SaaS Integration Token Breach Response: Revoke and Prove

When a SaaS vendor's integration tokens are stolen, most organisations revoke the obvious grant and miss the rest of the chain. The breaches below show the same gaps each time: tokens nobody knew existed, secrets sitting in the data the integration could read, credentials the attacker planted on other apps, and rotations that skipped a few accounts. This guide sets out a response that covers all three jobs, revoke, rotate and prove it, with the platform mechanics and the evidence you need to show the incident is actually closed. It assumes you already govern OAuth apps and have an incident playbook; it is for the identity, SaaS and incident response practitioners who have to run the response when a vendor calls.

Key takeaways

Treat every token the vendor held as compromised. Google Threat Intelligence Group advised treating all Drift-connected tokens as compromised, not only the ones seen in use.
Revocation is not one action. Disabling an app, revoking refresh tokens, letting access tokens expire and removing credentials the attacker added are separate steps on separate timers.
The data the integration read is now a secret store. In the Salesloft Drift case the attacker searched exported records for AWS access keys, passwords and Snowflake tokens; anything in those records must be rotated.
A rotation that misses one credential is no rotation. NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026) draws exactly this lesson from Trivy: "revoke everything, then prove it."
Proof is an evidence pack, not a status update. Close the incident only when logs show no use of old tokens after revocation and every rotated credential has a recorded new version.

What goes wrong in integration token incidents

The report counts 15 breaches that came in through an OAuth or SaaS integration and 20 that abused OAuth tokens, and its lesson from Salesloft Drift is to "inventory every connected app and integration token, with its owner, scopes and expiry." The cases below show why that inventory decides how fast you can respond.

Case	What was stolen	Response gap it exposes
Salesloft Drift (2025)	OAuth access and refresh tokens for the Salesforce and Google Workspace integrations, taken from Drift's AWS environment	Secrets pasted into support cases became the next target; Cloudflare rotated 104 API tokens as a result
Palo Alto Networks (victim view, 2025)	Salesforce data exported through the Drift tokens	Credentials customers had put in case notes may have been exposed; Unit 42 saw the attacker delete query jobs, which hides evidence
Gainsight (2025)	285 OAuth tokens, 2 to 8 years old	Only about 23% still existed in the vendor's systems, so the vendor could not tell customers which tokens were live
Klue (2026)	Customer Salesforce OAuth tokens collected after a stale GitHub PAT from an abandoned pilot was used to change integration code	The vendor's own forgotten credential was the root; customers had to revoke and review API logs for the exposure window
ConnectWise Cloud Backup (2026)	A multi-tenant Entra app credential	Attackers added client secrets valid until 2028 to other apps; disabling the vendor app did not remove them
Internet Archive (2024)	A GitLab token, then Zendesk API tokens found in the stolen code	The Zendesk tokens were not rotated after the first breach, so the attacker came back weeks later

Step 1: scope the blast radius before you pull the plug

Spend the first hour building the list of everything the vendor could touch. Revoking first and scoping later loses the log evidence you need and leaves gaps.

Every grant from the vendor: list connected apps, enterprise applications, marketplace apps, integration users and API keys tied to the vendor, across every SaaS platform, not just the one named in the advisory. Drift had both a Salesforce and a Google Workspace integration.
Scopes and objects: record what each grant could read and write. This defines which data you must search for secrets later.
Token age and issuer: note when each token was issued and by whom. Gainsight's tokens dated back to 2017.
Sibling and fourth-party apps: other apps from the same publisher, and anything the vendor's integration could create or modify. At ConnectWise, sibling Cloud Management service principals were the ones that took directory roles.
Preserve logs now: export API event logs, sign-in logs and audit logs for the exposure window before retention runs out. See the SaaS Audit Log Retention and Licensing Guide.

Step 2: revoke, platform by platform

Each platform separates "stop new tokens" from "kill the tokens already issued". Do both, and record the time of each.

Platform	Stop new tokens	Kill what is already issued	Watch for
Salesforce	Block or uninstall the connected app; set its Refresh Token Policy away from the default "Valid until revoked"	Revoke tokens from the OAuth Connected Apps Usage page or the user's detail page	Refresh Token Policy is checked only when the refresh token is used, so it does not end a current session
Microsoft Entra ID	Set "Enabled for users to sign-in?" to No on the enterprise app (service principal `accountEnabled` false), which Microsoft says prevents all tokens from being issued for that application	Remove client secrets and certificates you control; access tokens already issued run to expiry	New secrets or certificates added to other applications; directory role assignments to vendor service principals
Google Workspace	Set the app to Blocked in API controls	Revoke the app's tokens for affected users	Other apps from the same publisher with similar scopes
Any platform with API keys or integration users	Disable the integration user or key	Rotate the key and confirm the old value fails	Keys copied into the vendor's systems that you cannot see

For a multi-tenant Entra app published by the vendor, Microsoft Learn notes that disabling sign-in works per tenant, and only the publisher deactivating the application blocks it globally. Do not plan on Conditional Access here: Microsoft Learn states that Conditional Access for workload identities covers only single-tenant service principals registered in your tenant, not third-party SaaS or multitenant apps. Revocation mechanics in general are covered in the OAuth Token Introspection and Revocation Guide.

Step 3: rotate everything the token could see

Revoking the vendor's access stops future reads. It does nothing about what was already read. Rotation has three targets.

