The recent SalesLoft Drift breaches revealed an uncomfortable truth that keeps me up at night, and should keep every CISO awake, too. Organizations weren’t breached through their vendor. They weren’t even breached through their vendor’s vendor. It appears they were compromised through their vendor’s acquired company, referred to as a “fourth-party,” via legacy OAuth tokens that had been dormant for 18 months.
As a point of fact, Drift historically integrated with both Salesforce (as a connected app) and Google Workspace (via its email integration). In this incident, attackers abused OAuth tokens associated with the Drift application to access Salesforce instances and accessed a limited number of Google Workspace accounts through the Drift email integration.
Public disclosures have not confirmed whether any abused tokens predated Salesloft’s 2024 acquisition of Drift. However, there is a real possibility that some tokens were legacy and inherited, which is an all‑too‑common scenario in M&A. Regardless of token provenance, the risk pattern is clear.
Welcome to the fourth-party breach era, where your attack surface extends far beyond anything you can see, assess or control through traditional security measures.
The breach that changed everything
Let me paint you a picture of how this likely played out:
February 2024: SalesLoft acquires Drift, an AI-powered chatbot company
The hidden legacy: Drift’s existing OAuth tokens to thousands of Salesforce and Google Workspace instances probably remained active
Time passes: Tokens and app permissions remain valid unless explicitly rotated or revoked.
August 2025: Attackers abuse OAuth tokens associated with the Drift application to enumerate and exfiltrate Salesforce data; a limited number of Google Workspace accounts are impacted via the Drift email integration (per Google Threat Intelligence, The Hacker News).
The result: Hundreds of organizations breached through a vendor relationship outside their control.
Many organizations lack complete runtime visibility into which connected apps and inherited integrations hold OAuth access to their environments, particularly after M&A. That’s a gap adversaries exploit, and a gap we must close.
Your real attack surface in 2025
Here’s what security teams think they’re protecting:
Their SaaS applications
Their approved vendor integrations
Their documented third-party relationships
Here’s what they’re actually exposed to:
Every company their vendors have acquired
Every SaaS and AI tool integration those acquired companies ever created
Every OAuth token that survived those acquisitions
Every permission that nobody remembers granting
Now, I’ll put this in perspective with real numbers:
Enterprises today operate sprawling SaaS estates. On average, large organizations manage between 125 and 200 SaaS applications, with some studies reporting higher counts when shadow IT is included. Each of those applications typically maintains multiple third‑party/API integrations to function within enterprise workflows, often reaching low double‑digit connectors in mature stacks. Layered on top of this is steady consolidation: software M&A activity across technology, media and telecommunications (TMT) has remained active in recent years, with many mid‑market SaaS vendors completing a handful of acquisitions over five‑year periods, inheriting integrations and permissions along the way.
Put together, the math is sobering. Even at a conservative 150 apps and 5–10 integrations per app, most large enterprises are already managing roughly 750–1,500 integration links. When you add acquisition‑inherited OAuth connections and legacy permissions, exposure often reaches the thousands, resulting in an expanding fourth‑party attack surface that’s largely invisible until it’s exploited (SQ Magazine, PwC).
The M&A time bomb nobody talks about
Every time a vendor in your supply chain makes an acquisition, you inherit a security debt you don’t even know exists. Here’s why this is so dangerous:
OAuth tokens don’t care about ownership
When SalesLoft acquired Drift, they inherited:
Active OAuth refresh tokens that never expire
Broad permissions to customer Salesforce instances
API access to Google Workspace environments
Trust relationships that persist indefinitely
These tokens don’t check if the company still exists independently. They don’t verify if the acquisition was completed. They just continue to work. Sometimes for years.
The visibility black hole
Traditional vendor risk assessments ask questions like:
“Do you have SOC 2 certification?”
“What’s your incident response plan?”
“How do you manage access controls?”
What they don’t ask much or anything about acquisitions:
“What companies have you acquired in the last 3 years?”
“Did their OAuth integrations have access to sensitive data?”
“Are those legacy tokens still active?”
“Can you even enumerate all inherited permissions?”
The answer to that last question, by the way, is almost always “no.”
Why this changes everything
This isn’t just another supply chain attack. It’s a fundamental shift in how we think about SaaS security. Here’s why:
1. Point-in-time assessments are dead
Your vendor risk assessment from last quarter is already obsolete. In the time it took to complete it, your vendors made acquisitions, created new integrations and inherited permissions you’ll never know about until they’re exploited.
2. The perimeter is a myth
We’ve been saying “there is no perimeter” for years, but we still acted like we could define our vendor boundaries. The fourth-party reality means your perimeter extends infinitely through acquisition chains you can’t see or control.
3. Trust relationships are permanent
Once an OAuth token is granted, it can remain valid through acquisitions, bankruptcies, pivots and ownership changes. That startup you integrated with three years ago might now belong to a company you’ve never heard of.
The path forward
We can’t solve this with questionnaires. We can’t fix it with annual assessments. We need continuous, real-time visibility into the actual behavior of every OAuth token, every API connection and every data flow, regardless of who owns it today versus who owned it yesterday.
This means we must:
Monitor behavior and data, not the vendor. Stop trusting vendor relationships. Start monitoring sensitive data flows. An OAuth token accessing an abnormally large volume of Salesforce data at 3 AM from a Tor exit node is suspicious, whether it belongs to a trusted vendor or not.
Assume infinite parties. Don’t think in terms of third-party or fourth-party. Assume infinite parties. Your security posture should be based on zero-trust principles that verify every action, regardless of the trust chain.
Demand OAuth archaeology. Every organization needs to conduct what I call “OAuth archaeology”: digging through layers of integration sediment to understand what tokens exist, what sensitive data they can access and whether they should still be active.
A call to action for our industry
The SalesLoft Drift breaches of 2025 taught us that your biggest security risk might be a company you’ve never heard of, acquired by a vendor you trust, using tokens created before you were even their customer.
The only solution is continuous, real-time monitoring of every API call, every data flow and every OAuth token, regardless of how many parties they are removed from your organization.
The rules have changed. The fourth-party era is here. We need to fundamentally rethink how we secure our interconnected SaaS ecosystems.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
No Responses