TL;DR: Misused OAuth tokens linked to the Salesloft Drift integration enabled unauthorized access to Salesforce data between August 8 and 18, 2025, affecting hundreds of customers, according to Omada Identity. The incident shows how third-party OAuth exposure can outpace visibility, offboarding, and trust controls for NHI governance.
At a glance
What this is: Omada Identity reports that misuse of OAuth tokens associated with a third-party Salesforce integration exposed customer data and highlighted weak governance over delegated access.
Why it matters: IAM and NHI teams need to treat third-party OAuth relationships as governed identities with lifecycle controls, not as one-time connectors that can be left to drift.
Context
Salesloft Drift token misuse is a third-party access governance problem, not a Salesforce platform problem. OAuth tokens can outlive the business relationship or operational need that created them, which leaves delegated access available long after teams assume it has been contained. For IAM and NHI programmes, the question is whether integration access is inventoried, monitored, and revoked with the same discipline as any other non-human identity.
Omada Identity says unauthorized access occurred between August 8 and 18, 2025 and impacted hundreds of Salesforce customers. Omada also confirmed in its later update that no external email address or customer-business contact information was exposed, which narrows the incident impact but does not reduce the governance lesson for third-party OAuth access.
Key questions
Q: What breaks when OAuth access is not governed like a non-human identity?
A: Access persists beyond the user session that created it, so the organisation loses the usual sign-in checkpoints that would normally bound use. The application keeps operating with the originally granted token, which means revocation, ownership, and review become the real control points. Without them, integrations turn into standing access paths rather than temporary permissions.
Q: Why do OAuth tokens increase lateral movement risk in SaaS environments?
A: OAuth tokens increase lateral movement risk because they can remain valid after the initial user session, bypass MFA, and preserve scoped access until revoked. In SaaS environments, that makes a single consented app a durable bridge into email, files, logs, and admin-adjacent data. Identity governance must treat token scope and revocation as first-class controls.
Q: How can teams tell whether SaaS governance is actually working?
A: Look for evidence that discovered applications can be assigned an owner, tied to an access policy, and removed through an enforced workflow. If the platform can only report on SaaS usage but cannot drive deprovisioning or entitlement review, governance is still fragmented.
Q: What should organisations do after discovering misuse of a third-party integration token?
A: Disable the token, disconnect the application, confirm the scope that was active during the exposure window, and assess whether any downstream data was accessible beyond the core system. Then review other integrations that share the same trust model, because one compromised app often reveals a wider lifecycle problem. Response should end in governance review, not only containment.
Technical breakdown
How OAuth tokens become delegated non-human access
OAuth tokens act as delegated credentials, allowing one application to access another system without sharing a human password. In SaaS-to-SaaS environments, the token often becomes the real identity boundary because the downstream system trusts the token holder as if it were the application itself. That trust is durable unless the token is revoked, the app is disconnected, or scopes are reduced. When third-party integrations are left unattended, the access path can remain valid even after the original business intent has changed.
Practical implication: inventory OAuth grants with the same rigor used for service accounts and revoke stale integration tokens promptly.
Why third-party integration offboarding is the control point
The problem is not only token theft. It is the absence of a lifecycle event that reliably ends delegated access when the relationship, scope, or use case changes. Third-party integrations sit between IAM, SaaS administration, and vendor risk management, so ownership is often split and revocation is delayed. Without explicit offboarding and periodic review, the organisation relies on implicit trust in a connection that may no longer be justified.
Practical implication: assign a clear owner for every external integration and require formal offboarding when the integration is no longer needed.
Why visibility gaps make OAuth misuse hard to contain
OAuth misuse is difficult to spot when teams do not monitor token use, API access patterns, or third-party application scope continuously. A compromised or over-trusted integration may access CRM data without triggering obvious user-facing anomalies because the activity appears to come from an authorised application. That means containment depends on integration telemetry, scope governance, and rapid revocation paths rather than on post-event user investigation alone.
Practical implication: monitor third-party application activity, not just human sign-ins, and alert on unusual API behaviour or scope drift.
Threat narrative
Attacker objective: The objective was to reach Salesforce-held customer data through a trusted third-party access path without using direct account compromise.
- Entry occurred through misuse of OAuth tokens associated with the Salesloft Drift third-party application connected to Salesforce.
- The tokens provided delegated access to Salesforce data, allowing unauthorized access between August 8 and 18, 2025.
- The primary impact was exposure of customer business contact information, company attributes, and basic customer engagement information through the compromised integration.
Breaches seen in the wild
- Gainsight Salesforce breach 2025: Stolen OAuth tokens for Gainsight's Salesforce app, some eight years old, were used against customer orgs; Google saw 200+ instances at risk.
- Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Third-party OAuth access is now a governed identity problem, not a vendor integration detail. The incident sits in the same category as service-account sprawl because the organisation has delegated access to a non-human actor and then allowed the lifecycle to drift. When hundreds of customers can be affected through a trusted app connection, the control failure is governance over delegated access, not just token security. Practitioners should treat every external OAuth grant as an accountable identity relationship.
Vendor-managed integration trust creates a blind spot when ownership is split across teams. Security, application owners, and vendor managers often each assume someone else will revoke the access path. That diffusion of responsibility is what lets an integration survive beyond its business purpose. The lesson for IAM and NHI programmes is to make ownership, review, and offboarding explicit for every third-party credential path.
Salesloft Drift token misuse illustrates the identity blast radius of SaaS-to-SaaS trust. Once a third-party token is accepted by a core business platform, the attacker does not need to defeat the platform's primary authentication layer. The exposure surface expands through delegated trust, which is why integration inventory and scope governance belong in the identity control plane. Teams should measure the blast radius of each external app connection, not just the number of logins.
Shadow trust in external applications is the real governance debt exposed here. The exposed data was limited in this case, but the pattern shows how quickly a trusted integration can become an unreviewed access path. A mature NHI programme has to account for external apps as identities with their own lifecycle, scope, and revocation requirements. The practical conclusion is to govern integrations as assets with expiry, not as permanent convenience links.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: SaaS-to-SaaS and OAuth App Governance Guide
What this signals
Identity blast radius: every external app connection should be treated as a potential expansion of the organisation's trusted access surface, because a single delegated credential can open a path far beyond the original user account. That is why integration inventory, scope review, and revocation ownership must sit inside the IAM operating model rather than in ad hoc application administration.
Third-party OAuth governance is converging with broader NHI lifecycle discipline. The same questions that apply to service accounts now apply to external SaaS integrations: who owns them, what privileges they hold, when they expire, and how quickly they can be removed when trust changes.
For practitioners
- Map every third-party OAuth grant Build an inventory of Salesforce-connected applications, the scopes they hold, and the business owner responsible for each grant.
- Offboard dormant integrations on a schedule Remove unused app connections and require reapproval for any integration that has not been actively justified within a defined review cycle.
- Reduce delegated access scope Review whether each third-party app needs read, write, or admin-level access and remove any scope that is not operationally necessary.
- Monitor integration activity separately from user sign-ins Alert on unusual API access, token use outside expected patterns, and third-party app behaviour that suggests scope drift or reuse.
- Prepare a revocation runbook for integration compromise Define who disables tokens, who disconnects the app, and who communicates with business owners when a third-party OAuth path is suspected of misuse.
Key takeaways
- The incident shows how third-party OAuth misuse can turn a trusted integration into an access path that bypasses normal human authentication controls.
- Omada Identity says the unauthorized access window ran from August 8 to 18, 2025 and affected hundreds of Salesforce customers.
- The control gap is lifecycle governance for delegated access, including ownership, scope review, and prompt revocation of unused integrations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The article centres on a third-party app connection whose delegated access was misused. |
| NHI-01 — Improper Offboarding | The core failure is lifecycle control over an external integration that should have been removed or reset. | |
| NHI-04 — Insecure Authentication | OAuth token misuse shows how delegated authentication can fail when token handling is weak. | |
| Recommendation — Review and harden third-party NHI trust relationships before they become privileged access paths. Remove stale integration access and tie offboarding to business ownership and review cycles. Strengthen token issuance, storage, and revocation controls for delegated SaaS access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth tokens are authenticators whose lifecycle needs explicit management and revocation. |
| Recommendation — Apply authenticator lifecycle controls to issued tokens and revoke stale credentials promptly. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The incident involves token misuse leading to unauthorized access and exposure of CRM data. |
| Recommendation — Map token misuse to credential access and exfiltration tactics in detection and response planning. | ||
Key terms
- Third-Party NHI: Third-Party NHI is a non-human identity owned or operated by an external organization, partner, contractor, or supplier. It includes service accounts, API keys, certificates, tokens, and automated agents that access systems outside the primary enterprise boundary. Governance must cover issuance, scope, monitoring, revocation, and contractual accountability.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
- Vendor offboarding: Vendor offboarding is the controlled removal of a third party's access, data paths, and operational dependencies when the relationship ends or changes. It is a lifecycle control, not an administrative closeout, because any surviving credentials or integrations remain active security exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org