Phishing-Resistant MFA: Why SMS Codes Aren't Enough Anymore

Multi-factor authentication used to be the thing we told clients would stop credential-based breaches. In 2026, we've stopped saying that about most forms of it. Real-time phishing kits now defeat SMS codes, app push notifications, and even TOTP apps in the time it takes a user to read an email — and we've watched it happen inside client environments.

The MFA You Have Probably Isn't Working

Here's the pattern we keep seeing in incident response engagements: an employee gets a well-crafted phishing email, clicks through to a login page that looks identical to Okta or Microsoft 365, and enters their username and password. The page also asks for their MFA code — and because the attacker's proxy server is relaying that request to the real login page in real time, whatever code the employee enters (SMS, TOTP, even a push approval) gets captured and replayed before it expires.

This is called an adversary-in-the-middle (AiTM) attack, and toolkits that automate it — Evilginx and its many forks are the most common — are now widely available. They don't need to break MFA. They just need to sit between the user and the real site long enough to steal a valid session token. Once they have that, your MFA policy is irrelevant; they're already authenticated.

Why "We Have MFA Enabled" Isn't a Security Posture

Most compliance frameworks and cyber insurance questionnaires still just ask "is MFA enabled?" — a yes/no question that treats an SMS code and a hardware security key as equivalent controls. They are not. The difference is whether the factor is bound to the specific site the user is talking to, or whether it's just a number the user can be tricked into handing over.

Phishing-resistant MFA isn't a stronger version of MFA. It's a fundamentally different mechanism — one where the credential itself can't be phished because it's cryptographically tied to the real domain, not to whatever the user was shown.

What "Phishing-Resistant" Actually Means

The industry has largely converged on FIDO2/WebAuthn as the standard for phishing-resistant authentication. The mechanism that matters is origin binding: the cryptographic key exchange only completes if the browser and the authenticator agree they're talking to the legitimate, registered domain. A lookalike phishing page — no matter how convincing it looks to a human — fails the exchange automatically, because the domain doesn't match. No user judgment call required.

MFA Method	Phishing-Resistant?	Why
SMS / voice code	No	Code is just a number; user can be tricked into relaying it
TOTP app (Google Authenticator, etc.)	No	Same problem — a 6-digit code has no idea what site it's being entered into
Push notification (no number match)	No	User taps "approve" from habit; attacker triggers the prompt
Push with number matching	Partial	Better, but still relies on the user comparing numbers correctly under pressure
FIDO2 / WebAuthn passkeys	Yes	Origin-bound cryptographic exchange; a mismatched domain fails silently
Hardware security keys (YubiKey, etc.)	Yes	Same FIDO2 mechanism, in a dedicated device

What We're Recommending in Client Engagements

For every identity and access management engagement we've run since late 2025, phishing-resistant MFA has moved from "recommended" to the default starting point. In practice, that looks like:

• Passkeys as the primary factor — device-bound or synced FIDO2 passkeys (Windows Hello, Touch ID, or a platform authenticator) for the majority of users, since there's no hardware to procure or lose.
• Hardware keys for privileged accounts — admins, finance, and anyone with standing access to production systems get physical security keys as a non-negotiable, not an option.
• Okta FastPass or Verify with number matching as the bridge — for organizations mid-rollout, Okta's phishing-resistant push option closes the gap while passkey enrollment finishes.
• Killing legacy fallback factors — SMS and email-based recovery codes stay enabled far longer than IT teams realize, and attackers know to ask for them. We audit and disable fallback methods as part of every rollout, not as a follow-up task.
• Conditional access tied to device trust — pairing phishing-resistant MFA with device posture checks so a stolen session token from an unmanaged device still gets blocked downstream.

The Rollout Problem Nobody Mentions in the Vendor Pitch

The technology isn't the hard part. The hard part is that passkey enrollment requires a moment of friction — a user has to register a device — and mid-market IT teams rarely have the headcount to walk every employee through it individually. The rollouts that succeed treat this as a change-management project with a security component, not a security project with a training slide. That means phased enrollment by risk tier, a help desk script for the inevitable "I lost my phone" calls, and executive sponsorship before the first email goes out — not after adoption stalls at 40%.

The organizations that skip this step end up with phishing-resistant MFA available but not enforced, which — from an attacker's perspective — is functionally the same as not having it at all.