What breaks when MFA is protected by an Adversary in the Middle attack?

The factor still works, but the trust chain does not. The attacker relays the user through a fake page, captures the credentials and MFA response, and then uses the resulting authenticated session. That means the real failure is not MFA itself. It is the assumption that a successful MFA event proves the whole login journey was trustworthy.

Why This Matters for Security Teams

An adversary in the middle attack does not “break” MFA in the cryptographic sense. It breaks the assumption that a completed MFA challenge means the entire authentication journey was trustworthy. The attacker relays the victim through a fake login page, captures the live session material, and then reuses the authenticated state. That makes phishing-resistant design, session binding, and conditional access far more important than the second factor alone.

This matters because identity teams often measure success at the point of MFA completion, while attackers operate at the point of session theft. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks shows how quickly identity assumptions fail once credentials and tokens are exposed. Industry guidance increasingly aligns with CISA cyber threat advisories and the NIST Cybersecurity Framework 2.0, both of which emphasize resilient identity controls rather than single-event trust.

In practice, many security teams discover the gap only after a valid MFA prompt has already been replayed and the attacker has started using the session as if they were the real user.

How It Works in Practice

Adversary in the middle attack sit between the user and the legitimate identity provider. The attacker proxies the login flow in real time, so the victim sees a normal page, enters credentials, and completes MFA. Because the exchange is live, the attacker captures not just the password but also the authenticated session artifact, such as a cookie, token, or one-time authorization result.

That is why “MFA succeeded” is not the same as “the user is safe.” Stronger defenses focus on what can be bound to the device, channel, or session. Phishing-resistant methods such as FIDO2 and passkeys are designed to reduce relay risk because the private key never leaves the authenticator and the response is origin-bound. Where passkeys are not yet available, current guidance suggests adding step-up checks, device posture, and session risk evaluation at runtime rather than trusting a single login event.

For higher-risk environments, the practical control stack usually includes:

• Phishing-resistant MFA that resists credential and session relay
• Session binding and short token lifetimes to limit replay value
• Conditional access based on device health, location, and behavior
• Token and cookie protection to reduce theft after authentication

For broader identity context, NHI Management Group’s 52 NHI Breaches Analysis is useful because the same pattern appears in machine identity abuse: once a trusted token is stolen, the attacker does not need to “break” the original control. The control breaks because trust is reused beyond the point it was valid. These controls tend to break down in legacy SSO stacks that issue long-lived sessions without phishing-resistant binding because the attacker can replay the session faster than the environment can detect it.

Common Variations and Edge Cases

Tighter MFA and session controls often increase user friction and rollout complexity, so organisations need to balance attack resistance against support overhead and application compatibility. That tradeoff is especially visible in environments with older IdPs, device-agnostic access, or contractor-heavy workflows.

There is no universal standard for this yet, but best practice is evolving toward origin-bound authentication, token protection, and continuous risk evaluation. Some systems still rely on OTP or push approval because they are easy to deploy, but those methods are more exposed to relay, fatigue, and social engineering than phishing-resistant options. Where hardware-backed authenticators are not feasible, shorter session TTLs, reauthentication for sensitive actions, and tighter conditional access can still reduce the blast radius.

Agentic and automated environments add another edge case: a successfully stolen human session may be used to reach tools, APIs, and downstream systems that were never designed for interactive abuse. That is why frameworks such as the MITRE ATLAS adversarial AI threat matrix remain relevant even for non-AI identity incidents. For a related perspective on identity exposure, see Microsoft Midnight Blizzard breach and the broader pattern of stolen access being reused after initial compromise. The practical limit appears when a protected session can still reach high-value tools without additional proof of possession at the moment of use.

Related resources from NHI Mgmt Group

• How should security teams stop adversary-in-the-middle attacks on MFA-protected accounts?
• What is the difference between attack surface management and NHI governance?
• Why do adversary-in-the-middle attacks still work when MFA is enabled?
• What breaks when privileged chatbot access is not protected by MFA?