Multi-Factor Authentication (MFA)
Requiring a second proof of identity beyond the password — with a factor hierarchy that matters enormously, because SMS and phishable codes are no longer enough.
Last reviewed: July 25, 2026
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
Why MFA Is Considered a Baseline Control
Passwords alone are vulnerable to a range of common attacks — phishing, credential stuffing using passwords leaked from unrelated breaches, and brute-force guessing — that MFA substantially mitigates, since an attacker who obtains a valid password still lacks the second factor needed to complete authentication. Industry data consistently shows MFA blocking the vast majority of automated account takeover attempts, which is why it’s considered close to a mandatory baseline control for any account with meaningful access, particularly for cloud provider root/administrator accounts, where a single compromised credential without MFA can lead to complete environment compromise. Common MFA factors include authenticator apps generating time-based one-time codes (TOTP), hardware security keys (like YubiKeys, which are more phishing-resistant than SMS or app-based codes), and, less securely, SMS text messages, which remain vulnerable to SIM-swapping attacks and are increasingly discouraged for high-value accounts in favor of app- or hardware-based alternatives.
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.