Salesloft Drift token misuse exposes Salesforce NHI governance gaps

At a glance

What this is: This update explains a third-party OAuth token misuse incident tied to the Salesloft Drift integration and shows why delegated access remains a high-risk control surface for Salesforce-connected environments.

Why it matters: It matters because IAM, PAM, and NHI teams have to govern external integrations as active identity pathways, not just adjacent SaaS connections, or access can persist beyond intended oversight.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Omada Identity's update on the Salesloft Drift OAuth token incident

Context

OAuth-connected applications create a delegated identity pathway, which means an external app can access customer data without a human logging in each time. In this incident, the issue was not Omada’s core platform but the trust boundary created by a third-party integration tied to Salesforce, which is exactly where many identity programmes still have weak oversight.

The broader governance problem is familiar to NHI and IAM teams. Third-party app access often lives outside the normal lifecycle controls used for employees, while offboarding, scope review, and API monitoring lag behind business use. When that happens, a valid token becomes a standing access path rather than a controlled, time-bounded entitlement.

Key questions

Q: What breaks when third-party OAuth tokens are not tightly governed?

A: Delegated access turns into standing access that outlives the business need, the approval owner, and sometimes the vendor relationship itself. Once tokens are over-scoped or left active too long, attackers can reach sensitive SaaS data through a channel that still looks legitimate to normal controls.

Q: Why do third-party SaaS integrations increase identity risk in CRM environments?

A: They connect external applications directly to customer data, making the integration itself part of the identity attack surface. If scopes are broad, ownership is unclear, or revocation is slow, a compromised connector can expose contact data, business context, and downstream trust relationships.

Q: How can security teams know whether OAuth-connected applications are actually under control?

A: They should be able to name every integration owner, every granted scope, every active token, and every revocation trigger. If any of those four elements is missing, the environment does not have real governance over delegated access, only partial visibility.

Q: Who is accountable when a third-party integration exposes customer data?

A: Accountability sits with the organisation that approved and retained the integration, even if the technical fault lies with a vendor app. Frameworks such as OWASP Non-Human Identity Top 10 and Zero Trust both point toward explicit ownership, bounded access, and fast revocation for delegated identities.

Technical breakdown

OAuth token misuse in third-party SaaS integrations

OAuth tokens let a connected application act on behalf of a tenant without sharing a primary password. That delegation is useful, but it also creates a separate control plane that must be governed like an identity, not just like an app integration. If the token is stolen, misused, or over-scoped, the attacker inherits the application’s granted access until the token is revoked or expires. In this case, the incident centered on unauthorized use of Drift-associated tokens against Salesforce-connected data flows.

Practical implication: inventory every external OAuth grant, including who approved it, what scopes it has, and how quickly it can be revoked.

Third-party access visibility and integration lifecycle

Third-party SaaS connections often outlive the business need that created them. That happens when integrations are approved once, then left untouched while ownership changes, vendors shift, or the scope of data access expands. Without lifecycle controls, teams lose the ability to answer basic questions such as which apps still have access, what data they can read, and whether the access still serves an approved purpose. This is a governance failure, not just a monitoring gap.

Practical implication: treat every external integration as an identity record with owner, purpose, review date, and offboarding trigger.

Why Salesforce-connected data access becomes a breach multiplier

Salesforce is often a concentration point for customer, engagement, and account data, so a compromised integration can expose more than the application itself. The problem is not limited to data theft. It also creates a trusted channel for follow-on social engineering, targeted phishing, and account abuse because the exposed records can be used to mimic legitimate business communications. Once that channel is trusted, the blast radius extends beyond the original token misuse.

Practical implication: classify CRM-connected integrations as sensitive identity pathways and add monitoring for unusual export, read, or API activity.

Threat narrative

Attacker objective: The objective was to harvest data from a trusted customer-facing SaaS integration and use that access for broader misuse or follow-on social engineering.

1. Entry occurred through misuse of OAuth tokens associated with the Salesloft Drift integration, giving unauthorized actors a trusted path into Salesforce-connected data.
2. Escalation followed through access to customer business contact information, company attributes, and engagement records exposed via the compromised integration.
3. Impact was limited to data accessed through the Salesforce connection, but the compromised channel created downstream risk of phishing, impersonation, and misuse of trusted business contact data.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Third-party OAuth access is an identity problem, not a tooling problem. This incident shows how external application trust can create a standing access path even when the primary platform remains uncompromised. The governance failure sits in delegated access approval, scope ownership, and revocation discipline. Practitioners should treat every third-party integration as an identity with its own lifecycle, not as a one-time technical dependency.