Secrets inside the exposed data: search records the integration could read (support cases, notes, attachments, email, chat) for credential patterns such as the AKIA prefix of AWS access keys, private keys, connection strings and tokens. Treat any hit as exposed and rotate it at source. See the Work SaaS API tokens guide.
Credentials the attacker created: list app credentials, role assignments, OAuth grants and integration users created during the exposure window, and remove any that cannot be traced to an approved change.
Shared secrets with the vendor: rotate API keys, webhook secrets and client secrets you issued to the vendor, even if they were not named, because you cannot verify the vendor's internal blast radius. Cloudflare's earlier breach happened because one service token and three service accounts were skipped in the belief that they were unused; see the Cloudflare Thanksgiving breach.

Prioritise by power: rotate cloud and data platform keys first, then source control and CI tokens, then everything else. The Internet Archive lesson is to prioritise the most powerful secrets when rotating after a leak.

Step 4: prove it

A closed ticket is not proof. Build an evidence pack that an auditor or regulator can follow.

Evidence item	Where it comes from	What it proves
Inventory of every vendor grant with revocation time	Platform admin consoles, exported	Nothing was left out of scope
Log query showing no use of revoked tokens after revocation time plus maximum access token lifetime	API event logs, service principal sign-in logs	The token tail has ended
List of secrets found in exposed data, each with rotation date and new version ID	Secret scan results, vault version history	Exposed secrets are dead at source
Test that each old credential fails	Controlled authentication attempt, recorded	Rotation actually took effect
Diff of app credentials and role assignments before and after the window	Directory audit logs	No attacker persistence remains
Vendor's written statement of root cause and its own rotation	Vendor incident report	The source of the tokens is closed

Running the response

Hour 0 to 1: confirm the vendor notice or detection, open the incident, preserve logs, and start the grant inventory.
Hour 1 to 4: revoke grants and disable integration identities on every platform; record times. Decide on a business workaround for the disconnected integration.
Day 1: hunt the exposure window: bulk exports, count queries followed by record pulls, unfamiliar user agents (the Drift case showed Salesforce-Multi-Org-Fetcher/1.0), and access from Tor or anonymising proxies.
Days 1 to 3: scan exposed data for secrets, rotate findings and shared vendor secrets, remove attacker-created credentials.
Days 3 to 7: assemble the evidence pack; assess notification duties with legal and privacy.
Reconnect (when the vendor shows root cause fixed): re-authorise with narrower scopes, a refresh token expiry instead of tokens valid until revoked, and IP restrictions to the vendor's published ranges where supported. Keep the previous configuration on record so you can roll back if the narrower grant breaks a business process.

The roles, contacts and communication steps belong in your playbook; the Vendor SaaS Breach Response Playbook and the OAuth Token Theft Incident Playbook provide templates.

Decision guidance

Precautionary disconnect or wait: when a vendor reports suspicious activity but has not named you, disconnect if the integration can read regulated data or secrets. Zendesk and HubSpot cut Gainsight connections as a precaution, and Palo Alto Networks disabled its integration and later said it was not affected.
Rotate or reissue: where a platform allows, reissue a new grant with new scopes rather than rotating within the old one, so the old consent record cannot be reused.
Small teams: without a SIEM, use the platform's own usage pages and export logs to a spreadsheet; the evidence pack still applies.
Large estates: script the grant inventory per platform in advance, so step 1 takes minutes, not a day.

Detection and measurement

Integration baselines: source IP ranges, user agents, API versions and query volumes for each integration, so deviations stand out.
Bulk token testing: Gainsight's attacker bulk-tested about 250 tokens before use; alert on many failed or first-time token uses from new infrastructure.
Credential changes: new secrets or certificates on applications and new role assignments to service principals.

Metric	Target
Time from vendor notice to all grants revoked	Under four hours
Integrations with recorded owner, scopes and token expiry	100%
Integrations with refresh tokens valid until revoked	Zero for tier-one data
Secrets found in SaaS records per quarter	Falling, with automatic redaction
Incidents closed with a complete evidence pack	100%

Common failure patterns

Revoking only the platform named in the advisory: the same vendor often holds grants in mail, CRM and file platforms.
Uninstalling without revoking: removing the app from a menu while refresh tokens remain valid.
Ignoring the data: secrets in support cases outlive the integration; the Slack GitHub breach is a reminder that private code repositories reached through vendor-held tokens can carry credentials too.
Exempting "unused" credentials: the Cloudflare and Internet Archive cases both turned on credentials left valid after a known exposure.
Reconnecting with the old scopes: restoring the integration exactly as it was resets the risk to day zero.

Framework mapping

Framework	Reference	Response step
NIST CSF 2.0	GV.SC-08, ID.AM-02	Suppliers in incident response; inventory of services
NIST SP 800-53 Rev. 5	IR-4, IA-5, AC-2, AU-6, SA-9	Incident handling, authenticator rotation, account removal, log review, external services
ISO/IEC 27001:2022 Annex A	A.5.21, A.5.26, A.5.28	ICT supply chain, response to incidents, collection of evidence
MITRE ATT&CK v20	T1528, T1550.001, T1098.001	Stolen application tokens, their use, and added cloud credentials for persistence

Practitioner checklist

Keep a per-platform script or report that lists every grant from a given vendor with scopes and token age.
Preserve logs before revoking.
Revoke issued tokens and block new ones, on every platform the vendor touches, and record both times.
Search all data the integration could read for secrets and rotate every finding at source.
Remove app credentials and role assignments created in the exposure window.
Rotate every shared secret with the vendor, with no "unused" exemptions.
Close only with an evidence pack showing no old-token use after revocation.
Reconnect with narrower scopes, refresh token expiry and IP restrictions.

SaaS integration token breach response: Revoke, Rotate and Prove Every Token Is Dead