Third-Party SaaS Token Breaches: How One Vendor Compromise Reaches Hundreds of Tenants

A third-party SaaS token breach happens when an attacker steals the credentials a vendor uses to reach its customers, an integration's OAuth tokens, a support system's session data or an app's client secret, and uses them against every customer that trusted the vendor. SWI calls this a fan-out breach. In the Identity Breach Database, 19 of 115 identity breaches from 2021 to October 2026 (16.5%) are fan-out breaches, 14 of the 19 abused a non-human identity, and 10 of the 43 disclosed in 2025-2026 (23.3%) fit the pattern (Identity Breach Report 2026, finding 5). MFA does not reach most of them, because no person logs in.

This article walks through the records behind the pattern, separates it from look-alike campaigns such as Snowflake and 0ktapus, and lists the detection signals and controls for OAuth integrations and connected apps.

What a fan-out breach is

The report's definition: an incident in which one compromised identity or credential store at a provider is used, or exposed for use, against many separate customer organizations. The fan-out is the number of downstream organizations, tenants or repositories reached.

The defining feature is where the identity lives. In a fan-out breach, the abused credential belongs to the provider, not to you. Your password policy, your MFA rollout and your conditional access rules for employees never see it. What you control is what you allowed that identity to do: the scopes you consented to, the IP ranges it can call from, and how quickly you can revoke it.

The records behind the pattern

Salesloft Drift (2025): integration tokens as standing access

From as early as August 8 through at least August 18, 2025, UNC6395 used compromised OAuth tokens for the Salesloft Drift app to query and export data from numerous corporate Salesforce instances (record). The attacker then searched the stolen data for AWS access keys, passwords and Snowflake tokens. Salesloft and Salesforce revoked all Drift access and refresh tokens on August 20. Google later reported that Drift Email tokens were also used on August 9 to read mail from a very small number of Google Workspace accounts. Victims included Cloudflare.

The record's lesson: the integration's refresh tokens worked as standing access to many tenants with no user or MFA in the path. The second-order lesson is in what the attacker searched for. Support cases and CRM notes held secrets, so a CRM breach became a cloud breach.

Gainsight (2025): the same door, three months later

On November 19, 2025, Salesforce disclosed suspicious activity involving Gainsight-published applications connected to Salesforce, revoked all their active access and refresh tokens and pulled the apps from AppExchange (record). Google Threat Intelligence said it was aware of more than 200 potentially affected Salesforce instances. Gainsight's CEO later said only a handful of customers had data stolen, so the scope is disputed. Reporting tied the activity to ShinyHunters and to tokens taken in the earlier Drift campaign, which makes it one of the 12 incidents in the database where the abused credential should already have been dead.

Okta support system (2023): support uploads that carried sessions

From September 28 to October 17, 2023, an attacker used a service account credential, saved to an employee's personal Google profile on an Okta laptop, to access Okta's customer support case system (record, teardown). Files there included HAR files with live session tokens, which the attacker used to hijack sessions at five customers. Okta counts 134 customers whose support case files were accessed. 1Password, BeyondTrust and Cloudflare each detected and contained the activity.

The second hop is the instructive part. Cloudflare contained the October session hijack, then missed one access token and three service account credentials from it. From November 14 to 24, 2023, an attacker Cloudflare believes was a nation state used them to reach its Atlassian Confluence, Jira and Bitbucket (record). Cloudflare then rotated more than 5,000 production credentials.

An earlier Okta incident shows the human version of the pattern. In January 2022 an attacker had remote access to a workstation of a support engineer at Okta's subprocessor Sitel (record). Okta first estimated up to 366 customers potentially affected, then concluded the attacker accessed two customer tenants.

Other fan-out records worth knowing

• GitHub, Heroku and Travis CI (2022): stolen OAuth user tokens issued to Heroku and Travis CI were used to download private repositories of dozens of organizations, after a Heroku machine account token was taken from an archived private repository (record).
• Commvault Metallic (2025): CISA said a nation-state actor may have accessed client secrets for Commvault's Microsoft 365 backup SaaS, giving potential access to customers' tenants (record).
• ConnectWise Cloud Backup (2026): an attacker signed in as the vendor's multi-tenant Microsoft Entra application with a credential from the vendor's own tenant. Huntress confirmed unauthorized sign-ins in 162 tenants, and Microsoft said Storm-0940 attempted sign-ins to more than 2,250 tenants (record).

The contrast: Snowflake and 0ktapus are platform campaigns

Not every breach that touches many companies is a fan-out breach. The report separates shared-platform campaigns: many separate compromises, one technique, one platform.

Snowflake (2024) is the clearest case. Mandiant found no compromise of Snowflake's platform. UNC5537 logged into about 165 customer accounts one by one with credentials stolen by infostealer malware, some as far back as 2020, on accounts that lacked MFA, had not rotated credentials and had no network allow lists (record, teardown).

0ktapus (2022) is the phishing version. SMS messages linked to fake Okta login pages captured 9,931 credential sets and 5,441 MFA codes from users at more than 130 organizations, per Group-IB (record). It becomes fan-out only at specific victims: the Twilio intrusion let the attackers view data of 209 customers and 93 Authy users, and Signal was reached through Twilio.