Salesforce-connected integrations create identity blast radius. CRM data is not just operational metadata. When a trusted integration is misused, customer contact information and engagement context can be repurposed for phishing, impersonation, and account targeting. That makes the integration a high-value identity asset whose scope should be narrowed and reviewed with the same rigour as privileged access.

Vendor change and incident response assumptions often lag behind access reality. Many programmes assume an approved SaaS integration remains trustworthy until a formal review says otherwise. In practice, that assumption fails once a token is compromised or the business use case changes faster than the review cycle. The implication is that lifecycle governance for third-party access needs a shorter feedback loop than traditional quarterly recertification.

Identity lifecycle discipline must extend to OAuth grants and API paths. The same governance principles used for service accounts and privileged access apply here: named owner, explicit purpose, bounded scope, and fast offboarding. The problem is that many programmes still separate SaaS integration management from identity governance, which leaves a blind spot exactly where attackers look for durable access.

52 NHI Breaches Analysis remains the right reference point for this pattern. Token misuse, overexposed integrations, and delayed revocation recur across real incidents because they exploit the same governance gap: access is granted faster than it is reviewed. Practitioners should use that pattern to prioritise integration inventory and revocation workflows before another delegated channel is abused.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 20% have formal processes for offboarding and revoking API keys, which is why delegated access often persists after business use ends.
• That lifecycle gap is why teams should pair inventory with offboarding discipline, as outlined in the Ultimate Guide to NHIs.

What this signals

Delegated SaaS access is becoming a permanent governance problem, not a temporary integration issue. As more business processes depend on third-party apps, the control point moves from login to token lifecycle, and that is where many programmes are still weakest. The practical response is to manage external integrations as first-class identities with ownership, review, and offboarding. For teams building that model, the OWASP Non-Human Identity Top 10 is a useful control reference.

Identity blast radius is the concept teams should operationalise next. Once a connector can reach customer records, the compromise is no longer confined to the integration itself. The downstream risk includes phishing, impersonation, and trust abuse across sales and support workflows, which makes CRM-connected access materially more sensitive than many inventories suggest.

With 92% of organisations exposing NHIs to third parties, supply chain identity risk is already embedded in normal operations, not an edge case, according to our Ultimate Guide to NHIs. Teams should expect more delegated-access incidents unless they can inventory, scope, and revoke external grants quickly.

For practitioners

• Inventory every third-party OAuth grant Build a live register of connected applications, owners, scopes, last review date, and revocation path for every Salesforce-linked integration and other SaaS connector.
• Shorten integration offboarding cycles Require immediate removal of integrations that are no longer needed, especially when vendor relationships change or the business owner cannot justify the access.
• Restrict OAuth scopes to the minimum data set Audit every connector for overbroad read and write permissions, then narrow scopes to the smallest practical set of objects and API actions.
• Monitor for trusted-channel misuse Add detection for unusual API reads, contact export patterns, and atypical messaging activity originating from integrations that normally operate quietly.

Key takeaways

• Third-party OAuth tokens can create durable access paths that look legitimate until they are misused.
• The impact of delegated SaaS access is often wider than the original application because contact and engagement data can be reused for trust abuse.
• Inventory, scope reduction, and fast offboarding are the controls that limit this failure mode in practice.

Key terms

• OAuth Token: An OAuth token is a delegated credential that lets an application act on a user or tenant’s behalf without sharing the primary password. In identity governance terms, it is a non-human access artefact that must be owned, scoped, monitored, and revoked like any other credential.
• Third-Party Integration Lifecycle: The third-party integration lifecycle is the full set of steps that govern a connected application from approval through review, scope change, and removal. For security teams, it is the control framework that prevents forgotten connectors from becoming persistent access paths.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, and trust relationships an identity can reach if it is misused or compromised. In SaaS environments, it helps teams judge whether an integration is low-risk convenience or a high-impact access path.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Omada Identity covering the Salesloft Drift OAuth token incident: an update on third-party access exposure through Salesforce-connected data. Read the original.