Salesforce breach lessons for connected app identity assurance

At a glance

What this is: HYPR analyses the Salesforce breach as a connected-app trust failure, where OAuth consent and token reuse created a durable access path that MFA did not stop.

Why it matters: IAM and RevOps teams need to treat connected app approvals, token scope, and reusable access as governance issues, not just login controls, because the breach path lived outside the authentication prompt.

Context

OAuth-connected apps extend trust beyond the login page. In this case, the security gap was not password strength or MFA coverage, but whether app consent and token reuse were governed as high-risk access paths inside the Salesforce ecosystem.

For IAM and identity governance teams, that matters because the control boundary shifts from user authentication to delegated authorization. When third-party apps can hold persistent tokens or broad offline scopes, the real question becomes how that access is approved, constrained, and revoked.

Key questions

Q: What breaks when OAuth consent is treated like a one-time setup step?

A: Consent turns into standing delegated access when teams stop tracking scopes, owners, and tenant-specific service principals after approval. The result is access that outlives the business need and becomes difficult to review, revoke, or explain during governance checks.

Q: Why do reusable tokens create more risk than a password reset fixes?

A: Because the token can remain valid independently of the user’s password or MFA state. A password reset does not necessarily invalidate connected app credentials, so an attacker with a stolen token may keep access until the token is explicitly revoked. That makes token lifetime and revocation the real control points.

Q: How do security teams know if app secret governance is failing?

A: Look for secrets with unusually long expiry dates, repeated re-creation of credentials, and application records that still authenticate after the original human owner has changed. If credential rotation happens but the entitlement itself remains untouched, the backdoor may survive in a different secret. Effective governance means tracking both the secret and the identity state behind it.

Q: Should IAM teams prioritise consent controls or login hardening first?

A: Consent controls should be prioritised when the breach path relies on delegated app access rather than direct account takeover. Login hardening still matters, but it does not stop a valid token from being reused. For connected apps, approval, scope, and revocation are the controls that decide whether access persists.

Technical breakdown

OAuth consent turns a login event into delegated access

OAuth does not give an app a password. It gives a third party delegated access after a user or admin approves scopes, and those scopes can persist far beyond the original session. In Salesforce-connected environments, that means the app, not the person, becomes the active bearer of access. If consent is broad or poorly reviewed, the attacker does not need to defeat MFA again. They only need a valid token with the right scope, which can be used through legitimate APIs and can survive until revocation. That is why connected app governance belongs in identity governance, not only in application security.

Practical implication: Treat OAuth consent as a privileged authorization event and review every connected app scope before approval.

Token reuse is the durable part of the breach path

API tokens and refresh tokens behave like reusable credentials. Once issued, they can keep working without another interactive login, which makes them attractive to attackers and convenient for integrations. In the breach pattern described by HYPR, stolen tokens from third-party services could be reused against Salesforce data until someone revoked them. That is a different failure mode from password theft: the issue is not initial authentication, but the lifetime and scope of delegated access. The control problem is therefore credential persistence, not just credential strength.

Practical implication: Map which integrations hold reusable tokens and shorten their lifetime wherever business operations allow it.

Deterministic identity assurance is the missing control layer

Deterministic assurance means high-risk access decisions are bound to cryptographic or verified identity signals, not to a one-time trust decision. HYPR frames phishing-resistant passkeys, domain binding, and re-verification for risky actions as the way to reduce abuse of connected apps and token flows. The technical point is broader than one vendor: if access approval can be tricked, replayed, or reused, then login assurance alone does not protect downstream authorization. Connected-app risk sits at the intersection of human approval, delegated identity, and long-lived credentials.

Practical implication: Add stronger assurance before app approval, token reset, or privilege expansion, not only at initial sign-in.

Threat narrative

Attacker objective: The objective was to maintain persistent access to Salesforce-connected data and extract valuable CRM and pipeline information without triggering normal authentication controls.

1. Entry occurred through OAuth consent phishing or compromised third-party integrations that produced a valid delegated access token.
2. The attacker then reused the token or API credential to access Salesforce data without re-entering the login flow.
3. Persistent delegated access enabled silent collection through legitimate APIs until revocation or detection interrupted the chain.

