Salesforce breach lessons for connected app identity assurance

At a glance

What this is: This is an analysis of how the Salesforce breach exposed OAuth trust and token reuse as the real identity failure in connected app access.

Why it matters: It matters because RevOps, IAM, and security teams have to govern connected app access, reusable secrets, and phishing-resistant authentication across human, NHI, and delegated access paths.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read HYPR's analysis of the Salesforce breach and connected app identity risk

Context

OAuth trust models let users and admins approve access to connected apps without treating the app itself as a security boundary. In practice, that means the system can be working exactly as designed while still allowing attackers to turn consent, tokens, and delegated access into a durable foothold.

For identity programmes, this is not just an application security problem. It sits at the intersection of human approval flows, NHI token governance, and the control assumptions behind least privilege, re-consent, and phishing-resistant authentication.

The article's starting position is typical for modern SaaS-heavy environments: business teams value speed, and security often arrives after the integration is already live. That is why OAuth abuse keeps surfacing as an IAM problem rather than a simple login problem.

Key questions

Q: How should security teams govern OAuth consent for connected apps?

A: Security teams should treat OAuth consent as a privileged access grant, not a normal user click. That means reviewing scopes before approval, limiting offline access, logging each consent event, and requiring step-up verification for broad or sensitive permissions. If a connected app can reach CRM data or automate actions, it needs governance equivalent to other high-risk access paths.

Q: Why do token reuse and refresh tokens create so much risk in SaaS integrations?

A: Token reuse is risky because bearer tokens act as proof of access by possession. If an attacker steals a valid token, they can act as the integration until revocation or expiry, often without triggering login controls. Refresh tokens make that persistence longer, so teams must manage them as living credentials with strict scope and lifecycle controls.

Q: What breaks when organisations secure logins but ignore app approvals?

A: What breaks is the assumption that MFA on the login page is enough to control access. Attackers can bypass the login layer by persuading an admin to approve a malicious app or by reusing a stolen token from a trusted integration. In both cases, the app approval path becomes the real control failure.

Q: Who is accountable when a connected app grants unauthorised access to data?

A: Accountability usually spans the business owner who approved the app, the IAM or security team that defined the control model, and the vendor or integration owner that exposed the token path. For regulated environments, that shared accountability should be documented in access review, offboarding, and incident response procedures.

Technical breakdown

OAuth consent as an access grant, not a login event

OAuth does not authenticate the connected app in the same way a passwordless or MFA login authenticates a person. Instead, the user or admin grants the app permission scopes, and those scopes can outlive the session that approved them. That changes the risk model: the attacker does not need to defeat the primary login if they can obtain a valid consented token path. In connected app environments, the dangerous asset is often the token or refresh token, not the account password.

Practical implication: treat app consent as privileged access and require stronger approval controls before granting broad scopes.

Why token reuse turns third-party integrations into silent access paths

API and OAuth tokens function like bearer credentials. Whoever holds the token can call the API until the token is revoked or expires, which makes them high-value NHI secrets even when issued through a human workflow. When a third-party integration is compromised, the attacker can inherit trusted access without triggering the normal login controls. That is why connected apps, vendor integrations, and refresh tokens should be governed as living credentials, not static configuration.

Practical implication: inventory all persistent tokens and reduce their scope, lifetime, and placement outside secret stores.

Deterministic identity assurance for high-risk app approvals

The article frames a broader shift away from trust-based approval toward deterministic assurance. In practice, that means validating the person behind a sensitive request with phishing-resistant authentication and step-up identity proofing before permitting app installation, token reset, or privileged consent. This is especially relevant where help desk workflows, RevOps operations, and admin approvals intersect, because attackers often target the human process rather than the cryptography.

Practical implication: require phishing-resistant re-verification before any high-risk connected app approval or token reset.

Threat narrative

Attacker objective: The attacker objective was durable access to Salesforce data and connected app sessions without having to defeat the primary authentication layer.

1. Entry began when attackers used vishing or compromised third-party integrations to obtain OAuth consent or token material for Salesforce-connected apps.
2. Escalation occurred when the stolen OAuth or API tokens were reused as valid bearer credentials, bypassing MFA and normal login controls.
3. Impact followed through persistent, silent access to CRM data via legitimate APIs, enabling exfiltration without touching the login page.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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

NHI Mgmt Group analysis

OAuth consent is the real trust boundary failure in connected app security. The Salesforce breach shows that security teams often protect the login event while leaving the authorization event under-governed. In a consent-driven model, the app itself becomes the security boundary, and that boundary is only as strong as the approval process that grants scopes. Practitioners should treat consent workflows as privileged access decisions, not routine UX clicks.

