Key takeaways

  • Any MFA is better than none, but SMS codes, app codes and push approvals can be phished or abused. FIDO2 passkeys and security keys are built to resist phishing.
  • NIST SP 800-63B-4 became final in July 2025. It requires verifiers to offer a phishing-resistant option at assurance level 2 and restricts SMS and voice codes.
  • The same revision sets password rules: no forced composition rules, no routine rotation, a blocklist check, and at least 15 characters when a password is the only factor.
  • Synced passkeys are practical for most staff. Device-bound security keys are the stronger choice for administrators and high-risk roles.
  • Roll out in order: administrators and email first, then everyone, with a tested recovery process before you remove the old methods.

Why MFA is no longer one thing

Multi-factor authentication asks a person to prove identity with two or more different kinds of evidence: something they know, something they have or something they are. The idea is that a stolen password alone is not enough. CISA has urged organizations to turn it on for all users and all services, including email, file sharing and financial accounts.

But CISA also warns, in its fact sheet on phishing-resistant MFA, that not all forms are equally secure. Some are open to phishing, to "push bombing" (flooding a user with approval prompts until they tap Accept), to weaknesses in the telephone signaling network that carries text messages, and to SIM swapping, where an attacker talks a mobile carrier into moving the victim's number to a new SIM card. The fact sheet gives a simple example of a common phishing attack: a fake login page collects the username, the password and the six-digit code from the user's authenticator app, and the attacker uses all three right away on the real site. The code was correct. MFA was on. The attacker still got in.

This is why the conversation has moved from "do you have MFA" to "which MFA do you have." CISA ranks the forms from strongest to weakest. At the top is phishing-resistant MFA, based on FIDO/WebAuthn or on public key infrastructure (PKI) smart cards. Below it are app-based methods: one-time codes from an app, push notifications with number matching, and hardware token codes. Below those, in CISA's list, are SMS and voice codes. CISA calls phishing-resistant MFA the gold standard and says that any MFA is still better than no MFA.

What makes an authenticator phishing-resistant

A phishing-resistant method does not depend on the user judging whether a site is real. NIST's final SP 800-63B-4 describes how: phishing resistance requires cryptographic authentication, achieved through channel binding or verifier name binding. Values that a person types in, such as one-time codes and codes sent out of band, do not qualify.

In plain terms, the login is a challenge-response exchange tied to the real site's name. The user's device holds a private key and gives the site a signature, never a secret. If the user lands on a fake site with a similar name, the device will not answer, because it has no credential for that name. W3C's Web Authentication specification describes this: credentials are strong, public-key based and scoped to a given relying party, and a credential can be used only by origins that belong to the relying party it was created for. W3C's Web Authentication Level 3 is now a W3C Recommendation, published in August 2026.

FIDO2 and passkeys in plain English

FIDO2 is the set of standards behind this. It has two main parts: WebAuthn, the browser interface that websites use, and CTAP, the protocol that lets a browser or operating system talk to an authenticator such as a phone or a security key. A passkey is a FIDO-based credential stored on a phone, a computer or a hardware security key. The user signs in by unlocking the device with a fingerprint, a face scan, a PIN or a pattern, instead of typing a password.

The FIDO Alliance explains the benefits that matter to a business. The server stores a public key rather than a shared secret, so a breach of the password database exposes less. The fingerprint or face data stays on the device; the server only learns that the check passed. When the site asks for user verification, a passkey combines two factors in one gesture: possession of the device and a biometric or PIN.

There are two kinds. Synced passkeys are stored with a passkey provider and copied across a user's devices with end-to-end encrypted syncing. They survive a lost phone, because they are on the user's other devices. Device-bound passkeys never leave a single device, and that includes the ones on hardware security keys. The FIDO Alliance describes security keys as the highest-assurance option, and they have supported device-bound passkeys since 2019. A person can also sign in on a laptop using a passkey on a phone, usually by scanning a QR code, and the Bluetooth check confirms the two devices are close together.

What NIST SP 800-63B-4 changed

