Phishing-resistant MFA: why passkeys beat codes and push prompts

"Turn on MFA" is good advice, and you should follow it. But it hides a detail that matters a lot: some kinds of multi-factor authentication stop a well-made phishing page, and some don't. A six-digit code that you type into a fake login page is just as useful to the attacker as it is to you.

CISA says it plainly in its fact sheet on implementing phishing-resistant MFA (October 2022): not all forms of MFA are equally secure, and yet any form of MFA is better than none. This post works through the questions I'd want answered if I were choosing a second factor today, for myself or for a team. Each answer links to the standard or guidance it comes from.

Q: What counts as a "factor"?

A factor is a kind of proof. CISA's fact sheet defines MFA as presenting two or more different authenticators: something you know, something you have, or something you are (CISA).

Two passwords are still one factor. And NIST's current authentication guideline, SP 800-63B-4 (final, July 2025), adds a point people often miss: a biometric is not an authenticator by itself. It has to be paired with a physical authenticator, such as the phone or key that does the matching.

The useful question is not "how many factors?" but "what can an attacker do with what I hand over?" That's where the methods start to differ.

Q: How do attackers get past SMS codes and push prompts?

There are a few well-documented routes. CISA lists four threats to MFA: phishing, push bombing, abuse of SS7 weaknesses in the phone network, and SIM swapping (CISA).

Route 1: just ask for the code

The plainest attack is a fake login page. CISA's own example: a user gets an email, visits a site that mimics the company's login portal, and types in their username, password and the six-digit code from their authenticator app. Anyone holding all three can try them on the real site before the code expires.

A more polished version puts a proxy in the middle. Microsoft described a large campaign of this kind in 2022: the phishing site sits between the user and the real sign-in page, so it looks identical, and it captures both the password and the session cookie issued after MFA succeeds. With that cookie the attacker can skip sign-in altogether. Microsoft notes this is not a flaw in MFA itself; the attacker simply steals the session that MFA produced (Microsoft Security blog). MITRE ATT&CK files this position under Adversary-in-the-Middle (T1557), and notes that it can be used to grab credentials, including access tokens and session cookies.

Route 2: wear the user down

If the attacker already has the password, and the account uses "tap to approve" push notifications, they can just keep signing in. Each attempt sends a prompt to the victim's phone. MITRE calls this Multi-Factor Authentication Request Generation (T1621): adversaries flood a user with push notifications, SMS messages or calls until the user eventually accepts one, which ATT&CK calls "MFA fatigue". It lists groups such as APT29, LAPSUS$ and Scattered Spider among those using it.

CISA's number-matching fact sheet describes attackers generating hundreds of prompts in a short time. A tired person might tap "Approve" just to make it stop, or assume one of them must be real.

                                  ┌───────────────────────────┐ 
  ATTACKER'S BROWSER              │ PLAIN PUSH            ▮▮▯ │ 
┌────────────────────────────┐    │───────────────────────────│ 
│ login.example.com          │    │                           │ 
│────────────────────────────│    │                           │ 
│ user  ✓  password ✓        │    │                           │ 
│                            │    │                           │ 
│ waiting for approval       │    │                           │ 
│                            │    │                           │ 
│                            │    │                           │ 
└────────────────────────────┘    │                           │ 
                                  │                           │ 
                                  │                           │ 
                                  │                           │ 
                                  │                           │ 
                                  └───────────────────────────┘ 

The fix shown in the second half of the animation is number matching. The sign-in screen shows a number, and you must type it into the app to approve. CISA explains why that helps: you can't approve a request without access to the login screen (CISA). In Microsoft Authenticator, number matching is enabled for all push notifications and users can't opt out.

Number matching beats push bombing, but not a proxy phishing page. If you are looking at the attacker's copy of the login page, it can show you the real number, and you'll type it in.

Route 3: take over the phone number

Codes sent by text message or voice call add two more risks. CISA describes SS7 abuse, where weaknesses in the telecom signalling network are used to obtain codes sent by SMS or voice, and SIM swapping, where an attacker talks a carrier into moving your number to their SIM (CISA). CISA says SMS and voice should only be a last-resort option, though they can serve as a temporary solution while moving to stronger MFA. NIST SP 800-63B-4 treats the phone network for out-of-band codes as a "restricted" method and says verifiers should consider risk indicators, such as a SIM change or number porting, before using it (SP 800-63B-4).

Q: So what is "phishing-resistant" MFA?

NIST's definition is the clearest one I know. Phishing resistance is the ability of the authentication protocol to stop secrets and valid outputs from being revealed to an impostor site, without relying on the user being careful (SP 800-63B-4, §3.2.5). That last part is the whole idea. The same section says that anything where you manually type an output, such as an OTP or an out-of-band code, shall not be considered phishing-resistant.

CISA ranks MFA methods from strongest to weakest (CISA):

CISA also notes that FIDO/WebAuthn is the only widely available phishing-resistant option. PKI-based methods, like the smart cards used by US government staff, are strong but need mature identity management and aren't as widely supported. Passkeys are the FIDO kind, so let's look at how they work.

Q: What is a passkey, and how does it know the real site?

The FIDO Alliance describes a passkey as a password replacement built on the FIDO2 standards, WebAuthn and CTAP. You unlock it the way you unlock your device: a fingerprint, a face scan, a PIN or a pattern. Under the hood it's a key pair. The private key stays with you; the website stores only the public key. Signing in is a challenge and response: the site sends a fresh random challenge, your device signs it, and the site checks the signature with the public key it holds. Your biometric never leaves the device (FIDO Alliance; Microsoft Learn).

