MFA bypass attacks expose the limits of token-based trust

At a glance

What this is: This is an analysis of how MFA bypass attacks use token theft, adversary-in-the-middle techniques, and stolen cookies to sidestep login controls.

Why it matters: It matters because IAM, PAM, and NHI teams have to treat authentication as a session problem, not just a login problem, across users, service access, and privileged workflows.

By the numbers:

• Compromised non-human identities are involved in 80% of identity breaches.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Axiad's analysis of Microsoft's warning on MFA bypass attacks

Context

MFA bypass attacks exploit a simple problem: if attackers can steal a valid session token, they do not need to defeat the password prompt again. The article focuses on how token theft, adversary-in-the-middle phishing, and pass-the-cookie tactics turn authenticated access into the real target, which is a direct IAM and session-governance issue.

For identity teams, the lesson extends beyond human users. The same trust assumptions that fail when a browser cookie is stolen also fail when privileged access, device posture, and session lifetime are treated as stable after login. That makes this a useful case study for human identity controls, privileged access workflows, and broader NHI-style thinking about runtime trust.

Key questions

Q: What breaks when attackers can steal MFA session tokens?

A: MFA stops being the control point once the attacker has a valid token or cookie. The real failure is that the session is trusted after authentication, so the attacker can reuse access without reentering credentials. Organisations need to treat token replay as an identity event, not just an endpoint or phishing problem.

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 can security teams know if session controls are working?

A: Look for shorter token reuse windows, fewer successful replays from unknown devices, and faster revocation after suspicious activity. If privileged changes still occur after an alert, the session-control layer is not aligned with the risk level of the identity.

Q: Who is accountable when stolen tokens are used to change cloud settings?

A: Accountability sits with the team that owns identity policy, privileged access design, and incident response together. If token revocation, admin separation, and tenant-change monitoring are split across teams, attackers can move faster than the response model. Governance must cover the whole session lifecycle.

Technical breakdown

Adversary-in-the-middle phishing and token capture

Adversary-in-the-middle, or AiTM, attacks place an interception layer between the user and the legitimate application. The user still completes MFA, but the attacker captures the resulting token or session artefact and reuses it. This matters because MFA verifies the user at one point in time, while the token becomes the real bearer of access afterward. Once the session is live, the attacker no longer needs the password or the second factor. The control failure is not just weak authentication, but a model that treats post-authentication tokens as trustworthy for too long.

Practical implication: shorten token usefulness and tie session validity to device and risk signals, not just initial MFA success.

Pass-the-cookie attacks on unmanaged devices

Pass-the-cookie attacks steal browser cookies from a compromised device and replay them elsewhere. Because cookies often represent an already authenticated session, the attacker inherits access without re-entering credentials. The article correctly points out that unmanaged personal devices are attractive targets because corporate controls may not extend fully to them. In practice, this is a device-trust and session-integrity problem, not just a phishing problem. If the endpoint can be compromised, the authentication outcome can be exported with it. That makes endpoint posture and browser-session protections part of identity governance.

Practical implication: condition access on managed-device posture and block sensitive sessions from unmanaged endpoints where feasible.

Privileged session exposure in cloud identity

When stolen tokens belong to Global Administrators, Billing Administrators, or Authentication Administrators, the impact jumps from account compromise to tenant control. The article’s example shows how a session token can be enough to alter security settings, privilege assignments, and directory-wide trust. In identity terms, this is a privileged-session problem: the authentication event is over, but the blast radius remains open until the token is revoked or expires. That is why privileged access must be treated as a time-bounded operational state, not a static entitlement.

Practical implication: isolate privileged identities, monitor high-risk tenant changes, and make token revocation part of incident response.

Threat narrative

Attacker objective: The attacker wants to reuse authenticated access without needing passwords or MFA challenges, then use that access to control cloud identity and sensitive applications.

1. Entry occurs through adversary-in-the-middle phishing or a compromised unmanaged device that lets attackers capture an MFA token or browser cookie.
2. Escalation follows when the stolen session is replayed to access cloud resources, and the attacker targets privileged identities such as Global Admins.
3. Impact comes from tenant hijack, unauthorized configuration changes, and extended access until tokens are revoked or expire.

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

