Topic starter
02/08/2026 12:26 pm
TL;DR: OAuth token theft in the Salesloft Drift supply-chain campaign continues to expose Salesforce data at Qualys and Tenable, underscoring that stolen tokens can remain operational long enough to reveal customer support records and that detection lags when integrations are silently trusted, according to Anomali. The issue is not just compromise, but the governance assumption that third-party access stays visible, bounded, and reviewable in time to matter.
Editorial analysis by NHI Mgmt Group, based on content published by Anomali: “Anomali Cyber Watch: Salesloft Drift Breach, Salty2FA Phishing, GPUGate Malware, and More”.
Key questions
Q: What breaks when a stolen OAuth token is used against a trusted integration?
A: The trust model breaks because the system still sees a valid credential, even though the actor behind it is no longer trustworthy.
Q: Why do stolen OAuth tokens create such a large blast radius in SaaS environments?
A: Because the token often carries delegated access to multiple objects, actions, and downstream APIs, so one compromise can reach far beyond the initial integration.
Q: What are the signs that a third-party OAuth integration is over-trusted?
A: Warning signs include broad scopes, old tokens that still work, unclear app ownership, and integrations that were never revisited after a vendor or business change.
Practitioner guidance
- Inventory every OAuth integration Map each third-party app, the resources it can reach, the owner who approved it, and the data it can touch.
- Revoke tokens on vendor offboarding Treat partner change, app replacement, and contract end as revocation triggers for OAuth credentials, not just help desk cleanup.
- Shorten token scope and lifetime Remove unnecessary permissions from connected apps and reduce how long tokens remain valid so stolen credentials have a narrower abuse window.
Bottom line: This campaign shows that stolen OAuth tokens can keep third-party SaaS access alive long enough to expose sensitive customer support data.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:25 pm
Delegated SaaS access is now a governance boundary, not an implementation detail: When a third-party app can reach production data through OAuth, the organisation is managing non-human identity risk whether it has labelled it that way or not. The Salesloft Drift campaign shows that integration trust can persist beyond the visibility of the original compromise. Practitioners should treat app-to-app access as a governed identity domain with its own ownership and review requirements.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should IAM teams govern third-party SaaS access after a breach?
A: They should recertify every downstream entitlement tied to the affected integration, identify which apps inherited trust from the compromised connection, and revoke anything without a clear owner. The same review should cover dormant test apps, vendor connectors, and service accounts, because each can preserve access beyond the original incident.
👉 Read our full editorial: Salesloft Drift token abuse expands the NHI governance gap