MFA Is Not Enough: Passkeys, Recovery Paths & Human Failure Points

MFA has become synonymous with security hygiene. Enable MFA, the guidance says, and you are significantly more protected. That is still broadly true — but the version of MFA most people are using is no longer sufficient against the attacks most commonly deployed against them.

CISA strongly urges all organizations to implement phishing-resistant MFA as part of applying Zero Trust principles.

— CISA, More Than a Password: MFA Guidance

What "Phishing-Resistant" Actually Means

A phishing-resistant authentication method is one where the credential cannot be replayed by an attacker who intercepts it. SMS codes, email OTPs, and TOTP fail this test. An attacker operating a real-time proxy — a site that sits between you and the legitimate service, forwarding your session in real time — can intercept and replay these codes within their validity window.

FIDO2/WebAuthn-based authentication (hardware security keys, passkeys) passes this test because the cryptographic response is bound to the domain of the originating page. A phishing site that impersonates your bank cannot use your passkey challenge response because the domain does not match. The credential simply does not work outside the legitimate site.

Passkeys in Practice

Passkeys are FIDO2 credentials stored in your platform authenticator — iPhone Face ID, Android biometrics, Windows Hello, or a hardware key. When you authenticate, your device performs a cryptographic challenge-response that is bound to the specific website domain. There is no shared secret to intercept or replay. All major platforms support passkeys natively as of 2025. Google, Apple, GitHub, Microsoft, PayPal, and most major financial institutions now offer passkey enrollment.

• Phishing-resistant by design — domain-bound, cannot be replayed on a different site
• Resistant to credential stuffing — no password to leak in a breach
• Resistant to SIM swap — no SMS code in the authentication flow
• Biometric unlock — local biometric, never transmitted to the server

MFA Decision Framework

MFA Method Comparison

Method	Phishing-Resistant	AiTM-Resistant	SIM-Swap Proof
Passkey (FIDO2)	YES	YES	YES
Hardware Key (YubiKey)	YES	YES	YES
TOTP Authenticator App	NO	NO	YES
Push Notification	NO	NO	YES
SMS / Phone Call	NO	NO	NO

Account Recovery: The Real Attack Surface

MFA on the primary login means nothing if account recovery is weaker. Common failure modes:

• Phone number as recovery factor — SIM swap bypasses primary MFA entirely
• Security questions — answers often derivable from public records or social media
• Backup email with lower security — attackers target the weaker account first
• Carrier account without a PIN — enables unauthorized SIM transfers
• Printed backup codes stored insecurely — physical access negates all other controls

Recovery hardening: remove phone number as a recovery factor on your primary email; use a dedicated backup email with equally strong MFA; store backup codes in a password manager; set a carrier account PIN with your mobile carrier.

For Operators: M365 and Google Workspace

Microsoft 365 and Google Workspace tenants should enforce Conditional Access policies requiring phishing-resistant MFA for all admin roles — at minimum for Global Admin, Exchange Admin, and Security Admin. Break-glass accounts: two accounts with no MFA (by necessity), credentials in a physical safe, real-time monitoring alerts on any login. Number-matching in push notifications reduces MFA fatigue attacks. SSPR in M365 should require two verification methods, never SMS alone for admin accounts.