What "phishing-resistant" actually means
Phishing-resistant MFA cryptographically binds the authentication ceremony to the legitimate origin. Even if a user types their password into a perfectly cloned phishing site, the WebAuthn assertion will fail because the origin presented by the phishing site does not match the one the user originally registered. SMS, TOTP, and push prompts have no such binding — the user can be tricked into approving a malicious request.
In 2026 the methods that count as phishing-resistant are: hardware FIDO2 security keys (Yubico, Google Titan, Feitian), platform authenticators (Windows Hello, Touch ID, Android biometrics) when used via WebAuthn, and synced or device-bound passkeys. Everything else is "better than passwords" but not phishing-resistant.
Passkeys vs. hardware keys
The distinction matters for enterprise deployments. Hardware FIDO2 keys are device-bound — the private key never leaves the YubiKey. Loss of the key requires re-enrollment. Passkeys can be device-bound (created on and never leaves the device) or synced (replicated across a user's devices via iCloud Keychain, Google Password Manager, 1Password, etc.).
Synced passkeys are dramatically easier for users — losing a phone does not lock you out — but introduce a new risk: an attacker who compromises the sync account (Apple ID, Google account) can clone the passkeys. For most users this is a net win because the sync account is itself protected by phishing-resistant MFA. For high-privilege roles, device-bound hardware keys remain the gold standard — and an essential layer in any zero trust deployment.
A staged rollout that survives contact with users
Stage 1: Admins and high-value roles (week 1–4)
Enforce phishing-resistant MFA for every administrative role across the IdP, cloud consoles, source code repositories, and financial systems. Issue hardware keys (two per admin — primary and backup). Block all other factors for these roles via conditional access.
Stage 2: Broad user enrollment (months 2–6)
Open passkey enrollment to all employees, communicate heavily, and provide self-service registration through the IdP. Keep TOTP as a fallback during this phase to avoid lockouts but track adoption weekly. Reward early adopters and tie completion to performance reviews if the corporate culture supports it.
Stage 3: Enforcement (months 6–9)
Once adoption is above 90%, set the policy to require phishing-resistant MFA and grandfather only documented exceptions. Phase out SMS and TOTP entirely — they create a backdoor that attackers will find. The classic adversary-in-the-middle pattern is to phish a user, fail MFA, fall back to a weaker factor, and steal a session cookie — a cookie that, in 2026, is increasingly resold via infostealer marketplaces.
Stage 4: Recovery flow
The most dangerous moment in any MFA deployment is recovery. An attacker who calls the help desk pretending to have lost their phone has historically bypassed every MFA system because recovery still ran on knowledge-based verification. Move recovery to in-person verification, video-call ID checks, or a manager-approved process — never SMS-to-a-new-number. The same scrutiny applies to non-human identities, whose recovery flows are even less mature than human ones.
Edge cases worth planning for
- Shared-device environments (kiosks, frontline workers): platform authenticators do not work; issue per-user FIDO2 keys
- Apps without WebAuthn support: shrinking list, but legacy on-prem apps may need an identity-aware proxy in front
- Contractor accounts: lifecycle is messy — automate offboarding triggered by HRIS or contract-management system
- High-frequency travel: ensure backup hardware keys travel with users; train on regional phone-purchase scenarios