TLDR: A string of recent breaches, a marketing intelligence platform, a global student records system, a digital healthcare company, didn’t start with a phishing email or a cracked password. They started with access that was already there: a stolen OAuth token, a compromised integration, a connected app nobody was watching. The access was legitimate right up until it wasn’t. This is what that pattern means for everything your organization has plugged into its environment.
Attackers increasingly don’t need to break into your environment. They need to find a door someone already left open for a vendor.
That’s not a hypothetical. It’s the mechanism behind several of the past month’s breach disclosures. A digital healthcare company disclosed that hackers stole patient data through third-party-hosted business applications. A marketing intelligence platform confirmed that an attacker used a compromised legacy credential to obtain OAuth access tokens, then pulled data directly out of that company’s customers’ Salesforce and Gong instances. An extortion group built a months-long campaign by hitting one widely used Salesforce integration and walking away with data from over a hundred organizations connected to it, including more than 137,000 K-12 staff records from a single student information system.
None of these started with the target. They started with something the target had connected to, trusted, and stopped thinking about.
What Vendor Access Actually Means in Practice
Every connected app, every OAuth grant, every API integration, every MSP login is a standing credential that lives outside your own identity governance. Most of these get configured once, during onboarding or implementation, and then disappear from anyone’s active attention. Nobody revokes them. Nobody re-reviews what they can reach. They just sit there, working exactly as designed, for as long as the vendor relationship lasts.
The Klue breach is the clearest illustration of why that’s a problem. The attacker didn’t target Klue’s customers directly. They compromised Klue, used a legacy credential to obtain OAuth tokens for Klue’s integrated services, and used those tokens to reach into customer Salesforce and Gong environments from the outside. The customers weren’t breached in any sense most of them would recognize. Their vendor was, and that was sufficient.
This is the part that’s easy to miss when you’re building a security program around your own perimeter: the access an attacker needs to reach your data doesn’t have to come from your network at all. It can come from a tool you approved two years ago, configured by someone who’s no longer at the company, still holding the scope it was granted on day one.
Why This Keeps Working
The data backs up what feels anecdotal. Breaches involving a third party rose 60 percent year over year and now account for nearly half of all breaches tracked. Attackers are increasingly going after vendors, SaaS providers, and OAuth integrations rather than targeting organizations head-on, because the math favors it. Compromise one integration provider and you potentially get downstream access to every customer who connected to it. That’s a far better return than grinding through one organization’s perimeter at a time.
There’s a structural reason this keeps paying off. A vendor relationship typically gets security-reviewed once, at the point of onboarding. After that, it’s treated as settled. The access persists indefinitely, but the scrutiny doesn’t. The vendor’s own security posture doesn’t get re-checked on any meaningful cadence. Most organizations have no real visibility into what a given integration can actually reach once it’s been granted, only what it was supposed to be able to reach when someone last looked.
That gap between “approved once” and “monitored continuously” is exactly where these incidents live.
It’s also a gap that scales badly with the way modern organizations actually operate. A mid-sized company today might have dozens of SaaS platforms connected to its core systems, each with its own OAuth grants, each integrated by a different team for a different reason, at a different time. Marketing connects an analytics tool to the CRM. Engineering wires up a CI/CD pipeline to a code repository. Finance links an expense platform to the accounting system. Each of these decisions makes sense in isolation. None of them get revisited as a set. The result is a sprawling, largely undocumented web of standing access that nobody owns end to end, because no single team is responsible for the integration layer as a whole. Security teams often inherit visibility into the integrations they were involved in approving, and close to none into the ones added without a formal review.
The Blind Spot This Creates
The standard control here is the vendor security questionnaire: completed once, often answered optimistically by the vendor, rarely re-verified by anyone on either side. A questionnaire response and an OAuth scope are not the same thing. One is a claim about a security program. The other is a permission that persists whether or not anyone is still thinking about it, regardless of whether the claim was accurate, regardless of whether it’s still accurate now.
Knowing what a vendor says about their security program is a different exercise from knowing what their compromise would actually let an attacker reach inside your environment. Those two pieces of information get conflated constantly, and the conflation is what these breach chains exploit. An organization can have a fully documented, regularly updated vendor risk questionnaire process and still have no idea that a connected app it approved eighteen months ago has read access to its CRM, its file storage, and half its customer support tickets.
This isn’t a failure of diligence so much as a mismatch between what gets reviewed and what actually carries risk. The questionnaire asks the vendor what they do. It rarely asks, and almost never verifies, what the integration itself is capable of doing if the vendor’s side of it is compromised.
What Actually Closes the Gap
Start with an honest inventory. Most organizations significantly underestimate how many third-party integrations, connected apps, and standing vendor credentials actually exist inside their environment, because these accumulate quietly over years and rarely get decommissioned even after the underlying tool stops being used. You can’t manage exposure you haven’t mapped.
From there, treat OAuth scope and vendor access as something to test against, not just something to document. A questionnaire tells you what a vendor claims about their controls. An assessment that actually probes what a given integration’s access would let someone do if that vendor were compromised tells you something a questionnaire can’t: your real exposure, not your assumed exposure.
Finally, build incident response planning around the assumption that a breach might start outside your walls entirely. Most IR plans are written around the idea that the organization itself gets compromised first: an endpoint gets infected, a user gets phished, a server gets exploited. Increasingly, the more realistic scenario is that something you trusted gets compromised, and the first sign of trouble is data already moving through a connection you’d stopped paying attention to. An IR plan that has no answer for “what do we do when the breach happened on the other end of an integration we don’t control” is missing the scenario that’s currently playing out across the headlines.
None of this requires treating every vendor as hostile or ripping out every integration on principle. It requires treating standing access the way you’d treat any other asset with real reach into your environment: tracked, periodically tested, and owned by someone who’s accountable for knowing what it can actually do.
The Perimeter That’s Actually Being Tested
The perimeter most organizations spend their time defending is their own: the network, the endpoints, the identity provider, the things directly under their control. The perimeter attackers are increasingly using is someone else’s, granted in good faith, configured correctly at the time, and never tested since.
That gap doesn’t close itself, and it doesn’t show up on a vendor questionnaire. It shows up when someone actually tries to use the access the way an attacker would.