Overview
Multi-factor authentication is the single most effective control against account takeover, but most of the MFA in production today is not phishing-resistant. Push notifications are vulnerable to push fatigue attacks (the user gets bombed with prompts until they accept one). SMS one-time passwords are vulnerable to SIM swap and to phishing proxies that relay the code in real time. Time-based one-time password apps (TOTP, like Google Authenticator) are vulnerable to phishing proxies that capture the code as it is entered. The only MFA that holds up against a motivated attacker is FIDO2 / WebAuthn with a hardware-backed credential.
Phishing-resistant MFA means: the credential cannot be phished, cannot be replayed, cannot be stolen from the user's device, and cannot be socially engineered into being approved. The mechanisms that achieve this are tied to the origin (the credential is bound to the specific web origin that registered it) and tied to hardware (the signing key never leaves the secure element of the device). When the user authenticates, the browser presents the origin to the authenticator; the authenticator checks that the origin matches the registered credential; if it does not, the credential refuses to sign. A phishing site that proxies to the real origin cannot pass this check because the origin the browser is talking to is the phishing site's origin, not the real one.
WebAuthn is the W3C standard that implements FIDO2 in the browser. WebAuthn credentials can be bound to a hardware security key (a YubiKey, a Titan Key, a Feitian key) or to a platform authenticator (Apple Touch ID / Face ID, Windows Hello, Android's built-in authenticator). Both are phishing-resistant; the difference is whether the credential can roam between devices (hardware keys can) or is tied to a single device (platform authenticators are). The right answer for most organizations is a mix: platform authenticators for everyday users (because they have no friction), hardware keys for high-value accounts (admin accounts, executives, infrastructure access).
How it works
A WebAuthn registration creates a public/private key pair on the authenticator. The private key never leaves the device's secure element; the public key is sent to the relying party (the server) along with a credential ID. The server stores the public key and the credential ID. The user authenticates by clicking the WebAuthn login button on the site; the site sends a challenge (a random nonce) to the browser; the browser asks the authenticator to sign the challenge; the authenticator signs with the private key only if the origin in the challenge matches the origin registered with the credential; the signed challenge goes back to the server, which verifies the signature using the stored public key. If the signature verifies, the user is authenticated.
The critical detail is the origin check. The authenticator will not sign a challenge whose origin does not match the credential's registered origin. This is what makes the credential phishing-resistant: a phishing site that proxies the login flow to the real site cannot trick the authenticator into signing, because the origin in the challenge is the phishing site's origin, not the real one. The authenticator refuses. The phishing site is left with no signature and no way to authenticate as the user.
The two types of WebAuthn authenticators have different properties. A hardware security key (a YubiKey, a Titan Key, a Feitian key) is a physical device with a secure element that holds the private key; it can be plugged into any USB port or tapped on any NFC reader; the user carries it on a keychain. A platform authenticator (Apple Touch ID, Windows Hello, Android's built-in) is built into the device; the private key is held in the device's secure enclave or TPM; it can be used only on that device. The trade-off: hardware keys are portable and survive device loss (with a backup key); platform authenticators are zero-friction (no key to carry) but do not survive device loss. The right operational model is a mix, with hardware keys for accounts where loss-of-device is unacceptable.
In practice
A real WebAuthn rollout has three phases. Phase 1 is registration: the user adds a WebAuthn credential to their account, the server stores the public key. Phase 2 is authentication: the user logs in with the credential, the server verifies the signature. Phase 3 is fallback: if the user loses the credential (lost key, replaced device), how do they get back in? The fallback is the most commonly-mishandled phase; it is also where phishing-resistant MFA can fall back to being phishable.
The right fallback design: when the user registers a WebAuthn credential, they also register at least two credentials (two hardware keys, or one hardware key and one platform authenticator). The two-credential minimum means the loss of one credential does not lock the user out. For high-value accounts (admin, executive, infrastructure), two hardware keys stored in physically separate locations is the right minimum. For everyday users, one hardware key and the platform authenticator on their primary device is a reasonable balance.
The wrong fallback design is the one that introduces a phishing vulnerability. A common mistake: the fallback for a lost WebAuthn credential is to send a one-time recovery code via SMS, or to allow a password reset via email. Both of these fall back to phishing-vulnerable MFA. A user who loses their WebAuthn credential and recovers via SMS OTP is now protected only by SMS OTP, which is phishable. The right fallback is to require the user to authenticate with a second WebAuthn credential (which is why the two-credential minimum matters), or to do an out-of-band identity verification (a video call with a known person on the team, an in-person visit to the office, an out-of-band video verification through a trusted channel). Anything less re-introduces the vulnerability the WebAuthn rollout was supposed to fix.
For organizations rolling out WebAuthn at scale, the migration path is important. A common pattern: keep passwords as a fallback for the first phase of the rollout, but require WebAuthn for high-value accounts from day one. Once the user has registered a WebAuthn credential, the password can be removed or kept as a fallback only if the user re-authenticates with a recent WebAuthn login. The migration can be phased over quarters (admin accounts first, then executives, then engineering, then the rest of the organization), and the right phase depends on the organization's tolerance for friction and its risk profile.
Common mistakes
The first mistake is rolling out MFA without making it phishing-resistant. Push MFA, SMS OTP, and TOTP are all vulnerable to phishing proxies. The credential is captured by the phishing site and replayed, or the user is socially engineered into approving a push prompt. Rolling out MFA that is not phishing-resistant is better than no MFA, but it does not stop the most common attack (the AiTM phishing proxy). For a security-conscious organization, the rollout target should be FIDO2 / WebAuthn, not MFA in general.
The second is the fallback that re-introduces the vulnerability. SMS OTP as a fallback for lost WebAuthn credentials is the most common version of this; the user is protected by WebAuthn until they lose their key, and then they are protected by SMS OTP (which is phishable) until they re-register. The attacker who wants to take over the account waits for the user to lose their key, then triggers the fallback. The fix is the two-credential minimum and the out-of-band recovery flow.
The third is treating the platform authenticator as a substitute for a hardware key. The platform authenticator is tied to the device; if the device is compromised (malware, thief with the unlocked device), the platform authenticator is compromised too. The hardware key is a separate device; compromising the user's laptop does not compromise the hardware key. The platform authenticator is good for everyday friction reduction, but a high-value account should have a hardware key as a primary or secondary credential.
The fourth is not registering backup credentials. The user has one WebAuthn credential, on their primary device, with no backup. They lose the device, they cannot log in, the fallback flow fires. If the fallback is weak, they are exposed; if the fallback is strong, they are saved but the account was unavailable for hours. The fix is the two-credential minimum, set up at registration time.
The fifth is no monitoring of the WebAuthn flow. An organization that rolls out WebAuthn without monitoring the registration and authentication events will not detect an attacker who tries to register a rogue credential against a compromised account. The right monitoring is the same as for any authentication flow: log every registration, every authentication, every failed authentication, and alert on unusual patterns.
Defensive guidance
Make FIDO2 / WebAuthn the standard for high-value accounts from day one. Admin accounts, executive accounts, infrastructure access (cloud consoles, code repositories, payment systems, identity providers) should require WebAuthn. Push MFA and SMS OTP are acceptable as a transitional measure for low-value accounts, but the rollout target is WebAuthn everywhere.
Require two WebAuthn credentials per user. The two-credential minimum ensures that the loss of one credential does not lock the user out and does not trigger a fallback to a phishing-vulnerable authentication method. The two credentials should be of different types (a hardware key and a platform authenticator, or two hardware keys stored in different locations).
Audit the fallback flows. The fallback for a lost WebAuthn credential should not be SMS OTP, TOTP, or any other phishable method. The right fallback is a second WebAuthn credential, an out-of-band identity verification, or a documented recovery flow that is itself phishing-resistant. The fallback that re-introduces the vulnerability is the most common mistake in WebAuthn rollouts.
Monitor the WebAuthn flow. Log every registration, every authentication, every failed authentication, every credential change, every fallback invocation. Alert on unusual patterns: registrations from unexpected IPs, failed authentication bursts, fallback invocations from accounts that should not be falling back. The monitoring is the operational safety net that catches the things the rollout itself did not anticipate.
Plan the migration in phases. Admin accounts first (smallest surface area, highest impact), then executives, then engineering, then the rest of the organization. Keep passwords as a fallback during the migration, but require WebAuthn for high-value accounts from day one. The migration can take quarters; the right phase depends on the organization's tolerance for friction and its risk profile. Do not let the perfect be the enemy of the good; a phased rollout that gets WebAuthn in front of the most exposed accounts is better than a perfect rollout that never ships.