ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Phishing-resistant MFA is the only category of multi-factor authentication that still works when the user does everything wrong. That is the whole point of it. Every other form of MFA — codes, prompts, push notifications — ultimately depends on the person at the keyboard noticing that something is off, and attackers have spent a decade proving that this is not a control you can rely on.
NIST put a formal definition around it in July 2025. This guide covers what that definition actually says, which methods qualify, the two assurance levels that treat it differently, and the passkey rule that catches organisations out.
NIST Special Publication 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, was finalised in July 2025 and supersedes the 2020 edition. It defines phishing resistance as the authentication protocol’s ability to prevent authentication secrets and valid authenticator outputs from being disclosed to an impostor verifier — an attacker posing as the real service — without relying on the vigilance of the person authenticating.
That last clause is the load-bearing one. A control that works only when the user spots a lookalike domain is not phishing-resistant; it is user training with a technical veneer. The document is also explicit that how the victim arrived at the fake site is irrelevant — a poisoned search result and a malicious email are the same attack.
It follows that any authenticator requiring a human to read a value and type it somewhere cannot qualify as phishing-resistant MFA. NIST says so directly: authenticators involving manual entry of an output, such as one-time passcodes and out-of-band methods, are not phishing-resistant, because manual entry does not bind the output to the session being authenticated. An attacker relays the code and authenticates as you.
The guidelines recognise exactly two ways of achieving phishing resistance, and knowing which one you are deploying is useful when a vendor claims a product qualifies.
Channel binding establishes an authenticated protected channel with the verifier, then irreversibly binds a channel identifier from that channel into the authenticator output — typically by signing both together with a private key. An impostor cannot relay the result onto a different connection, even if it holds a valid certificate for the real site. PIV and CAC smart cards work this way, using client-authenticated TLS.
Verifier name binding cryptographically binds the authenticator output to the verifier’s identity, which for web authentication means the origin domain. The credential simply produces nothing usable when the origin does not match. This is how FIDO2 and WebAuthn credentials — security keys and passkeys — resist phishing.
Both satisfy the standard, and both count as phishing-resistant MFA. NIST regards channel binding as the stronger of the two, since it does not depend on certificates being issued correctly, but either is a legitimate route to phishing-resistant MFA.
| Method | Phishing-resistant | Why |
|---|---|---|
| FIDO2 / WebAuthn security key | Yes | Verifier name binding to the origin domain |
| Passkey (platform or roaming) | Yes | Same WebAuthn binding — but see the AAL3 rule below |
| PIV / CAC smart card | Yes | Channel binding via client-authenticated TLS |
| Certificate-based authentication | Yes | Channel binding, where properly implemented |
| Authenticator app TOTP code | No | Manual entry; output not bound to the session |
| SMS or voice one-time code | No | Manual entry, plus interception and SIM-swap exposure |
| Push approval prompt | No | Relayable; vulnerable to prompt bombing |
| Push with number matching | No | Better against fatigue attacks, still relayable |
| Email magic link | No | No binding to the session or the origin |
Number matching deserves a note because it is often sold as the fix. It meaningfully reduces accidental approvals during a prompt-bombing campaign, and it is a worthwhile improvement over a plain approve/deny prompt. It does not make push notifications phishing-resistant, because a relaying attacker simply shows the victim the number it was given.
The guidelines define three Authentication Assurance Levels, and they do not demand phishing-resistant MFA equally at each.
At AAL1, it is not required. At AAL2, it is recommended and must be available — verifiers are required to offer at least one phishing-resistant option, even though subscribers are not compelled to use it. At AAL3, it is required outright: the cryptographic authenticator must have a non-exportable private key, must provide phishing resistance, must be replay-resistant, and must demonstrate authentication intent.
The AAL2 provision is the one most commonly misread. “Must be available” is an obligation on the service, not on the user. If you operate a system assessed at AAL2, offering only TOTP and push does not satisfy it — a phishing-resistant option has to exist for those who choose it. For US federal systems the position is firmer still: agencies are required to have staff, contractors and partners use phishing-resistant authentication.
Passkeys are the reason phishing-resistant MFA finally became deployable at scale. They are also subject to a restriction that catches security teams designing for the top assurance level.
Syncable authenticators — passkeys that replicate across a user’s devices through a cloud account — require the private key to be exportable in order to sync. AAL3 requires a non-exportable private key. NIST therefore states plainly that syncable authenticators cannot be used at AAL3. Appendix B of the guidelines, which covers syncable authenticators, is normative rather than informative, so those requirements carry the same weight as the main body.
The practical consequence: synced passkeys are an excellent AAL2 answer and are genuinely phishing-resistant, but if you have systems that need AAL3, they need device-bound credentials — hardware security keys or smart cards. Deciding this early avoids a rollout that has to be partially undone.
Phishing-resistant MFA has moved out of best-practice guidance and into requirements documents:
None of these mandate FIDO2 by name. What they increasingly do is ask you to justify the authentication strength you chose against the risk, which is a question that becomes uncomfortable once a phishing-resistant option is cheap and widely supported.
It closes credential phishing, which is the single most common route into an organisation. It does not close everything, and overselling it internally creates a false sense of completion.
Session hijacking still works: an attacker who steals a valid session token after authentication has bypassed the login entirely, which is why token binding, short session lifetimes and conditional access still matter. Malware on the endpoint sits behind the authentication boundary and sees whatever the user sees. Consent phishing — tricking a user into granting an OAuth application access to their mailbox — never touches the credential at all. And help desk social engineering targets the recovery path rather than the front door.
Treat phishing-resistant MFA as removing one very large category of attack rather than as a finished programme. The controls that catch the remainder are ordinary ones: endpoint protection, restrictions on which applications may be granted consent, session policy, and an identity-verified recovery process.
The usual failure is trying to convert everyone at once and stalling on the awkward twenty percent.
Step five is where most programmes stop, and stopping there means the organisation has paid for security keys and kept the vulnerability. Where personal devices carry work credentials, make sure the enrolment expectations line up with what your BYOD policy already commits to.
No. A TOTP code from an authenticator app is manually entered, so it is not bound to the session being authenticated and can be relayed by an attacker in real time. It is better than a password alone and better than SMS, but it is not phishing-resistant MFA.
Yes. Passkeys use WebAuthn, which binds the credential to the origin domain, so a lookalike site cannot obtain a usable output. The caveat is assurance level rather than phishing: syncable passkeys cannot be used at AAL3 because syncing requires an exportable private key.
It reduces the risk from prompt fatigue and is worth enabling, but it does not make push phishing-resistant. An attacker relaying the login displays the same number to the victim, who approves it in good faith.
Usually not. Platform passkeys on managed laptops and phones cover most users at no hardware cost. Reserve physical security keys for privileged accounts, shared-device environments and anywhere you need AAL3.
Plan for it before deployment. Two registered credentials per user, plus a documented, identity-verified recovery process that does not fall back to a phishable method. Recovery is where phishing-resistant MFA deployments most often leak.
Inventory which accounts hold real power, check what protects them today, and enable a phishing-resistant option for that group first. Then work on recovery, because it is the path attackers take once the front door is closed.
Our ISO 27001 Toolkit includes the access control and authentication policy documents that record these decisions — method by system, exception handling, and the recovery process an auditor will ask to see.
Definitions and assurance-level requirements verified against NIST SP 800-63B-4, published July 2025. Checked August 2026.
August 23, 2026
August 21, 2026
August 20, 2026
August 20, 2026