Bearer token reuse is an NHI governance problem disguised as application convenience. Once an OAuth or API token is issued, it behaves like a non-human identity credential with standing access until revocation. That means lifecycle controls, scope governance, and offboarding discipline matter just as much for connected apps as they do for service accounts. Organisations that do not govern tokens as identities are leaving persistent access paths in place long after the original business need has changed.

Deterministic identity assurance is becoming the control that separates legitimate admin action from attacker-driven consent abuse. The article's core lesson is that phishing-resistant authentication alone is not enough if high-risk requests can still be approved through weak human processes. High-risk app approvals need proof of the requester, proof of the device, and proof of the action context before the grant is accepted. Teams should re-evaluate whether their approval model can actually distinguish a real operator from a social-engineered one.

Identity blast radius is now defined by the broadest connected app, not the strongest login policy. A single over-permissioned integration can expose CRM data, refresh tokens, and downstream workflows even when password hygiene and MFA are strong. That widens the attack surface from account compromise to delegated access compromise, which is why least privilege must be applied at the scope level. The practitioner conclusion is simple: every connected app expands the blast radius unless its permissions are continuously trimmed.

Unsecured consent and token persistence are the named failure modes this breach exposes. The article makes clear that the attacker did not need to break authentication if they could exploit an approval path that granted durable access. That assumption, that access is safe because the login is protected, fails the moment the actor is an approved app or reused token. The implication is that connected app governance has to be built around approval trust, not just user identity assurance.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which explains why token persistence remains a recurring failure mode.
• The broader pattern is visible in 52 NHI Breaches Analysis, where reuse, standing access, and poor offboarding repeatedly turn credentials into breach accelerants.

What this signals

Identity blast radius: connected app governance is now one of the fastest ways to measure whether an identity programme still assumes trust at the edge. As connected workflows multiply, every broad consent grant increases the number of places where token persistence can outlive business need. Teams that can continuously trim scopes, rotate credentials, and prove approval context will shrink the damage a single integration can do.

The practical signal is that SaaS access review is no longer only about users and roles. RevOps, IAM, and PAM teams need a shared control model for app approvals, token lifetimes, and vendor offboarding, because the breach path crosses all three. The organisations that move first will be the ones that treat connected apps as governed identities rather than convenient plumbing.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the governance problem extends beyond Salesforce. That means the same review discipline used for connected apps should also cover every place tokens, keys, and certificates can be created, copied, or reused. If the lifecycle is invisible, the attack path is already open.

For practitioners

• Review connected app consent scopes Inventory every Salesforce-connected app, identify offline access and broad permissions, and remove any scope that is not required for a documented business process. Pay special attention to refresh tokens and full-access grants that outlive the original approval.
• Treat OAuth approvals as privileged events Require security review or step-up approval for new connected apps, scope expansions, and token resets. If an approval can expose CRM data or automate workflows, it should follow the same control path as other high-risk access grants.
• Replace reusable trust with phishing-resistant verification Use FIDO2 passkeys or equivalent phishing-resistant controls for administrators and operators who can approve integrations, reset tokens, or grant delegated access. Tie those approvals to device-bound verification so token theft cannot be the only path to persistence.
• Instrument token lifecycle offboarding Build revocation checks into vendor offboarding, app retirement, and permission review cycles so stale tokens do not keep working after the business relationship changes. The goal is to remove access before a compromised integration can be reused.

Key takeaways

• The Salesforce breach exposed consent and token reuse as the true identity weaknesses, not passwords or MFA on their own.
• The scale of NHI exposure is already high, with compromised non-human identities accounting for most identity breaches in NHIMG research.
• Teams should govern connected apps as privileged identities, with scope review, phishing-resistant approval, and token lifecycle control.

Key terms

• OAuth Consent: OAuth consent is the permission grant that lets a connected app act on a user's or admin's behalf. In identity terms, it is an authorization decision, not a login event, and it can create persistent access if scopes, lifetimes, and revocation are not tightly governed.
• Bearer Token: A bearer token is a credential that authorizes whoever possesses it to call an API or service. Because it proves access by possession, it must be treated like a secret and governed with strict scope, expiry, storage, and revocation controls.
• Connected App: A connected app is a third-party or internal application that integrates with a platform through delegated access. It often receives tokens or scopes that persist beyond a single session, which makes app governance a core identity control rather than a purely application-level concern.
• 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

OAuth consent abuse and connected app governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team manages CRM integrations, delegated access, or token lifecycle risk, it is worth exploring.

This post draws on content published by HYPR: The Salesforce Breach Is Every RevOps Leader’s Nightmare: How to Secure Connected Apps. Read the original.