Token-based MFA trust is the real failure point, not the second factor itself. The article shows that if an attacker can steal a valid session artefact, MFA has already done its job but the access model has not. That exposes a structural problem in identity governance: the programme is still treating authentication success as proof of continuing trust. Practitioners should read this as a session-governance failure, not a login failure.

Session lifetime becomes a privilege-risk control when identity is replayable. The longer a token remains usable, the longer an attacker can operate without reauthentication or user awareness. That makes token TTL, refresh-token handling, and revocation speed core identity controls rather than back-end implementation details. The practical conclusion is that privileged access design and session design cannot be separated anymore.

Unmanaged endpoints turn human identity into exportable access. The article makes clear that personal devices are not just weaker endpoints, they are identity transfer points where browser state can be copied and reused. That means device trust, endpoint control, and browser session policy now sit inside the identity perimeter. Practitioners should treat unmanaged-device access as a governance exception, not a convenience feature.

Privileged identities need separate operating assumptions from standard user sessions. Global admin and authentication admin access creates tenant-wide blast radius if a token is stolen. The right framing is not just stronger MFA, but a narrower trust envelope around privileged session state. That is the part of the identity model that fails first when attackers move from phishing to tenant control.

Runtime identity assurance matters more than point-in-time verification. Access can be valid, stolen, and abused within the same session window, which means the governance model has to observe device posture, token reuse, and high-risk tenant changes as one control plane. For IAM and PAM teams, this is a reminder that authentication assurance without session assurance leaves the programme exposed.

From our research:

• Compromised non-human identities are involved in 80% of identity breaches, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• That is why the 52 NHI Breaches Analysis is useful reading for teams that need breach-pattern context beyond authentication bypass alone.

What this signals

Session trust is becoming the new identity perimeter. The practical lesson from MFA bypass is that authentication alone no longer defines control. Organisations that still separate MFA, conditional access, and privileged access reviews into different workstreams will miss the fact that token replay collapses those boundaries in real time. The next programme adjustment is to treat session state, device posture, and privilege elevation as one control path, supported by NIST SP 800-207 Zero Trust Architecture.

The strongest programmes will start measuring how quickly a stolen session can be invalidated, not just whether MFA is enabled. That is a more useful indicator than control adoption because it captures whether the identity stack can still contain abuse after initial authentication. For teams with NHI sprawl as well, the issue is the same: trust must be continuously re-established, not assumed after login.

For practitioners

• Reduce token replay windows Shorten session lifetimes for high-risk applications and privileged users, then tie renewal to fresh device and risk checks instead of passive refresh behavior.
• Block unmanaged-device access to sensitive sessions Use device-based conditional access to prevent browser sessions from unmanaged personal devices reaching privileged or finance applications, especially where cookie theft is plausible.
• Separate privileged identities from everyday accounts Move administrators into dedicated cloud-only identities and keep administrative activity away from general-use browsing and email sessions.
• Monitor tenant-change events as identity indicators Alert on security configuration changes, privileged role changes, and transport rule edits because those are common signs that a stolen token is being used for follow-on abuse.

Key takeaways

• MFA bypass works because attackers target the session artefact, not the password prompt.
• Token replay, unmanaged endpoints, and privileged identities combine to create tenant-level blast radius quickly.
• Identity teams need shorter session trust windows, stronger device controls, and faster revocation to reduce exposure.

Key terms

• Adversary-in-the-middle attack: An adversary-in-the-middle attack places an attacker between a user and the legitimate service so the attacker can intercept authentication artefacts. In identity terms, the user may complete MFA successfully while the attacker captures the session token needed to continue access.
• Session token: A session token is a bearer artefact that proves an identity has already authenticated. Once stolen, it can often be replayed without re-entering credentials, which is why token lifecycle and revocation are core identity controls, not just technical plumbing.
• Conditional access: Conditional access is policy-based access control that evaluates context such as device posture, location, or risk before granting or sustaining access. In practice, it helps reduce the value of stolen tokens by making session continuation depend on current signals, not one-time login success.
• Privileged identity: A privileged identity is an account or role with elevated permissions that can change security settings, roles, or tenant configuration. When its session is compromised, the blast radius is much larger than a normal user account because the attacker can alter the control plane itself.

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.

This post draws on content published by Axiad: Microsoft's warning about how hackers are bypassing MFA. Read the original.