Token theft bypasses MFA by turning bearer tokens into access

At a glance

What this is: Token theft turns post-login OAuth and session tokens into replayable access, bypassing MFA and other front-door authentication controls.

Why it matters: IAM, PAM, and NHI teams need to treat tokens as bearer credentials with their own lifecycle, because compromise can persist after login, password reset, or MFA invalidation.

By the numbers:

• AiTM phishing attacks increased 146% over the past year.
• Token theft accounted for 31% of Microsoft 365 breaches in 2025.

Context

Token theft is a bearer-token problem, not a password problem. Once a user has authenticated and the system issues an OAuth token or session cookie, that token becomes the access mechanism until it expires or is revoked.

That changes the governance model for IAM and NHI programmes. MFA still matters at login, but it does not govern what happens when stolen tokens are replayed, refreshed, or inherited through SaaS integrations.

Obsidian Security's analysis focuses on why authentication-centric controls miss the real attack surface: the lifecycle of tokens, the visibility of token use, and the trust placed in already-issued credentials.

Key questions

Q: What breaks when OAuth tokens are stolen through a legitimate login flow?

A: Password-based phishing controls lose much of their value because the victim authenticates on real infrastructure and the attacker captures the token instead of a password. The result is reusable access that can outlast the session and support inbox compromise, so organisations need controls for token issuance, scope, and revocation.

Q: Why do refresh tokens make token theft harder to contain than password theft?

A: Refresh tokens can mint new access tokens long after passwords are changed or MFA is reset. That means incident response based only on credential resets leaves a surviving access path in place. Containment must include explicit token revocation and confirmation that delegated grants, sessions, and refresh chains are actually closed.

Q: How should security teams detect token theft without relying on failed login alerts?

A: Use behavioural signals such as location shifts, ASN changes, User-Agent changes, impossible session combinations, and unusual data-access volume. Stolen tokens usually generate successful authentication events, so the signal is in how the token is used after issuance. This is where session analytics and identity threat detection become essential.

Q: When is MFA no longer enough to protect SaaS and cloud access?

A: MFA is necessary at login, but it is not sufficient once bearer tokens, OAuth grants, and refresh paths exist. If your environment relies on long-lived sessions, delegated integrations, or third-party apps, then post-login token governance becomes the control that actually limits abuse. Strong authentication and strong session governance must work together.

Technical breakdown

Why bearer tokens bypass MFA

OAuth access tokens, refresh tokens, and session cookies act as bearer credentials. The system authorises whoever presents the token, not whoever originally authenticated, so MFA is only enforced at issuance time. In practice, that means a stolen token can be replayed from a different device, network, or geography without generating a new authentication challenge. The security failure is structural: the access decision has moved from interactive identity proofing to token possession and validity checks.

Practical implication: Design controls around token possession and replay risk, not only around initial login assurance.

How attackers steal and replay tokens

Attackers obtain tokens through AiTM phishing, malware, browser compromise, device code abuse, or supply-chain exposure. Once acquired, the token can be validated, enumerated for scope, and replayed against SaaS apps, APIs, and cloud services. Refresh tokens are especially dangerous because they can mint new access tokens without user interaction, extending access far beyond the original login event. This is why token theft often looks like legitimate activity in authentication logs.

Practical implication: Instrument token issuance, usage, and refresh activity so anomalous replay stands out even when login events look normal.

Why traditional incident response misses token persistence

Password resets, MFA device removal, and user logout can stop credential theft, but they do not reliably invalidate every stolen token. If refresh tokens or delegated grants remain active, attackers can keep generating new access tokens after the account owner believes the incident is contained. That makes token hygiene and explicit revocation part of containment, not just post-incident cleanup.

Practical implication: Treat token revocation as a containment control and verify that refresh paths are actually closed.

Threat narrative

Attacker objective: The attacker wants durable access to SaaS and cloud resources without re-entering credentials or triggering MFA.