The part that stops phishing is how WebAuthn scopes each credential. The WebAuthn Level 3 specification (a W3C Recommendation since 25 August 2026) gives every credential a Relying Party ID, which is a domain name. The browser lets a page use a credential only if that ID equals the page's own domain or is a registrable suffix of it. The spec's example: a site at login.example.com may use the RP ID login.example.com or example.com, but not com.

So imagine a passkey with the RP ID example.com, created at login.example.com, and a phishing page at login.examp1e.co:

                                                                
                                      ┌───────────────────────┐ 
 ┌───────────┐                        │  login.examp1e.co     │ 
 │ PASSKEY   │                        o                       │ 
 │───────────│                        │  look-alike           │ 
 │         · │                        └───────────────────────┘ 
 │ for:      │                                                  
 │ example   │                                                  
 │    .com   │ o━┑                                              
 │ ·  ·      │                        ┌───────────────────────┐ 
 │    ·  ·   │                        │  login.example.com    │ 
 │ face/PIN  │                        o                       │ 
 │   [ ]     │                        │  [ lock ]             │ 
 └───────────┘                        └───────────────────────┘ 
                                                                
                                                                

On the look-alike, the browser simply has no passkey for that name, so there is nothing to type, approve or leak. You don't have to notice the 1 in place of the l. The protocol notices for you.

There's a second check on the server side. The browser puts the page's origin into the signed client data, and the spec says the site must validate it and must not accept unexpected values (WebAuthn §13.4.9). The authenticator data also carries a hash of the RP ID, which the site checks against its own (WebAuthn §7). A proxy can forward bytes back and forth, but it can't make a signature that says "I was made for the real origin" when the browser saw a different one. NIST calls this property verifier name binding and names WebAuthn as its example (SP 800-63B-4). Microsoft's docs call it verifier impersonation resistance: the authenticator only releases a response to the site the passkey was registered with.

Q: Synced or device-bound: which kind should I use?

There are two flavours (FIDO Alliance; Microsoft Learn):

• Synced passkeys are copied between your devices by a passkey provider, such as Apple iCloud Keychain or Google Password Manager. FIDO says this sync is end-to-end encrypted. WebAuthn calls these multi-device credentials and marks them with "backup eligible" and "backup state" flags that a site can read (WebAuthn §6.1).
• Device-bound passkeys never leave one device. Hardware security keys are the typical example, and FIDO describes them as offering the highest assurance. They also make a handy recovery credential if you lose access to your synced devices.

Both kinds are phishing-resistant, because the origin check is the same. The differences are about who else could reach the key:

The NIST row comes from SP 800-63B-4, which allows syncable authenticators at AAL2 but says they shall not be used at AAL3, where the private key must be non-exportable (SP 800-63B-4). Microsoft's guidance follows the same line: hardware security keys (or passkeys in Microsoft Authenticator) for highly regulated industries and privileged users, and synced passkeys for most other people (Microsoft Learn).

My take: for personal accounts, a synced passkey is a big step up from a password plus SMS. For admin accounts, use a device-bound key.

Q: How do I start?

For your own accounts:

1. Start with your email account. It resets everything else. CISA's MFA page also lists financial services, social media, online stores, and gaming and streaming services as places to turn MFA on.
2. Where a service offers passkeys, create one. Where it doesn't, use an authenticator app over SMS.
3. Register a second way in, like a passkey on another device or a security key, before you need it.
4. Treat any approval prompt you didn't start as an alarm, not a nuisance. Deny it and change your password.

For an organisation:

1. Take inventory. Which systems hold the most valuable data, and which users have the most access? CISA points to email, file servers, remote access systems and identity servers as common targets, and to system administrators, attorneys and HR staff as high-value users (CISA).
2. Begin where support is easy. CISA notes that most hosted mail and SSO systems support FIDO, and suggests IT and help-desk staff as a first group.
3. Turn on number matching for any push-based MFA you can't replace yet, and limit how many prompts can be sent in a period of time (MITRE T1621).
4. Pair it with conditional access policies that also weigh signals such as device status and IP location, so a stolen session cookie is harder to use from somewhere else (Microsoft Security blog).
5. Retire SMS as a fallback where you can. A strong front door doesn't help much if the recovery door next to it is weak.

The short answer

Codes and push prompts make an attacker's job harder, and they're far better than a password alone. But they depend on a person spotting a fake page or refusing the twentieth prompt at midnight. Passkeys and other FIDO/WebAuthn authenticators move that judgement out of human hands and into the browser, which checks the site's name every single time. Use what you have today, and move toward passkeys as your services allow it.

Sources

• CISA: Implementing Phishing-Resistant MFA (fact sheet, October 2022)
• CISA: Implementing Number Matching in MFA Applications (fact sheet, October 2022)
• CISA: More than a Password (MFA)
• MITRE ATT&CK: T1621 Multi-Factor Authentication Request Generation
• MITRE ATT&CK: T1557 Adversary-in-the-Middle
• NIST SP 800-63B-4: Authentication and Authenticator Management (publication record)
• W3C: Web Authentication Level 3
• FIDO Alliance: Passkeys
• Microsoft Learn: Passkeys (FIDO2) in Microsoft Entra ID
• Microsoft Learn: Number matching in Authenticator push notifications
• Microsoft Security blog: From cookie theft to BEC (AiTM phishing, July 2022)