Salesloft Drift breach exposes the limits of SaaS trust

At a glance

What this is: A Salesforce supply chain breach used compromised Salesloft Drift OAuth tokens to expose data across multiple organisations, showing how trusted SaaS integrations can become an access path for attackers.

Why it matters: IAM, PAM and NHI teams need to treat third-party OAuth trust as governed access, because weak lifecycle controls can turn one integration into broad data exposure.

Context

Salesforce-connected SaaS integrations are only as trustworthy as the tokens, scopes and revocation processes behind them. When a third-party app can reach business data, it inherits enough authority to become an identity control problem, not just a vendor risk problem.

This breach sits at the intersection of SaaS governance, OAuth trust and non-human identity lifecycle management. The central issue is not simply that an app was compromised, but that delegated access remained useful enough for credential harvesting and data exfiltration across multiple environments.

Key questions

Q: What breaks when a third-party SaaS integration loses trust but its token stays valid?

A: The control that breaks is the assumption that revoking the application relationship automatically removes access. A live token can continue to read data, search for secrets and move laterally through the connected platform until it is explicitly revoked. That is why third-party grants need lifecycle ownership, expiry review and emergency revocation paths, not just approval at onboarding.

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. The risk increases when the token is refreshable or tied to always-on automation. Blast radius depends on scope breadth, not just token presence.

Q: How should security teams govern SaaS applications that rely on integrations and shared data?

A: Treat SaaS governance as a combined identity, data, and integration problem. Start with a complete inventory of users, local accounts, OAuth grants, and service connections, then enforce least privilege, periodic access review, and rapid revocation for stale permissions. Continuous monitoring only works when findings trigger concrete entitlement changes.

Q: What should IAM teams prioritise after a third-party OAuth breach?

A: First, revoke or re-issue active tokens tied to the compromised integration, then review where those tokens had access and whether the same scopes exist elsewhere. After that, tighten consent, logging and secret-detection controls so one SaaS compromise cannot expose credentials stored in business records.

Technical breakdown

How stolen OAuth tokens turn a SaaS integration into an access path

OAuth gives an application delegated access without sharing the user's password. That delegation is controlled by tokens, scopes and refresh privileges, which makes the token itself the effective credential. If an attacker steals a valid token from a third-party integration, they do not need to break authentication again. They can operate inside the trust boundary already granted to the app, often with enough access to query data, enumerate records and search for secrets. In SaaS ecosystems, this is why the integration layer must be treated as an identity surface.

Practical implication: inventory every third-party OAuth app and verify that its scopes match the minimum data it genuinely needs.

Why credential harvesting becomes the attacker objective

In supply chain incidents like this, the initial data theft is often not the end goal. Attackers look for secondary credentials inside business systems because one exposed secret can unlock cloud accounts, admin consoles or other SaaS services. Salesforce records, support notes and account data can contain access keys, tokens or operational details that help an intrusion spread. This creates a chain where one compromised integration leads to discovery of other non-human identities, expanding the blast radius far beyond the original app.

Practical implication: scan high-value SaaS data stores for embedded secrets and treat those stores as potential credential reservoirs.

What revocation and visibility should have broken

Revocation only works if organisations can identify every active grant, understand which users or services depend on it, and retire it quickly when trust changes. Visibility matters because a token can remain valid even after the app or vendor is compromised, unless the control plane tracks ownership, scope and expiry well enough to cut access cleanly. Without that lifecycle view, organisations respond after exfiltration has already started rather than at the point of delegated trust loss.

Practical implication: require continuous review of OAuth grants, token age and third-party access ownership across SaaS environments.

Threat narrative

Attacker objective: The attacker aimed to harvest credentials and steal sensitive Salesforce data at scale through a trusted third-party integration.

1. Entry occurred through compromised OAuth tokens tied to the Salesloft Drift integration, giving the attacker valid delegated access into Salesforce environments.
2. Credential access followed as the actor searched those environments for high-value secrets such as AWS access keys and authentication passwords.
3. Impact came through systematic exfiltration of Salesforce data across multiple organisations, including exposure at Palo Alto Networks, Zscaler and PagerDuty.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• 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

SaaS trust has become a non-human identity governance problem. The breach shows that an OAuth grant is not just an integration detail. It is a delegated identity with its own lifecycle, scope and revocation requirements, and those controls failed here. Practitioners should treat third-party SaaS access as governed NHI territory, not as a procurement checkbox.

Credential harvesting is the real blast-radius multiplier in SaaS supply chain attacks. Once an attacker lands inside a business platform, the goal often shifts to finding secrets that unlock other systems. That means the protected asset is not only the data already in the SaaS app, but the hidden credentials embedded in tickets, notes and records. Practitioners need to assume SaaS data stores may contain machine identities waiting to be discovered.

Delegated access without continuous review creates trust debt. The longer an OAuth grant lives, the more likely it is to outlast the context that justified it. This is a governance failure because access remains technically valid after the trust relationship has become unsafe. Practitioners should re-baseline every persistent SaaS integration as an identity control with expiry, ownership and revocation expectations.

Zero Trust for SaaS only works when token scope and runtime behaviour are aligned. If a third-party app can read broadly, then runtime policy and data governance need to constrain what the token can actually reach. The issue is not simply access approval. It is blast-radius control across connected systems, which becomes decisive when one compromised app can touch many tenants or business units. Practitioners should use this as a test of whether Zero Trust is real or only declarative.

Salesloft Drift-style incidents validate the need for explicit third-party NHI governance. The market often treats machine and app identities as operational residue, but this breach shows they are the primary control plane for modern SaaS trust. The named concept here is SaaS trust debt: delegated access that accumulates faster than organisations can inventory, review and revoke it. Practitioners should manage that debt before the next integration is abused.

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.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

SaaS trust debt: organisations need to treat every long-lived OAuth grant as an identity with an owner, an expiry expectation and a revocation plan. When integrations outlive the context that created them, the control problem shifts from authentication to delegated access governance.

A practical Zero Trust reading of this breach is that blast radius must be measured at the integration layer, not just at the user layer. If one third-party app can reach business records, and those records may contain secrets, then the real question is whether your policy model can stop token abuse before exfiltration starts.

For practitioners

• Inventory every third-party OAuth grant Build a complete register of SaaS integrations, token scopes, owners and expiry dates so delegated access is visible before an incident forces discovery.
• Rotate and revoke tokens on ownership change Treat vendor compromise, app decommissioning and scope changes as events that require immediate token revocation, re-consent or re-issuance.
• Search business data stores for embedded secrets Scan records, tickets, notes and attachments for API keys, passwords and cloud credentials because attacker objective often shifts to harvesting reusable secrets.
• Constrain SaaS blast radius with least privilege Limit each integration to the smallest data set and action scope it needs, then verify those permissions continuously against actual runtime use.

Key takeaways

• The breach shows that a trusted SaaS integration can become an access channel for attackers when OAuth lifecycle controls are weak.
• The attacker objective was not just data theft but credential harvesting, which can turn one SaaS compromise into broader identity exposure.
• The most effective containment lesson is to govern third-party tokens as non-human identities with ownership, scope review and rapid revocation.

Key terms

• 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.
• 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.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.
• SaaS Trust Debt: SaaS trust debt is the accumulation of delegated access, consent grants and integration permissions that remain active longer than the business need behind them. The more trust debt an organisation carries, the harder it becomes to understand who or what can still reach sensitive data.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security and identity practitioners turn delegated access into something they can inventory, review and control.