Breaches seen in the wild

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

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

Connected-app governance is now an identity governance problem, not an integration hygiene problem: the breach path existed because authorization was delegated to apps that could keep working after the original trust decision. That shifts the control surface from the login screen to consent, scope, token lifetime, and revocation discipline. Practitioners should treat every connected app as a governed identity with an access lifecycle.

OAuth consent is a privileged access event in disguise: approving an app can grant broader and longer-lived access than many human administrators realise. Once that approval exists, MFA on the primary account is no longer the decisive control because the app can act through valid tokens. The implication is that consent workflows need the same scrutiny applied to privileged access grants.

Reusable tokens create trust debt that compounds over time: every long-lived refresh token increases the amount of access that can survive a compromise, a vendor incident, or a social engineering event. This is classic NHI governance failure: access outlives the intent that created it. The named concept here is connected app trust debt: persistent delegated access that remains exploitable after the original business need changes. Practitioners should read this as a lifecycle failure, not a login failure.

Deterministic identity assurance should be the boundary for high-risk app actions: if an organization cannot bind approval, domain, and user intent to a high-risk connected app action, it is relying on hope rather than assurance. Passkeys and phishing-resistant re-verification matter because they reduce the chance that an attacker can manufacture a legitimate-looking consent path. Teams should re-evaluate where they still trust approvals that are not cryptographically or operationally anchored.

The market signal is that SaaS-to-SaaS trust is becoming a first-class attack surface: identity programmes that only cover workforce login are incomplete when business teams can create their own delegated access paths. That pressure will push governance toward app inventory, scope review, token lifetime control, and event-driven revocation. The practical conclusion is simple: if you do not govern connected apps as identities, attackers will.

What this signals

Connected app trust debt: long-lived delegated access is the real risk when business teams can approve integrations faster than governance can review them. Login assurance reduces one path, but it does not solve the lifecycle problem of tokens that remain usable after the original approval has aged out.

Identity programmes should move downstream from sign-in events and focus on delegated authorisation boundaries. That means app inventory, scope governance, and revocation triggers need to sit alongside MFA and passwordless work, because the breach surface now lives inside SaaS-to-SaaS trust chains.

For practitioners

• Inventory connected apps and delegated scopes Identify every Salesforce-connected app, the scopes it holds, whether it has offline access, and who approved it. Remove any integration that still has broad permissions without an active business owner.
• Shorten token lifetime and revoke stale access Replace permanent or effectively permanent refresh tokens with expiring credentials where the business process allows it, and revoke unused tokens on a fixed review cycle.
• Require phishing-resistant assurance before app approval Use phishing-resistant authentication and stronger proofing for administrators who can approve high-risk integrations, especially where the approval grants offline API access.
• Review consent workflows as privileged actions Treat app consent, token reset, and scope expansion as privileged events that need approval, logging, and periodic recertification rather than one-time setup.

Key takeaways

• The Salesforce breach shows that connected apps can turn OAuth consent into a persistent access path that bypasses normal login protections.
• Reusable tokens and broad scopes create governance debt because they keep working after the original approval is no longer justified.
• IAM teams should treat app consent, token lifetime, and revocation as first-class controls for Salesforce and other SaaS integrations.

Key terms

• OAuth Consent: The approval that allows an application to access resources on behalf of a user or tenant. In practice, consent can create durable access paths that outlive the original interaction if permissions are broad, unmanaged, or never reviewed. For security teams, it is both an access decision and a lifecycle event.
• Connected App: A connected app is a third-party integration that is granted access to a SaaS platform through APIs and OAuth permissions. From a governance perspective, it is an identity-bearing access path that needs ownership, scoping, and periodic review like any other non-human identity.
• Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
• Deterministic Identity Assurance: Deterministic identity assurance means verifying a requester with enough cryptographic or procedural certainty that the access decision is not based on trust or convenience. For high-risk approvals, it reduces the chance that a social-engineered request or stolen session can become lasting access.

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.