NIST's Digital Identity Guidelines are the reference many U.S. contracts, auditors and insurers point to. Part B covers authentication. The fourth revision of SP 800-63B was finalized in July 2025 and supersedes the 2020 edition. Even if you are not a federal agency, it is the best published statement of current practice. The points below are from the final text.

  • Assurance levels. At level 1 (AAL1), single-factor or multi-factor authentication is allowed. At AAL2, two factors are required, at least one must resist replay, and verifiers must offer a phishing-resistant option. At AAL3, the authenticator must be phishing-resistant, use a cryptographic key that cannot be exported, and be paired with a second factor.
  • Syncable authenticators. The revision covers authenticators that copy keys across devices, which is how synced passkeys work, and sets out requirements for them in an appendix. Because syncing requires keys that can be exported, syncable authenticators are not allowed at AAL3. That is the standards reason to use security keys for your most sensitive accounts.
  • Phone-based codes. Out-of-band authentication over the public telephone network is "restricted." Verifiers must offer another option, should check risk signals such as a recent SIM change or number port before sending a code, and must treat a change of phone number as binding a new authenticator. Email is prohibited as an out-of-band channel.
  • Passwords. A password used alone must be at least 15 characters. A password used only as one factor within MFA must be at least 8. Verifiers should allow at least 64 characters, must not impose composition rules, must not force periodic changes (but must require a change if a password is compromised), must check new passwords against a blocklist, and must allow password managers and pasting.
  • Reauthentication. At AAL2, sessions should last no more than 24 hours overall and 1 hour of inactivity. At AAL3, the limits are 12 hours and 15 minutes.

Two cautions. First, NIST's text is aimed at federal systems. Treat it as a strong benchmark, not as your legal duty. Second, the FIDO Alliance itself notes that some regulatory regimes have not yet recognized passkeys as an official form of MFA. If you have a specific rule to satisfy, such as one in a contract or an industry regulation, ask the author of that rule how it treats passkeys.

Choosing the right method by user and risk

A single method rarely fits everyone. A practical way to decide is to sort accounts by the damage a takeover would cause.

  • Administrators, finance staff, and anyone who can change payment details or access regulated data: hardware security keys, with a second registered key kept in a safe place. This is also the group for which CISA says migration should be a high priority.
  • Everyone else with email and business apps: synced passkeys, or an authenticator app with number matching as a bridge, while you complete the move.
  • Contractors and shared devices: a security key or a managed device, not a personal phone you do not control.
  • Fallback only: SMS or voice codes, kept for the few accounts or customers that have nothing better, and never for administrators.

A rollout plan that does not lock people out

Most failed MFA projects fail on recovery, not on technology. Plan these steps in order.

  • Inventory. List every system that holds a login: email, file sharing, VPN, the accounting system, the line-of-business application, domain registrar, cloud consoles, and social accounts. Mark which ones support passkeys or security keys. Many support them now; some still do not.
  • Start with identity. If you use a single sign-on or a directory service for most apps, enforce strong MFA there first. One policy then covers many apps.
  • Administrators first. Issue two security keys per administrator. Register both. Store one in a safe. Turn off password-only access for admin roles.
  • Pilot with one team for two weeks. Collect the problems: old mail clients, shared mailboxes, scanners that send mail, scripts that use passwords. These legacy cases cause most of the help-desk calls.
  • Design recovery before you remove anything. Decide how a person who loses a phone proves who they are. Use a verified call with a manager or an in-person check, not an email link or a text. Attackers target the reset process because it is the weakest door.
  • Move everyone, then remove the weaker options. Disable SMS and voice for staff who have a stronger method. Turn on number matching for any push approval that remains.
  • Block legacy sign-in methods that skip MFA, such as old protocols that accept only a username and password.
  • Review quarterly: unused accounts, lost devices, new apps, and exceptions.

Common mistakes

We see the same problems in many environments. MFA is on for staff but not for the shared mailbox or the service account that sends invoices. An exception list grows until it covers the executives, who are the favorite targets. A push prompt without number matching is left on, so users approve prompts out of habit. Recovery codes are saved in the same mailbox the MFA protects. A departed employee's phone remains registered. And the password policy still forces a change every 90 days, which NIST now says not to do, and which teaches people to add a number to the end of the old one.

Also remember that MFA protects the sign-in, not the session. If malware steals the session cookie from a logged-in browser, the attacker may not need the second factor. Keep devices patched, use endpoint protection, and shorten session lifetimes for sensitive apps.

How Clayton Cybernetics can help

Our team has worked with most major identity systems and designs and operates MFA rollouts for businesses: inventory, policy, security-key logistics, pilot, recovery process, help-desk scripts and ongoing review. Through Clayton Secure we also build login flows for custom applications. If you want to know where your accounts stand today, we can start with a short identity review.

Sources

This article is general information, not legal advice. Standards such as NIST SP 800-63B-4 are written for federal systems; confirm which rules apply to your business with your compliance counsel. Last reviewed .

Keep reading

Need help with this?

One view of your entire cybersecurity program, in near real time.

Clayton Secure