Authentication
Phishing-resistant MFA
Authentication whose output only works for the genuine site, without relying on the user to spot the fake. How it works, what qualifies, and what it does not cover.
Most MFA can be phished. If a user can read a code off one device and type it into a web page, an attacker's look-alike page can collect it and replay it to the real site within seconds. Phishing-resistant authentication closes that gap with cryptography rather than user vigilance: the authenticator's output only works for the genuine site. This page explains the NIST definition, how adversary-in-the-middle proxies defeat other MFA, the two technical mechanisms NIST recognizes, and the US federal requirement.
What NIST means by phishing resistance
SP 800-63B-4 section 3.2.5 defines it:
In this document, phishing resistance is the ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier (i.e., an attacker fraudulently posing as the verifier) without relying on the vigilance of the claimant.
Three points follow from the text:
- It is a property of the protocol, not of the user. Training people to check the address bar helps, but it is not phishing resistance.
- How the user got to the fake site does not matter. An email link, an ad or a search result are all phishing.
- It requires cryptographic authentication. "Phishing resistance requires single- or multi-factor cryptographic authentication." Authenticators involving manual entry of an output, explicitly including OTP and out-of-band authenticators, "SHALL NOT be considered phishing-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated".
Earlier editions of SP 800-63B called this property verifier impersonation resistance. Some prior versions also used "strongly MitM-resistant". SP 800-63B-4 notes both older names.
How adversary-in-the-middle phishing works
An adversary-in-the-middle (AiTM) phishing kit is a reverse proxy on a look-alike domain. It shows the user the real site's pages, relays everything the user types, and keeps a copy, including the session cookie the real site issues at the end.
This is why the attack beats OTP, push and SMS equally. None of them carry any information about which site the user is on. With push and number matching, the proxy simply shows the user the number the real site displayed. Even "approve only if you just tried to sign in" fails, because the user did just try to sign in.
The two mechanisms NIST recognizes
SP 800-63B-4 recognizes two ways to achieve phishing resistance. Both satisfy the requirement. NIST considers channel binding "more secure than verifier name binding because it is not vulnerable to the misissuance or misappropriation of verifier certificates".
| Channel binding (§3.2.5.1) | Verifier name binding (§3.2.5.2) | |
|---|---|---|
| How it works | The protocol establishes an authenticated protected channel, then binds a channel identifier from that channel into the authenticator output, for example by signing both together. | The authenticator output is cryptographically bound to the verifier's authenticated identifier. For DNS names, that is the hostname or a parent domain at least one level below the public suffix. |
| Defeats a proxy because | The proxy's TLS connection to the real site is a different channel, so the binding does not match. | The proxy's domain is a different verifier name, so the right key is never used, or the signed data names the wrong site. |
| Example in the standard | Client-authenticated TLS. PIV and CAC cards "provide phishing resistance through channel binding". | WebAuthn, "by choosing an authenticator secret based on the authenticated domain name of the verifier". |
For WebAuthn specifically: each credential is scoped to an RP ID (a domain). The browser will only use it on pages whose origin matches that RP ID, and it writes the actual origin into the signed client data, which the server MUST verify. The details are on WebAuthn.
Implementations CISA describes
CISA's fact sheet names two families:
- FIDO/WebAuthn authentication, which CISA calls "the only widely available phishing-resistant authentication". Authenticators can be roaming (separate physical tokens connected by USB or NFC) or platform authenticators built into laptops and phones. Passkeys are FIDO credentials. See passkeys.
- PKI-based MFA, such as the smart cards used by US government agencies (PIV and CAC). CISA describes it as strong but "less widely available", requiring "highly mature identity management practices", and less widely supported without SSO.
SP 800-63B-4 also counts signed, audience-restricted assertions from a subscriber-controlled wallet on the subscriber's device as phishing-resistant (section 3.1.7.3).
The US federal requirement
OMB Memorandum M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles (January 26, 2022), section III.A.2, sets the policy for executive agencies:
- "For agency staff, contractors, and partners, phishing-resistant MFA is required."
- "For public users, phishing-resistant MFA must be an option." Public-facing systems that support MFA had to offer it within one year of the memo.
- For routine self-service access by staff, contractors and partners, agency systems "must discontinue support for authentication methods that fail to resist phishing, including protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications".
- MFA must be enforced at the application layer, not the network layer.
The memo names PIV (including Derived PIV) and W3C Web Authentication as approaches. SP 800-63B-4 (July 2025) aligns: verifiers SHALL offer at least one phishing-resistant option at AAL2, federal agencies SHALL require their staff, contractors and partners to use phishing-resistant authentication, and AAL3 SHALL use a phishing-resistant authenticator.
What phishing resistance does not cover
- Weaker fallbacks. If the sign-in page also offers SMS, push or "try another way", an AiTM proxy will steer the user there. Phishing resistance only counts if the weaker paths are removed or limited for the users who matter.
- Enrollment and recovery. An attacker who can register their own authenticator, or talk the help desk into a reset, never needs to phish the strong one. See account recovery.
- Session theft after sign-in. Malware or a stolen cookie can reuse a session that was established with phishing-resistant MFA. Session protections (short lifetimes, device-bound sessions, re-authentication for sensitive actions) are a separate layer.
- Consent and token phishing. Tricking a user into granting an OAuth application access, or into completing a device-code flow on an attacker's behalf, does not involve the authenticator at all. See device authorization and scopes and consent.
Rollout checklist
- Start with administrators and the help desk, as CISA suggests, then other high-value users.
- Register at least two phishing-resistant authenticators per person, so one loss does not force a downgrade.
- Use authentication policies that require phishing-resistant methods for privileged roles, not just allow them.
- Remove or restrict SMS, voice, OTP and push for those users. Monitor for attempts to use them.
- Protect enrollment of new authenticators with an existing phishing-resistant authenticator or an in-person or video check.
- Review legacy protocols and service paths that bypass interactive MFA entirely.
Sources
- NIST SP 800-63B-4: Authentication and Authenticator Management, NIST. Public domain (U.S. government work).
- CISA fact sheet: Implementing Phishing-Resistant MFA (October 2022), CISA. Public domain (U.S. government work).
- OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, Office of Management and Budget. Public domain (U.S. government work).