Phishing-Resistant MFA: Why Your Current MFA Probably Is Not Enough

TL;DR

Turning on multi-factor authentication (MFA) was the right move, but attackers have caught up with the common types. SMS codes, authenticator app codes, and push prompts can all be stolen, intercepted, or spammed until someone taps “approve” by mistake. Phishing-resistant MFA is the class of MFA that a fake login page physically cannot steal, because the credential is cryptographically tied to the real website. In practice that means passkeys, FIDO2 security keys, and Windows Hello for Business.

• Most MFA is phishable. A convincing fake login page can relay your code or push in real time and steal your logged-in session.
• Phishing-resistant MFA cannot be relayed: the credential only works on the genuine site, so a fake one gets nothing.
• What to actually use: passkeys and FIDO2 security keys for people, Windows Hello for Business on Windows PCs.
• Start with your admins. They are the highest-value targets; put them on phishing-resistant MFA first, then roll it out to everyone and retire SMS.

Now for the more technical explanation

The problem: “we have MFA” is not the finish line

MFA dramatically cut account takeovers, so attackers adapted. The weakness in most MFA is that the second factor is a shared secret or an approval that can be captured or coaxed out of you in real time. The main attacks:

• Adversary-in-the-middle (AiTM) phishing. This is the big one. A phishing site sits between you and the real login, proxying the whole thing. You enter your password and your MFA code on the fake page, it forwards them to the real site instantly, and it steals the resulting session cookie. Now the attacker is logged in as you and your MFA never mattered. Ready-made kits automate this.
• MFA fatigue (push bombing). The attacker has your password and hammers you with push prompts until, out of annoyance or confusion, you approve one. Several high-profile breaches started exactly this way.
• SMS interception and SIM swapping. Text-message codes can be intercepted, and an attacker who social-engineers your mobile carrier into moving your number to their SIM receives your codes directly.
• One-time codes are just short-lived secrets. A code from an authenticator app or an email is still something you can be tricked into typing into the wrong box.

The common thread: all of these factors can be relayed. If you can read a code or tap approve, so can a fake site standing between you and the real one.

What is phishing-resistant MFA?

Phishing-resistant MFA removes the thing that can be relayed. Instead of a code you type, the credential is a cryptographic key pair bound to the specific website, and it proves possession without ever revealing a secret.

• The private key lives on your device (or a security key) and never leaves it.
• Authentication is bound to the real domain (this is the crucial part). Your credential for login.realsite.com simply will not respond to login.realsite.evil.com. The browser and the authenticator enforce the origin, so an AiTM proxy has nothing to relay.
• There is no code to read, no prompt to fatigue, so push bombing and code phishing both fall away.

This is the FIDO2 / WebAuthn standard, and it is what powers passkeys, security keys, and Windows Hello for Business.

The MFA ladder, worst to best

A quick mental ranking, weakest first:

1. SMS / voice codes (SIM-swappable, interceptable). Better than nothing, but retire these.
2. Email codes (only as strong as the email account, which is often the thing you are trying to protect).
3. Authenticator app codes / TOTP (not relayed automatically, but still phishable if you type them into a fake site).
4. Push approval (convenient, but vulnerable to fatigue/bombing).
5. Number-matching push (you type a number shown on the login screen into the app). A real improvement that kills blind approval and push bombing, and worth enabling everywhere as a baseline. But it is still phishable via AiTM, so it is a strong stopgap, not the destination.
6. Phishing-resistant: passkeys, FIDO2 security keys, Windows Hello for Business, certificate-based. This is the goal.

Getting everyone to at least number matching is a good baseline. Getting your high-value accounts to level 6 is the win.

What to actually deploy

• Passkeys. A passkey is a FIDO2 credential stored on your phone, laptop, or security key, unlocked with your fingerprint, face, or device PIN. Device-bound passkeys stay on one device; synced passkeys roam across your devices through a platform account, which is more convenient but means your platform account security matters. For most users, passkeys are the sweet spot of strong and usable.
• FIDO2 hardware security keys (for example YubiKeys). A physical key you tap. The gold standard for administrators, executives, and anyone high-value, because the credential cannot be extracted and there is no synced copy to worry about. Issue two per person (one primary, one backup).
• Windows Hello for Business (WHfB). On a Windows PC, WHfB turns the sign-in you already do (PIN or biometric) into a phishing-resistant credential backed by the device TPM (trusted platform module). For a Windows fleet it is often the lowest-friction path to phishing-resistant MFA, because users are already doing it. It pairs naturally with the device-compliance approach from the Conditional Access guide.

Enforcing it (this ties into Conditional Access)

Deploying the credentials is only half the job; you have to require them, or people will keep using the weaker factor. In Microsoft 365 / Entra:

• Use authentication strengths in Conditional Access to require a phishing-resistant method for the accounts that matter.
• Do your admins first. Require phishing-resistant MFA for every privileged role before you touch anyone else. This is the single highest-value control you can turn on.
• Then extend to all users, and remove the weak methods (disable SMS and voice as MFA options) so they cannot be used or socially engineered back into play.
• Keep your break-glass emergency accounts configured and excluded per the Conditional Access guide, with their own strong protection and a tested recovery path, so a policy change never locks you out.

The weak link everyone forgets: recovery

Attackers do not attack the strong door; they attack the fallback. Your phishing-resistant rollout is only as strong as what happens when someone loses their key or phone.

• If your help desk can reset MFA on a phone call with weak identity checks, that reset process is your MFA, and it is phishable by social engineering. Tighten it.
• Register at least two credentials per person (a passkey plus a backup security key, for instance) so a lost device is an inconvenience, not a lockout that forces a weak recovery.
• Treat account-recovery flows as part of the security design, not an afterthought.

A sensible rollout

1. Baseline now: turn on number matching for everyone to kill push bombing, and start disabling SMS/voice.
2. Admins next: issue hardware security keys to every privileged account and require phishing-resistant MFA for those roles in Conditional Access.
3. Everyone else: roll out passkeys (and Windows Hello for Business on managed PCs), register a backup credential per user, then require phishing-resistant methods broadly.
4. Close the back doors: remove weak MFA methods and tighten help-desk recovery so nobody can downgrade around your new controls.

The short version

Having MFA is no longer the same as being protected, because push prompts, SMS, and app codes can all be relayed by a real-time phishing proxy or spammed until someone approves. Phishing-resistant MFA (passkeys, FIDO2 security keys, and Windows Hello for Business) fixes this by binding the credential to the real website so a fake one gets nothing. Deploy it, enforce it with Conditional Access authentication strengths, start with your admins, register backups, and shut the weak methods and soft recovery paths that let attackers go around it.

Related

• Conditional Access baseline policies (enforce authentication strengths and device compliance)

Written by Tom Langston, IT Infrastructure and Cybersecurity.