Phishing-resistant multi-factor authentication

Phishing-resistant multi-factor authentication (MFA) uses cryptography to make a sign-in response work only with the real service or its secure connection. This makes it much harder for a fake login page to steal the response and reuse it. Passkeys, security keys, and some smart-card credentials use this approach.

It protects the sign-in step, but not account recovery, malware-infected devices, or sessions stolen after login. Pair it with secure recovery, device protection, and safeguards for active sessions.

How phishing-resistant MFA blocks phishing

A phishing page can imitate a familiar service and forward information to the real one. For example, someone might enter a password and one-time code on the fake page. The attacker can then quickly send both to the real service.

Phishing-resistant authentication stops this kind of relay by using cryptography to make sign-in responses specific to the service. With WebAuthn, the web authentication standard used by passkeys and security keys, the browser and authenticator associate the response with the service’s web address. A credential registered for the genuine site therefore does not work on a look-alike domain. Credentials based on public key infrastructure (PKI), such as smart cards, can instead bind authentication to the secure communication channel.

The National Institute of Standards and Technology (NIST) defines phishing resistance as preventing a fake service that checks sign-ins from obtaining valid responses. This protection does not depend on the user noticing the deception. A short-lived code is still vulnerable to real-time relay, even if it expires quickly.

Passkeys, security keys, and smart cards

Passkeys and FIDO2 security keys use WebAuthn, a standard for web authentication. A passkey is a cryptographic credential stored on a device or, in many cases, synced between devices through a provider’s account. A security key is a separate physical authenticator. Both can protect against fake-site credential theft when correctly supported by the service.

PIV and CAC smart cards are examples of PKI-based credentials used in some government and enterprise environments. They can provide phishing-resistant authentication through channel binding. Their deployment requires supporting services and identity-management infrastructure.

NIST’s current guidance classifies one-time-password methods and push-based out-of-band authentication as not phishing-resistant. A number-matching prompt can help users catch some deceptive requests, but it does not provide the cryptographic verifier binding that defines phishing resistance.

When phishing-resistant sign-in counts as MFA

Phishing resistance and MFA describe different properties. Phishing resistance concerns whether a response can be stolen and reused at a fake site. MFA concerns whether a sign-in uses more than one type of proof, such as something you have and something you know or are.

NIST classifies a passkey as multi-factor cryptographic authentication when the user verifies their identity with a PIN or biometric check. Without that check, NIST classifies it as single-factor cryptographic authentication. A security key also needs the right configuration and user-verification step to meet a particular MFA requirement.

Organizations that must meet a specific security standard need to check these details. NIST’s Digital Identity Guidelines require covered services at Authentication Assurance Level 2 (AAL2) to offer at least one phishing-resistant option. At Authentication Assurance Level 3 (AAL3), the private key must not be exportable, meaning it cannot be copied out, and the authentication must resist phishing. These requirements apply only in the contexts covered by the guidelines; they do not automatically govern every consumer account.

Limits of phishing-resistant MFA

Phishing-resistant authentication protects the exchange used to sign in. It does not stop an attacker from stealing a session token, a digital credential that keeps a user signed in, or from using a compromised device. With a stolen token, an attacker can access a service without completing the sign-in challenge again.

If a service lets someone bypass a passkey with a phishable code or an easily manipulated recovery process, that weaker path can undo much of the protection. In a 2021 USENIX Security study of FIDO recovery and alternative-factor flows, 55% of participants fell for a specific attack that steered them to a weaker sign-in method. Another 35% were considered potentially susceptible to the attack in practice. Those results describe the study’s scenario and participants, not all passkey users or current services.

Plan recovery with the same care as ordinary sign-in. Check which methods can restore access if a device is lost, and whether those methods offer weaker protection than the passkey. Where the service supports it, keeping another registered authenticator can reduce dependence on a weak emergency route. Restrict fallback methods when practical, and protect recovery channels such as email accounts with strong authentication.

Syncing passkeys can make it easier to restore access when a device is lost. NIST permits authenticators that sync between devices for some AAL2 uses when they meet the relevant requirements. But synced keys can be copied between devices, so they do not meet AAL3’s requirement that the key cannot be exported. Organizations with higher assurance needs should check whether the credential’s storage and sync behavior meets their rules.

Plan a phishing-resistant MFA rollout

Start by checking which services support WebAuthn or PKI credentials and how they handle recovery. Then test sign-in from the devices and browsers people actually use. A credential that works on one device may not work smoothly on every device or with every legacy service.

Make the stronger method the normal sign-in path, while reviewing every alternative route for account access. Explain how users should enroll an authenticator and recognize a legitimate recovery request. Also tell them what to do if they lose a device. For organizational accounts, pair strong sign-in with device security and session controls. Add checks for sensitive actions.

NIST’s assurance requirements provide a useful decision point: organizations covered by AAL2 rules need to offer a phishing-resistant option, while AAL3 requires a non-exportable key. For other accounts, the practical choice depends on the services in use, the devices available, and the security of recovery.

Evidence on usability and phishing resistance

A five-week field study at one mid-sized IT company compared FIDO2 security keys with passwords plus time-based one-time passwords among 34 employees. Biometric security keys reduced login time by nearly five seconds, and employees reported higher satisfaction with both biometric and PIN-based keys. PIN-based keys were not significantly faster. The study also found hardware compatibility and broader workflow complexity to be concerns. Its small sample and single-company setting limit how widely the results apply.

The UK National Cyber Security Centre’s comparison found that FIDO2 credentials resisted credential harvesting and credential stuffing. They also resisted phishing attacks that intercept and relay messages between a user and a service. The analysis covered personal-use accounts. The paper cautions that it had not formally assessed whether the same results apply to organizational settings, including those involving personal devices and older access methods.

The evidence shows that phishing-resistant authentication protects the sign-in step, but it does not show how much wider use reduces account compromise. Strong authentication protects an important point of exposure. Its effectiveness still depends on how services handle recovery, fallback methods, devices, and sessions.