Why do stolen tokens bypass MFA?

MFA is checked during login, but a stolen token is already proof that login succeeded. Once an attacker has that token, they can often act as the authenticated user without facing another MFA challenge. That is why session protection and token revocation matter as much as the login flow.

Why This Matters for Security Teams

Stolen tokens bypass MFA because MFA protects the authentication event, not every action that follows. If a session token, OAuth token, or API key is already valid, the attacker inherits the authenticated context and can often operate without ever seeing a login prompt. That is why token theft turns identity compromise into a post-authentication problem, not a password problem.

This failure mode is common in real incidents because tokens move outside controlled paths. NHIMG research shows that 44% of NHI tokens are exposed in the wild, often through Teams, Jira, Confluence, and code commits, while 91% of former employee tokens remain active after offboarding. Those numbers make it clear why The 52 NHI breaches Report is so relevant here: the breach is frequently the session, not the login. Current guidance from Anthropic — first AI-orchestrated cyber espionage campaign report also reinforces that autonomous and tool-using systems can amplify a single credential into broad access faster than human defenders expect. In practice, many security teams encounter token abuse only after the session has already been replayed across multiple systems.

How It Works in Practice

The key mechanic is simple: MFA is checked at issuance, then the resulting token becomes the portable proof of access. If that token is stolen from a browser cache, CI/CD log, chat thread, ticket, device, or malware-infected endpoint, the attacker can reuse it until it expires or is revoked. That is why session protection, token binding where available, and fast revocation are as important as the original login flow.

For NHI and agentic environments, the better pattern is to reduce the value and lifetime of every credential. Use JIT credentials for task-scoped access, prefer short-lived secrets over static ones, and pair them with workload identity so the system can verify what the workload is rather than trusting a copied bearer token. For agentic workflows, current guidance suggests moving toward intent-based authorisation and real-time policy evaluation, because a tool-using agent may chain actions in ways a human access review never anticipated. That is why the Salesloft OAuth token breach matters operationally: once OAuth material is stolen, the attacker can act inside the trusted session boundary rather than re-authenticating.

• Set short TTLs on access tokens and refresh tokens where the platform supports it.
• Revoke on offboarding, suspicious use, and secret exposure events, not just on schedule.
• Segment privileged workflows so one stolen token cannot reach all downstream systems.
• Use workload identity and policy-as-code to decide access at request time, not only at login.

These controls tend to break down in legacy apps, long-lived service accounts, and SaaS platforms that do not support immediate revocation or token binding.

Common Variations and Edge Cases

Tighter token controls often increase operational overhead, so organisations need to balance faster revocation against workflow reliability and support burden. That tradeoff is especially visible in SSO-backed SaaS, automation pipelines, and AI agents that depend on chained API calls.

One common edge case is that not all “MFA bypass” incidents are really bypasses. Sometimes the attacker never touches the MFA-protected login at all and instead reuses an already-issued session, a stolen API key, or a refresh token. Another nuance is that bearer tokens are not equally risky across environments: a low-privilege app token is not the same as a vault token, but either becomes high impact if it is duplicated broadly. NHIMG has documented how duplication and overuse drive this risk, and the Guide to the Secret Sprawl Challenge is a useful companion reference for understanding why secret hygiene is inseparable from identity security. For broader incident patterns, see the 52 NHI Breaches Analysis and the Dropbox Sign breach.

There is no universal standard for token revocation latency yet, so teams should define their own maximum exposure window, test it regularly, and assume any long-lived credential will eventually be replayed.

Related resources from NHI Mgmt Group

• What are the implications of using OAuth tokens in third-party integrations?
• What makes OAuth tokens risky in NHI environments?
• What common vulnerabilities do cloud applications face with OAuth tokens?
• How do attackers operationalise stolen OAuth tokens at scale?