Account security · Guidelines

What is phishing-resistant MFA? Definition, and why OTPs don't qualify

7 min read

Key points

  • Phishing resistance means authentication secrets and valid outputs aren't handed to an impostor, and NIST names verifier name binding and channel binding as the ways to get there.
  • SMS and one-time codes that users type in can be relayed through a fake site, so they don't qualify. FIDO / WebAuthn (passkeys) and PKI do.
  • Fallback methods, enrollment, and recovery that stay weak become the attacker's way in.

Phishing-resistant MFA is multi-factor authentication that doesn't hand authentication secrets or valid results to an attacker, even when the user is fooled by a fake site. NIST SP 800-63B-4 counts methods that bind the authenticator's output to the real verifier's name (its domain) as phishing-resistant and names WebAuthn as an example. SMS and app one-time codes that users type in can be entered into a fake site just as easily, so they are not considered phishing-resistant. In Japan, the Japan Securities Dealers Association revised its guideline in October 2025 to require phishing-resistant MFA for important operations such as sign-in.

Definition

NIST SP 800-63B-4 defines phishing resistance as "the ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier." It recognizes two ways to achieve it:

  • Channel binding: cryptographically binding the authenticator output to an identifier of the communication channel
  • Verifier name binding: cryptographically binding the authenticator output to a verifier identifier (such as a domain name) that is authenticated as part of the protocol

For the latter, NIST cites WebAuthn, used by FIDO2 authenticators, as a standard that provides phishing resistance by choosing the authenticator secret based on the verifier's authenticated domain name.

The same document says authenticators that involve manually entering the output, such as OTP and out-of-band codes, shall not be considered phishing-resistant, because manual entry doesn't bind the output to the session being authenticated.

How one-time codes get phished

A typical attack through a fake site goes like this:

  1. The user opens a fake login page and enters their username and password.
  2. The attacker forwards them to the real site.
  3. The real site asks for a one-time code by SMS or app.
  4. The fake site shows the same prompt, and the user types the code.
  5. The attacker enters the code on the real site and is signed in.

Even if a code is valid only briefly, an automated relay is fast enough. CISA's fact sheet gives exactly this example: a fake portal that collects the username, password, and the 6-digit code from an authenticator app.

With a passkey, step 4 can't happen. The browser checks the fake site's domain, the authenticator has no key for the fake RP ID, and no signature for the real site is produced. There is also no string for the user to copy.

Where each method stands

In its October 2022 fact sheet, CISA ranks MFA from strongest to weakest:

Method Weaknesses CISA lists
Phishing-resistant MFA (FIDO / WebAuthn, PKI) Resistant to phishing. Push bombing, SS7, and SIM swap don't apply
App-based OTP, push with number matching, token-based OTP Vulnerable to phishing. Resistant to push bombing
Push without number matching Vulnerable to push bombing and user error
SMS or voice Vulnerable to phishing, SS7, and SIM swap. Use only as a last resort

CISA calls phishing-resistant MFA "the gold standard" and says FIDO/WebAuthn is the only widely available phishing-resistant authentication (as of 2022). For small and medium-sized businesses that can't adopt it immediately, it names app- or token-based OTP and push with number matching as the best options. It also says any form of MFA is better than none.

Is a passkey really multi-factor?

A passkey takes a single gesture, so it may not look multi-factor. The FIDO Alliance explains that passkeys are kept on a user's devices (something the user has) and, if the RP requests user verification, can only be exercised with a biometric or PIN (something the user is or knows). If your server requests user verification and checks the result, one gesture satisfies two factors.

On the server, you check the UV (User Verified) flag in the authenticator data. Setting WebAuthn's userVerification to required rejects authentications without user verification. With preferred, authenticators that can't verify the user still pass, so for operations you treat as multi-factor, check the UV flag.

How guidelines treat it

NIST SP 800-63B-4 (United States)

NIST SP 800-63B-4, revised in August 2025, requires phishing-resistant authenticators at the highest assurance level (AAL3). At AAL2, credential service providers must offer subscribers at least one phishing-resistant authenticator.

CISA (United States)

CISA strongly urges all organizations to implement phishing-resistant MFA and notes that the Office of Management and Budget requires federal agencies to adopt it.

Japan Securities Dealers Association (Japan)

On October 15, 2025, the Japan Securities Dealers Association put into effect a revision of its guideline on preventing unauthorized access in internet trading. It requires implementing phishing-resistant MFA (for example passkey-based or PKI-based authentication) and making it mandatory by default for important operations such as sign-in, withdrawals, and changes to the withdrawal bank account. For customers who turn it off because, for example, they lack a suitable device, firms must provide alternative MFA and track the opt-out rate with the goal of lowering it.

Gaps that remain

Adding a phishing-resistant method doesn't help if other doors stay weak. Attackers will use them.

  • Fallback methods: If an SMS code also works, attackers will steer users to the SMS prompt. The more important the operation, the fewer fallbacks you should allow.
  • Enrollment: If an attacker who signed in with a stolen password can register their own passkey, they become indistinguishable from the user. Require existing MFA or re-authentication before enrollment.
  • Recovery: If an email link alone lets someone register a new passkey, a mailbox takeover is enough.
  • Sessions after sign-in: Phishing resistance is a property of the authentication moment. It doesn't protect a session cookie stolen after sign-in. Combine it with re-authentication before important operations and good session management.

A practical rollout

  1. Offer passkeys as an option alongside your existing MFA.
  2. Use passkeys for re-authentication before sensitive operations such as withdrawals or contact changes.
  3. For users with a passkey, stop showing weaker fallbacks by default.
  4. Track the share of users who can't use passkeys and reduce fallbacks over time.

Implementing with SealGate

SealGate is an API for adding passkeys (FIDO2 / WebAuthn) to an existing login. The settings and values that relate to phishing resistance:

  • In the environment settings, you set the passkey RP ID and the origins allowed to register and sign in. Responses from origins you didn't allow are rejected with 403 origin_not_allowed.
  • With user_verification set to required, registrations and logins where the user wasn't verified with a biometric or PIN fail with verification_failed (the default is preferred). With an API key you can change it through PATCH /v1/apps/{app_id}.
  • The POST /v1/login/verify response includes user_verified, so even with preferred you can decide based on it before important operations.
  • Adding a passkey for a user who already has one requires signed_in: true or a recovery_token. Issue recovery tokens only after verifying the user's identity on your side.

See the docs for details.

FAQ

Should we stop using SMS codes?

CISA says any MFA is better than none. But SMS isn't phishing-resistant, so make passkeys the default for users who can use them and decide case by case whether to keep SMS as a fallback.

Isn't a passkey a single factor?

The FIDO Alliance explains that a passkey lives on the user's device (something they have) and, when user verification is requested, can only be used with a biometric or PIN. If your server requests and checks user verification, you can treat it as multi-factor.

Does the JSDA guideline apply outside securities firms?

It covers internet trading at its member securities firms and isn't an obligation for other industries. It's still a useful reference for which methods are considered phishing-resistant.

Sources

Related posts

Back to the blog