The difference changes who fixes it. A fan-out breach is the provider's identity problem: the provider has to scope, rotate and revoke, and customers can only limit what the provider's identity was allowed to do. A platform campaign is each customer's identity problem: enforce MFA, preferably phishing-resistant, and network restrictions on your own tenant.

Why MFA does not help here

In SWI's data, 20 of the 43 breaches disclosed in 2025-2026 (46.5%) had no interactive login at which MFA could apply, up from 7 of 33 (21.2%) in 2021-2022 (finding 3). Non-human identities were the abused identity in 29 of 115 breaches (25.2%), rising to 14 of 43 (32.6%) in 2025-2026 (finding 4). A stolen refresh token or client secret goes straight to the API. The same is true at the front of the chain: in the UNC6040 campaign, callers posing as IT support talked employees into authorizing a modified Data Loader connected app, and at Cyberhaven an employee with Google Advanced Protection received no MFA prompt, because an OAuth consent grant is not a login.

How to detect token abuse by connected apps

Detection has to watch what apps do, not how people sign in.

• Bulk reads by an integration. The Gainsight record's lesson names monitoring for bulk API queries. An integration that normally syncs a few hundred records and suddenly exports whole objects is the signal.
• App sign-ins from new networks. Integration tokens are usually used from the vendor's infrastructure. Calls from unfamiliar IP ranges or hosting providers deserve an alert.
• Searches for secrets. Drift's attacker searched for AWS keys, passwords and Snowflake tokens. Pair SaaS audit logs with secret scanning of the same data so you know which credentials to rotate if the data leaves.
• New permissions granted by apps. In the ConnectWise case, in one tenant a second vendor app granted itself Global Administrator and added secrets to other applications. Alert on directory role changes and credential additions made by service principals.
• Dormant apps that wake up. A connected app with no use for months that starts calling the API is either a renewed project or a stolen token. Either way, someone should confirm it.

Expect noise: legitimate integrations run large syncs, change IP ranges and get new permissions in upgrades. Each alert needs an app owner who can say "that was us" quickly, which is why the inventory below comes first. ITDR tooling that ingests SaaS and directory audit events helps here; the ITDR buyer guide and non-human identity security platforms ranking compare options.

Controls for OAuth integrations and connected apps

The report ties two of its ten controls to this pattern: brokered, time-bound third-party and integration access (24 of 115 incidents) and governing OAuth apps and user consent (8 of 115). In practice:

1. Inventory every connected app and give each an owner. Google Workspace's App access control lists configured apps, apps that have accessed Google data and apps pending review, and lets admins set each to Trusted, Limited, Specific Google data or Blocked, restrict high-risk OAuth scopes and choose settings for unconfigured apps. Microsoft Entra lists enterprise applications and their permissions. Do the same review for Salesforce connected apps.
2. Restrict who can consent. In Entra, the user consent settings include a built-in policy that allows user consent only for apps from verified publishers and apps registered in your tenant, and only for permissions you classify as low impact. Pair it with the admin consent workflow, which lets users request approval from designated reviewers instead of granting access themselves. See consent phishing.
3. Scope and IP-restrict integration tokens. Grant the narrowest scopes the integration needs, restrict connected apps to the vendor's known IP ranges where the platform allows it, and prefer short token lifetimes.
4. Know the limits of conditional access for apps. Microsoft's Conditional Access for workload identities can block service principals from outside known IP ranges or on detected risk, but it needs Workload Identities Premium licenses and, per Microsoft, applies only to single-tenant service principals registered in your tenant. Third-party multi-tenant SaaS apps, the ConnectWise and Commvault kind, are not covered. For those, review permissions and remove what is not needed.
5. Keep secrets out of SaaS records. Support tickets, CRM notes and HAR files are not secret stores. Sanitize HAR files before upload and scan SaaS data for API keys and passwords.
6. Be able to revoke one vendor in one action. Write down, per critical vendor, where its tokens and service principals live and how to revoke them all. Salesloft and Salesforce revoked every Drift token, and Salesforce revoked Gainsight's; you should not need to wait for the platform to do it for you.
7. Rotate everything after a vendor breach. When a provider you use is breached, rotate every credential it could have seen, including service accounts thought to be unused. Cloudflare's second hop is the reason. See secrets rotation.
8. Treat each integration as a privileged non-human identity. Owner, expiry, least privilege and access reviews apply to service principals as much as to people. The non-human identity security guide and zero standing privileges rollout cover the program.

Related techniques: refresh token abuse, static API key abuse, session cookie theft and secrets in repositories and CI. The OAuth 2.0 standard page explains the token types, and the identity incident response runbook covers revocation order when it happens to you.

Bottom line

Fan-out breaches rose to 10 of the 43 identity breaches disclosed in 2025-2026 (23.3%) in SWI's data, and most of them sit outside MFA: 14 of the 19 abused a non-human identity. You cannot secure the vendor's credential, but you can decide what it is allowed to do, watch what it does, and revoke it fast. Every number above comes from the Identity Breach Report 2026 and the linked records.