“MFA enabled” is one of the most common phrases in security programs. It is also one of the most misleading.

Not all MFA is phishing resistant. In fact, many common MFA deployments still fail against modern attacker workflows, including real-time phishing and adversary-in-the-middle (AiTM) techniques. The result is a dangerous gap between what teams believe they have deployed and what their authentication program actually resists.

This article explains what phishing-resistant MFA really means, how methods like FIDO2 security keys and passkeys fit into the picture, and how enterprise teams should evaluate MFA by resistance properties rather than by labels.

What “phishing-resistant MFA” means

A useful definition:

Phishing-resistant MFA is authentication designed so users cannot be tricked into providing reusable credentials to an attacker-controlled channel.

That definition matters because many MFA methods still rely on user-entered secrets:

• Passwords
• One-time codes (OTP/TOTP)
• SMS codes
• Approvals that can be manipulated through fatigue and social engineering

When users can type it, forward it, or approve it under spam, attackers can build workflows to steal or coerce it.

For a broader map of terms, see: Passwordless vs MFA vs Passkeys

Why “MFA” is not enough in 2026 threat reality

Attackers do not need to break MFA cryptographically. They exploit how MFA is used:

• Real-time phishing: capture password and OTP in one flow
• AiTM proxying: forward user actions to the legitimate service and capture sessions
• Push fatigue: spam approval prompts until the user accepts
• Recovery abuse: bypass strong login by attacking helpdesk and recovery workflows

That is why it is more accurate to ask: “Which parts of our program are phishing-resistant, and which parts are not?”

Related: How Passwordless Reduces Phishing and Credential Theft (AiTM, Replay, and Fatigue Attacks)

Which MFA methods are phishing-resistant (and which are not)

Generally not phishing-resistant

• SMS OTP: vulnerable to interception, SIM swapping, and real-time phishing
• TOTP codes from authenticator apps: can be phished and replayed in real time
• Push approvals: vulnerable to fatigue and social engineering if prompts can be spammed

These methods may still be useful as transitional baselines, but they should not be the strongest control for high-risk access.

Generally phishing-resistant (when implemented correctly)

• FIDO2 security keys: cryptographic proof and user presence, often with origin binding properties
• Passkeys (WebAuthn/FIDO-based): cryptographic credentials that reduce reliance on reusable secrets
• Smartcards in controlled environments: can be strong, though operationally heavy

The key phrase is “when implemented correctly”. An enterprise can still undermine strong authenticators with weak fallback and recovery paths.

Phishing resistance is a property of the whole program

Many teams make a critical mistake: they evaluate a factor in isolation. Attackers evaluate the whole program.

If your program has:

• Password fallback.
• OTP fallback.
• Recovery via reset links.
• Helpdesk overrides without consistent proofing then phishing-resistant authenticators are not the defining feature of your authentication system. They are an optional path.

This is why recovery is the hidden requirement of both passwordless and MFA programs.

A practical evaluation checklist for CISOs and IAM teams

Use this checklist to determine whether your MFA program is truly phishing-resistant for high-risk access:

1. Do high-risk accounts have phishing-resistant methods enforced by policy?
2. Are OTP, SMS, and push approvals restricted to low-risk tiers only?
3. Are fallbacks narrow, time-bound, and auditable?
4. Can users recover access without phishable reset links?
5. Are recovery and factor enrollment protected against helpdesk abuse?
6. Do step-up rules apply to sensitive actions, not only to initial login?
7. Do logs capture authenticator type and step-up triggers for audit evidence?

If the answer is “no” to any of these, the program is not fully phishing-resistant, even if a phishing-resistant method exists somewhere in the stack.

Where post-quantum readiness fits

Phishing resistance addresses today’s attacker workflows. But enterprise authentication programs are long-lived. If your identity stack hard-codes cryptographic assumptions, future migrations become disruptive and exceptions multiply.

Post-quantum readiness and cryptographic agility reduce that long-term risk by keeping authentication programs adaptable as standards evolve.

Conclusion: measure MFA by resistance, not by labels

Phishing-resistant MFA is not a marketing term. It is a security property that must be true end-to-end: primary login, step-up, fallback, and recovery.

If you want a practical landscape of enterprise MFA types and trade-offs, start with: Types of MFA for Enterprises.