Multi-Factor Authentication (MFA)

What is MFA?

Multi-factor authentication demands two or more independent proofs: something you know (password), something you have (phone, security key), something you are (biometric). Its power is statistical: stolen passwords are the raw material of account takeover, and any second factor removes the attacker’s easiest path. But “any MFA” stopped being the right bar years ago — the factor hierarchy now matters as much as the checkbox.

The hierarchy, bottom to top

SMS codes: better than nothing, defeated by SIM-swapping and interception — banks keep learning this publicly. TOTP apps (authenticator codes): solid against remote password stuffing, but phishable — a fake login page relays your code in real time, and modern phishing kits (Evilginx-style adversary-in-the-middle) automate exactly this, capturing session cookies wholesale. Push notifications: phishable and fatigue-attackable — bombard a user at 2 a.m. until they tap approve; number-matching mitigates but doesn’t cure. Phishing-resistant MFA — FIDO2/WebAuthn security keys and passkeys — is the top tier because the cryptographic exchange is origin-bound: the credential simply will not authenticate to a lookalike domain. No user vigilance required; the protocol refuses.

Deployment realities

The rollout that matters most is admins and high-privilege roles first — attackers target them first. Watch the recovery path: an account with a hardware key but SMS-based reset has SMS-grade security; recovery flows must match factor strength. And enforce at the IdP/SSO layer so coverage is fleet-wide rather than per-app roulette.

What people get wrong

• Declaring victory at “MFA enabled” while the factor is phishable and the target is a phishing campaign.
• Ignoring MFA fatigue — approvals without context train users to tap yes.
• Leaving service accounts out entirely: machine credentials often bypass MFA policy and hold the broadest access.

Primary source: CISA — Implementing Phishing-Resistant MFA