Why Traditional MFA Still Loses to Adversary-in-the-Middle Attacks

Multi-factor authentication (MFA) remains one of the most useful upgrades over passwords alone. It blocks most automated stuffing and many simple phishing pages that only harvest a password. But it is not phishing-proof. In April 2026, the UK National Cyber Security Centre (NCSC) compared traditional MFA with FIDO2 credentials and passkeys for personal use and found a clear gap: adversary-in-the-middle (AitM) phishing still defeats passwords plus SMS, TOTP, push approvals, or email codes, while FIDO2 does not.

This article explains that gap in practical terms, and why moving high-value accounts to passkeys matters more than adding another SMS code.

MFA Fixed Stuffing — Not Phishing Proxies

Credential stuffing works because people reuse passwords. Once a password leaks from one breach, attackers try it on email, banks, shopping sites, and cloud accounts. A second factor stops that pattern: the stolen password is not enough.

That success created a misleading mental model. Many people heard that MFA “stops phishing.” Against a static fake login page that only captures a password, MFA often helps. Against a live phishing proxy that sits between you and the real site, traditional MFA usually fails. Industry reports often cite MFA as blocking the vast majority of automated account-takeover attempts; that figure describes stuffing and low-sophistication theft, not AitM session theft.

How Adversary-in-the-Middle Phishing Works

In an AitM attack, the victim lands on a lookalike site controlled by the attacker. That site is not a simple form dump. It is a reverse proxy that forwards every request to the real service in real time.

You enter your username and password. The proxy sends them to the real site. The real site asks for a second factor. You type the SMS code, authenticator code, email OTP, or approve a push prompt. The proxy forwards that too. Once the real site issues a session cookie or token, the attacker copies it and takes over the authenticated session—often without needing your password again.

• The attacker does not need to “break” MFA cryptography. They wait for you to complete a valid login.
• The stolen artifact is usually the session cookie or bearer token, not just the password.
• Tools such as Evilginx-style proxies made this tradecraft widely available to criminals.

Why SMS, TOTP, Push Approvals, and Email OTP All Fail Against AitM

These second factors prove that someone who can receive a message, read a rotating code, or tap “Approve” was involved. They do not prove that the browser talking to the real website is yours.

• SMS OTP: the code is a short shared secret. If you type it into a proxied page, the attacker receives a working login.
• Authenticator TOTP: same problem. The six-digit code is valid for both the real site and the phishing proxy for a short window.
• Push approvals: approving “Was this you?” completes the attacker’s login unless the prompt includes strong number matching and you carefully check the source.
• Email OTP: another relayable code. If the attacker already has your password and can coerce the second step, email delivery does not bind the login to the real origin.

Fatigue Attacks and SIM-Swap as Secondary Traditional-MFA Failures

AitM is not the only way traditional MFA fails. Fatigue attacks hammer push notifications until someone accepts one to stop the noise. SIM-swap and SMS interception steal codes before they reach you.

The NCSC comparison treats these as additional reasons traditional MFA is weaker than FIDO2 across the credential lifecycle. Even if you never click a phishing link, push fatigue and SIM abuse remain realistic personal threats.

• Push fatigue succeeds because “Approve” is easy and the prompt often lacks clear context.
• SIM-swap targets the phone number that receives SMS codes, not the password itself.
• These failures reinforce the same lesson as AitM: a factor that can be coerced, relayed, or redirected is not phishing-resistant.

Why FIDO2 and Passkeys Resist AitM

FIDO2 / WebAuthn credentials—including passkeys—are bound to the real website origin. Your authenticator will not complete a ceremony for evil-bank.example when the credential belongs to bank.example.

The private key never leaves the authenticator (or the protected sync fabric for synced passkeys). The site receives a signature over a challenge that includes origin information, not a reusable secret you can type into a proxy.

That is why the NCSC table marks adversary-in-the-middle phishing as always successful against traditional MFA and never successful against FIDO2 credentials for the personal-use threat model they assessed.

• Origin binding stops credential use on lookalike domains.
• No short OTP exists for the attacker to relay in real time.
• Session theft via proxied 2SV completion is not the same attack path.

The Transition Trap: MFA Downgrade While Passwords Remain as Fallback

Even when a service supports passkeys, many accounts still keep a password plus weaker MFA as backup. Attackers know this. MFA downgrade attacks steer the victim toward the weaker path: password reset, “sign in another way,” SMS instead of security key, or a recovery flow that never presents the passkey prompt.

During the long coexistence of passwords and passkeys, the weakest allowed path often decides the real security level. Enrolling a passkey helps only if you also resist downgrade UX and treat recovery options as carefully as the primary login.

What to Do Now

You do not need to wait for every website to go passwordless. Prioritize the accounts that unlock everything else, then harden the rest.

• Prefer passkeys or security keys for email, password manager, banking, cloud, and developer accounts. Start with our passkeys guide.
• Where push MFA remains, use number matching and treat unexpected prompts as hostile.
• Avoid SMS as a primary second factor when a better option exists.
• Until an account supports passkeys, use a unique long password from a password manager—stuffing still thrives on reuse.
• Review recovery options so “forgot password” or “try another method” cannot silently erase phishing resistance.