MFA Is Not Enough: Bypass Techniques and Phishing-Resistant MFA

Enabling multi-factor authentication remains one of the highest-value security decisions an organisation can make. It is also increasingly treated as a solved problem, which it is not. Attackers have adapted, and the difference between MFA that resists phishing and MFA that does not is now one of the more consequential distinctions in identity security.

How MFA gets bypassed

• Real-time phishing proxies — the victim authenticates through an attacker-controlled site that relays every step to the genuine service instantly. The one-time code is used within seconds, and the attacker captures the resulting session. This defeats SMS, email and app-generated codes alike.
• Session token theft — stealing the post-authentication session cookie, through malware or the proxy above, so the attacker never needs to authenticate at all.
• Push fatigue — repeatedly triggering approval prompts until the user approves one to stop the interruption, sometimes combined with a call impersonating IT support.
• SIM swapping — taking control of the phone number to receive SMS codes.
• Help-desk social engineering — persuading support staff to reset or register a new factor, which bypasses the technology entirely.
• Legacy protocol fallback — using an older authentication path that does not enforce the second factor.
• Self-service registration abuse — enrolling an attacker-controlled factor on an account whose password has already been compromised.

Why phishing-resistant factors differ

FIDO2 and WebAuthn credentials — including passkeys and hardware security keys — work on a fundamentally different principle. The credential is a key pair bound to a specific origin, and the authenticator will only sign a challenge for the site it was registered to.

That property is what defeats the real-time proxy. A user tricked into visiting a lookalike domain simply cannot complete authentication, because the authenticator refuses to sign for the wrong origin. There is no code for the user to read out and no secret to relay. The resistance is structural rather than dependent on the user noticing anything.

A realistic ranking of factors

1. FIDO2 / WebAuthn hardware keys and device-bound passkeys — phishing-resistant by design. The strongest widely available option.
2. Platform authenticators using biometrics with device binding — strong for most threat models.
3. Push notification with number matching and context — meaningfully better than plain push, since it defeats blind approval, though still not phishing-resistant.
4. Authenticator app codes — better than SMS, still relayable through a proxy.
5. Plain push approval — vulnerable to fatigue attacks.
6. SMS and email codes — weakest, but still far better than no second factor at all.

Deploying it without breaking everything

Rolling out phishing-resistant authentication rarely fails on technology; it fails on the edges — shared accounts, legacy applications, contractors and recovery flows.

Start with the accounts that matter most: administrators, finance, and anyone with access to sensitive data. Register at least two authenticators per user so a lost device does not force a weak recovery path. Then close the gaps that make the strong factor optional: disable legacy authentication protocols, block fallback to weaker factors for privileged roles, and harden the help-desk reset process with identity verification that cannot be satisfied by information found on a public profile.

Recovery deserves particular attention. An account protected by a hardware key but recoverable through an SMS code is only as strong as the SMS.

Detection still matters

• Alert on repeated denied or ignored MFA prompts, which is the signature of a fatigue attack.
• Monitor new authenticator registrations, especially soon after a password change.
• Watch for authentication using legacy protocols that bypass modern controls.
• Look for session anomalies such as impossible travel or a token used from an unexpected location.
• Treat help-desk factor resets as auditable security events rather than routine support tickets.

Related from TechBiz Security

• Security awareness training
• Security audits
• SOC services

Sources & further reading

• CISA — Implementing Phishing-Resistant MFA
• NIST SP 800-63B — Digital Identity Guidelines, Authentication
• FIDO Alliance — Passkeys
• W3C — Web Authentication (WebAuthn)

Frequently asked questions