1. Entry occurs through AiTM phishing, browser compromise, malware, or a compromised third-party integration that exposes already-issued tokens.
2. Credential access happens when the attacker captures OAuth tokens, session cookies, or refresh tokens that the target service will accept as valid.
3. Escalation and lateral movement follow when the attacker replays the token against connected SaaS apps, APIs, or downstream integrations that trust inherited access.
4. Impact arrives as persistent, low-friction access for data theft, delegated abuse, or supply-chain spread across customer environments.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

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

Token lifecycle, not authentication success, is now the decisive control surface: MFA proves identity at login, but bearer tokens move the trust decision to possession and validity. That means the real governance problem is whether organisations can see, bind, revoke, and re-evaluate tokens after issuance. The practical conclusion is that authentication assurance and access assurance are no longer the same thing.

Bearer tokens create identity blast radius across connected SaaS estates: one stolen token can unlock not just a primary application but also delegated access through trusted integrations. This is why token abuse scales faster than password compromise and why single-sign-on visibility is not the same as token visibility. Practitioners need to treat integration trust as a separate control plane, not as a by-product of SSO.

Refresh-token persistence is a governance gap, not just a technical nuisance: password resets and MFA invalidation assume the attacker still depends on user credentials. Refresh tokens break that assumption by regenerating access after the original session should have ended. The implication is that revocation, expiration, and re-issuance rules must be governed as part of identity lifecycle, not incident aftercare.

Token-based attacks expose the limits of logon-centric security models: traditional telemetry optimises for failed authentication and impossible travel, yet stolen tokens often produce successful logins from seemingly normal sessions. That shifts detection toward behaviour, scope drift, and unusual API consumption. Practitioners should regard token abuse as an access-governance problem that happens after authentication has already succeeded.

Identity programmes need token-aware control objectives, not just stronger MFA: the article reinforces that phishing-resistant authentication reduces one path into token theft but does not remove the replay problem once a valid bearer token exists. The stronger position is that organisations must align session management, conditional access, and token revocation around bearer risk, because MFA alone cannot govern post-login abuse.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Token replay is the access-control problem that MFA cannot see: security programmes that still optimise for authentication events will miss the real control failure, which happens after the token is issued. The next maturity step is to govern token issuance, usage, and revocation as first-class identity controls.

Identity blast radius now extends through integrations: once a token is replayed into one SaaS app, connected grants can propagate access into other services without another login event. That makes delegated trust and integration scope part of the access model, not a separate application concern.

For practitioners

• Audit OAuth grants and delegated access Inventory third-party OAuth grants, service connections, and high-scope integrations. Remove unused grants, narrow scopes where possible, and review which tokens can access customer data or downstream systems.
• Implement behavioural detection for token replay Monitor IP deviation, User-Agent changes, geolocation anomalies, bulk downloads, and unusual API call patterns because stolen tokens often look like valid sessions.
• Shorten token exposure with explicit revocation checks Verify that logout, password reset, MFA reset, and account suspension actually invalidate active refresh paths and token stores across major applications.
• Bind high-risk sessions to device signals Use device-bound or phishing-resistant controls for privileged access so a stolen token cannot be replayed cleanly from a different endpoint.

Key takeaways

• Token theft succeeds because bearer tokens remain valid after authentication, so the compromise is in post-login access rather than password cracking.
• The article shows why behavioural detection matters, since stolen tokens often look like successful sessions instead of failed logins.
• The control gap is token governance: organisations need explicit revocation, scope review, and replay detection to limit abuse.

Key terms

• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
• 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.
• Adversary-in-the-middle phishing: A phishing method that places an attacker between the user and the real identity provider so the attacker can intercept or relay the authenticated session. It often preserves the user experience, which is why it can evade awareness and some detection paths while still producing usable session tokens.
• Token Replay: Token replay is the reuse of a valid access or refresh token by someone other than the intended client. The token may still be unexpired and cryptographically correct, so the compromise often shows up only through context anomalies such as location, device, or session overlap.

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.