MFA bypass attacks expose the limits of session-based trust

At a glance

What this is: This is an analysis of MFA bypass attacks that rely on token and cookie theft rather than password compromise, with the core finding that authenticated sessions can be hijacked after MFA succeeds.

Why it matters: IAM, PAM, and NHI teams need to treat session governance, device trust, and privileged account isolation as first-class controls, because MFA alone does not stop token reuse on unmanaged endpoints.

Context

MFA reduces password risk, but it does not eliminate the value of a stolen session. Once a user or admin has authenticated, the browser token or cookie becomes the control point, and attackers can target that artefact instead of the login step.

That creates a governance gap for identity programmes that still treat authentication success as the end of the risk decision. The article focuses on token theft, adversary-in-the-middle interception, and pass-the-cookie abuse, which are especially dangerous for privileged users and cloud-admin access.

Key questions

Q: What breaks when MFA is bypassed by token theft instead of password compromise?

A: The control that breaks is the assumption that a successful sign-in proves ongoing trust. When attackers steal a session token or browser cookie, they can reuse the authenticated session without repeating MFA. That means identity teams must govern token lifetime, device trust, and session revocation, not only the login step.

Q: Why do unmanaged devices increase the risk of MFA bypass?

A: Unmanaged devices often lack the endpoint controls needed to protect browser sessions, cookies, and local token storage. If an attacker compromises the device, they can export authenticated state and reuse it elsewhere. That is why device posture must be part of access decisions for sensitive systems.

Q: How should security teams reduce the risk of browser session token theft?

A: Security teams should tighten token scope, shorten session lifetime where the business can tolerate it, and build fast revocation into identity operations. They should also assume token theft can bypass password resets, so incident playbooks must focus on invalidating active sessions and limiting what each token can reach.

Q: What is the difference between phishing-resistant MFA and session protection?

A: Phishing-resistant MFA protects the authentication event, while session protection governs what happens after login. A user can still complete a strong MFA challenge and then lose the session to token theft, cookie replay, or endpoint compromise. Teams need both controls because they defend different parts of the identity lifecycle.

Technical breakdown

How token theft bypasses MFA after login

MFA validates the login transaction, but many applications then trust a session token or browser cookie until it expires. Adversary-in-the-middle attacks capture the token at sign-in, while pass-the-cookie attacks reuse an already issued cookie from another browser or device. In both cases, the attacker does not need the password or the second factor again because the session itself becomes the credential. That shifts the security boundary from authentication strength to token handling, device hygiene, and session lifetime. If those controls are weak, MFA can be bypassed without breaking the authentication factor itself.

Practical implication: treat session tokens as sensitive credentials and limit how long they remain usable.

Why unmanaged devices widen the token theft window

Token theft becomes easier when users authenticate from personal or unmanaged devices that corporate IT cannot continuously inspect. Those endpoints often lack full patching, EDR coverage, or hardened browser controls, so stolen cookies can be harvested and replayed with little resistance. Conditional access and device-based policy help only when the organization can distinguish trusted endpoints from risky ones. The issue is not simply remote work, but the loss of control over the device that stores the session artefact. Once that artefact leaves the managed boundary, identity assurance weakens even if MFA was correctly performed.

Practical implication: tighten conditional access decisions around device posture and unmanaged endpoint use.

Why privileged sessions create outsized blast radius

A stolen token is far more damaging when it belongs to a Global Admin, Billing Admin, or Authentication Admin. Those sessions can open tenant-wide settings, privileged cloud resources, and high-value business applications without triggering a new authentication event. That is why the article’s emphasis on segregating privileged users matters: the session is not just access, it is administrative reach. In practical terms, the same bypass technique can move from nuisance to tenant compromise depending on the privilege carried by the session. Privilege scope, not just MFA strength, defines the impact.

Practical implication: isolate privileged identities and reduce the amount of administrative power in any single session.

Threat narrative

Attacker objective: The objective is to bypass MFA and use a valid session to reach privileged cloud accounts or tenant controls without triggering a fresh authentication challenge.

1. Entry occurs when the attacker intercepts or steals a valid session token or browser cookie through adversary-in-the-middle phishing or device compromise.
2. Escalation follows when the stolen session is replayed against cloud services, allowing access without re-entering the second factor.
3. Impact occurs when the attacker uses the live session to reach privileged accounts, modify tenant settings, or access high-value cloud resources.

Breaches seen in the wild

• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Session trust has become the real control plane for modern identity risk. MFA is still valuable, but it no longer closes the risk boundary if the session token or browser cookie can be stolen and replayed. The governance problem is that identity programmes often certify the login and then stop looking. Practitioners need to recognise that post-authentication trust decisions now carry as much weight as the sign-in event itself.

Privileged access becomes materially more fragile once it is delivered through reusable sessions. A stolen Global Admin token does not just confirm identity, it inherits authority for as long as the session remains viable. That creates a separate identity security problem from password compromise: the attack target is the session artefact, not the human factor. The implication is that PAM and cloud admin governance must account for session replay as a primary threat path.

Unmanaged endpoint exposure is the hidden trust gap behind many MFA bypasses. Personal devices can store the very artefacts attackers need, while security teams often lack enough telemetry to distinguish safe from unsafe browser state. Session-based trust debt: this article shows that organisations accumulate risk when authentication assurance is not matched by continuous control over the session that follows it. The practitioner conclusion is to govern the session lifecycle, not just the login.

Phishing-resistant MFA is necessary but not sufficient when tokens can be replayed. The article does not argue against stronger authentication; it shows that stronger login factors still leave a replay window if downstream session handling is weak. That is why the problem sits at the intersection of IAM, PAM, and device governance rather than inside any single control family. Teams should treat token theft as an identity governance issue, not only a phishing issue.

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

Session-based trust is now a distinct governance layer. Identity programmes that stop at MFA completion leave a gap between authentication and authorised use, which is exactly where token theft operates. Teams should map which applications, admin roles, and remote access paths still rely on long-lived browser sessions rather than continuous trust evaluation.

Privileged accounts need a narrower operational surface than standard users. If an admin session can touch tenant settings, transport rules, or broad cloud resources, then token theft becomes a tenant-governance problem rather than a simple login problem. The practical response is to reduce where privileged sessions can exist and what they can reach.

Session lifetime should be treated as an identity control, not a convenience setting. Shorter token duration, reauthentication for sensitive actions, and stronger endpoint checks all reduce the chance that a stolen artefact stays useful long enough to matter.

For practitioners

• Harden session lifetime settings Shorten browser session and refresh-token duration for high-value applications so stolen artefacts have less time to be replayed. Pair that with reauthentication for sensitive actions rather than assuming sign-in once is enough.
• Isolate privileged identities Move administrative users into separate cloud-only identities and restrict those accounts to the minimum cloud services they need. Keep Global Admin, Billing Admin, and Authentication Admin roles away from routine browsing and everyday productivity use.
• Enforce device-based conditional access Require managed device posture, patch compliance, and endpoint protection before allowing access to sensitive cloud apps. Treat unmanaged personal devices as a separate risk tier, not as equivalent endpoints with different convenience settings.
• Monitor for suspicious token activity Use identity threat detection to flag unusual token issuance, repeated high-severity alerts, and tenant changes such as new privileged users, security configuration edits, or exchange transport rule changes. After compromise, revoke refresh tokens and force reauthentication.
• Prioritise phishing-resistant MFA for critical users Require phishing-resistant MFA for administrators and users who access finance systems, PII-heavy applications, or collaboration platforms with broad data reach. This reduces the chance that the initial authentication step can be captured in an adversary-in-the-middle flow.

Key takeaways

• MFA bypass attacks succeed because the session, not the password, becomes the reusable credential after authentication.
• The article’s evidence shows that attackers can use token theft and cookie replay to reach privileged cloud resources even when MFA is enabled.
• Organisations need stronger session governance, tighter device controls, and isolated privileged identities to reduce replay risk.

Key terms

• Session-level trust: A security model that evaluates whether a live session should continue to be trusted after authentication has already succeeded. In travel and hospitality, it uses behavior, device context, and transaction signals to decide whether access should remain valid as the user moves through booking, loyalty, and support workflows.
• Adversary-in-the-middle Attack: An adversary-in-the-middle attack intercepts and relays authentication in real time between the user and the legitimate service. It is especially dangerous for OTPs because the attacker can capture the code while it is still valid and immediately use it to complete login.
• Pass-the-Cookie Attack: A pass-the-cookie attack reuses a stolen browser cookie to impersonate an already authenticated session. The attacker does not need the password if the cookie still represents a live identity state. This is especially dangerous when the cookie belongs to a privileged account or an unmanaged device.
• Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.

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 building or maturing an IAM programme, it is worth exploring.