Why do legacy MFA methods fail against adversary-in-the-middle attacks?

Why Legacy MFA Still Fails Under Real-Time Relay Attacks

Legacy MFA often answers the wrong question. It verifies that a person approved a prompt or entered a code, but adversary-in-the-middle tooling can proxy the entire sign-in flow and capture the live session after MFA succeeds. That means the attacker does not need to defeat the second factor directly; they only need to reuse the authenticated session token before it expires or is bound to a stronger context.

This is why current guidance increasingly emphasises phishing-resistant authentication and session protections rather than codes alone. NIST guidance on phishing-resistant methods and the broader NIST AI Risk Management Framework both reinforce the need to control not just login approval, but the conditions under which access is issued and maintained. For identity risk patterns that show how exposed credentials and sessions get abused in the wild, NHIMG research such as the 52 NHI Breaches Analysis and Microsoft Midnight Blizzard breach show how quickly attackers operationalise stolen access once they have a foothold.

In practice, many security teams discover MFA weakness only after a valid session has already been replayed from an attacker-controlled endpoint, rather than through intentional testing of relay-resistant controls.

What Actually Stops Adversary-in-the-Middle Abuse

Stopping this class of attack requires stronger binding between the authenticator, the device, and the session. Phishing-resistant MFA methods such as FIDO2/WebAuthn reduce relay risk because the cryptographic assertion is tied to the real origin and challenge, not just a code that can be forwarded. Session controls matter just as much: short-lived tokens, re-authentication for sensitive actions, token binding where supported, and device posture checks all help limit reuse after a proxy succeeds.

Security teams should also separate primary authentication from continuous authorisation. A login event is not proof that the session remains trustworthy throughout its lifetime. That distinction is highlighted in standards and threat research from the CISA cyber threat advisories and the MITRE ATLAS adversarial AI threat matrix, where tool-enabled abuse and credential theft are treated as operationally different from simple password compromise. NHIMG’s OWASP NHI Top 10 also reflects a broader pattern: identities fail when the system trusts a single approval event instead of the full access path.

• Prefer phishing-resistant MFA over OTPs and push approvals for high-risk access.
• Bind sessions to device or hardware-backed proof where possible.
• Reduce token lifetime and revoke on anomaly, not only on logout.
• Re-check risk for privileged actions, not just at sign-in.

These controls tend to break down in legacy SSO estates where token binding is unavailable and long-lived browser sessions are shared across unmanaged devices.

Common Variations and Edge Cases Security Teams Miss

Tighter authentication often increases user friction and operational overhead, requiring organisations to balance usability against the reduced relay risk. That tradeoff is real, especially where contractors, BYOD, or service desks depend on older sign-in flows.

There is no universal standard for this yet, but current guidance suggests treating push approvals and SMS OTPs as weak for any sensitive workload, while reserving stronger authenticators for admin access, remote access, and financially exposed applications. Hardware keys are not a silver bullet if the browser session is still long-lived, and some environments still need compensating controls such as conditional access, impossible-travel alerts, or step-up prompts for high-value transactions.

NHIMG’s Ultimate Guide to NHIs - Key Challenges and Risks and Top 10 NHI Issues are useful reminders that identity compromise often becomes a session governance problem, not just an authentication problem. That distinction matters when attackers use a relay proxy, a compromised device, or a trusted helpdesk flow to bypass the human-centered assumptions inside legacy MFA.

Related resources from NHI Mgmt Group

• Why do phishing-resistant methods still fail against man-in-the-middle attacks?
• Why do traditional MFA methods fail against phishing attacks?
• Why do OTP and push approvals fail against adversary-in-the-middle attacks?
• Why do legacy MFA controls fail against support-led attacks?