What is phishing-resistant MFA, and why codes and push prompts don't count
A six-digit code can be typed into a fake page and passed along within seconds. A passkey won't work on the wrong site. That one difference is the whole idea.
When r/cybersecurity discussed how people actually stay safe from phishing these days, the top answer skipped email tips altogether: phishing-resistant MFA, conditional access rules and a password manager, so you don't enter credentials yourself. It's a good answer, because it removes the need to spot anything.
"Phishing-resistant" has a specific meaning, though, and most two-factor methods don't meet it.
The definition
NIST's digital identity guidelines (SP 800-63B-4) define phishing resistance as the ability of the authentication protocol to prevent the disclosure of authentication secrets, without depending on the person's vigilance. That last part is what matters. If security relies on you noticing a fake, it isn't phishing-resistant.
NIST recognizes two ways to do this: binding the login to the verified name of the site (WebAuthn and FIDO2, which includes passkeys), and binding it to the secure connection itself (such as client-certificate login with PIV and CAC smart cards). NIST is blunt about what's left out. Authenticators that involve manually entering an output don't qualify, "OTP authentication is not phishing-resistant," and neither is out-of-band authentication.
Why a fake site can't use a passkey
Here's the attack that this stops, known as adversary-in-the-middle:
- You click a link and land on
login-rnicrosoft.com, a proxy that shows you the real Microsoft page, passed through live. - You type your password. The proxy passes it on to Microsoft.
- Microsoft asks for your code. You type it, and the proxy passes that on too.
- Microsoft issues a session cookie. The proxy keeps it. The attacker is now logged in as you, and your MFA did its job perfectly.
With a passkey, step 3 fails. When your device signs a login, it includes the domain the browser is actually on. The passkey for microsoft.com doesn't exist for login-rnicrosoft.com, so the device offers nothing. Even if something were signed, it would name the wrong site and Microsoft would reject it. You could be completely fooled and still not lose the account.
How each method stacks up
| Method | Phishing-resistant? | The weakness |
|---|---|---|
| Password only | No | Anything typed can be stolen |
| SMS or voice code | No | Relayed through a fake page, or stolen through a SIM swap |
| Authenticator app code (TOTP) | No | Typed by hand, so it can be relayed in real time |
| Push approval | No | "Approve" fatigue, covered in our MFA fatigue post |
| Push with number matching | No, but better | Stops blind approvals, but a proxy can still show you the number |
| Passkey (WebAuthn / FIDO2) | Yes | Account recovery and fallback methods |
| Hardware security key (FIDO2) | Yes | Cost, and losing the key |
| Smart card (PIV / CAC) | Yes | Needs infrastructure to run |
CISA calls phishing-resistant MFA the gold standard. Any MFA is still far better than none. If an authenticator app is all a service supports, use it.
Are synced passkeys good enough?
For almost everyone, yes. Passkeys synced through Apple, Google, Microsoft or a password manager are still bound to the site, so they resist phishing just the same. The difference is where the key lives. NIST says syncable authenticators "SHALL NOT be used at AAL3," its highest assurance level, because the private key must be exportable. Regulated environments and top administrators may therefore need device-bound keys or hardware. For everyone else, a synced passkey is a big upgrade, and it's less likely to lock you out.
What it won't stop
Be clear on the limits, because attackers already have been:
- The weakest fallback wins. If an account allows a passkey or an SMS code, the attacker will go for the SMS code. In one recent campaign, attackers talked people into enrolling the attacker's passkey over the phone. Remove the weak methods once people have moved, and protect the enrollment process.
- Consent phishing. OAuth consent attacks get you to approve a malicious app with your real login on the real site. No password is stolen, so a passkey doesn't help.
- Stolen sessions. Malware on your device can take the session cookie after you've signed in. See can an extension steal my login session?
- Everything that isn't a login. Fake invoices, payment requests, card-skimming shops and "run this command" pages don't need your login at all.
Where to start
For yourself: add a passkey to your main email account first, since it can reset nearly everything else. Then your password manager, then your bank if it offers one. Keep your recovery codes offline, and register a second device or key.
For an organization: CISA suggests a phased rollout that starts with the highest-value targets, such as email, file servers and remote access, and with executives and privileged users. It warns that a compromised system administrator's account may give an attacker access to any system and any data. In practice:
- Admins and help desk staff first, because they're the keys to everything else.
- Finance, HR, executives and anyone who keeps failing phishing tests.
- Everyone else, then disable weaker methods. Conditional access can require a phishing-resistant method for sensitive apps.
- Harden recovery. A help desk that resets MFA over the phone is the next target, as the help-desk vishing attacks show.
Where a browser warning still helps
Many sites still don't offer passkeys, and you'll still have accounts that rely on a password. PhishClean checks where a password field really sends what you type, and warns on lookalike domains, on your device. It's a backstop for the accounts you can't yet protect this way, not a replacement for a passkey.
Frequently asked questions
What is phishing-resistant MFA?
Multi-factor authentication that doesn't depend on you spotting a fake. The login is cryptographically bound to the real site or to the secure connection, so a phishing site gets nothing it can reuse. Passkeys, FIDO2 security keys and smart cards qualify.
Is an authenticator app phishing-resistant?
No. NIST says OTP authentication is not phishing-resistant, because you type the code by hand and a fake site can relay it in real time. An app is still much better than a password alone.
Are passkeys phishing-resistant?
Yes. A passkey is tied to the domain it was created for, so it won't work on a lookalike site. Synced passkeys keep this property, although NIST doesn't allow syncable authenticators at its highest assurance level, AAL3.
Can phishing-resistant MFA be bypassed?
Not by tricking you into using it on a fake site. But attackers can target weaker fallback methods, account recovery, OAuth consent or session cookies stolen by malware, so those need attention too.
Sources
- NIST SP 800-63B-4: Authentication and authenticator management
- Cybersecurity Dive: CISA on phishing-resistant MFA (summarizes CISA's fact sheet)
- CISA: Implementing phishing-resistant MFA (fact sheet)
A backstop for every other account
Not every site offers passkeys yet. PhishClean warns when a page is a lookalike or sends your password somewhere unexpected.
Install PhishClean freeLast updated: