MFA shows up throughout this site's other posts as the control that catches a correctly guessed or stolen password — the layer Password Security: A Comprehensive Guide calls defense beyond the password itself — but always as a one-paragraph mention, never explained on its own. This is that piece: what actually counts as a factor, why the common mechanisms aren't interchangeable, and which ones a determined attacker can still get around.
The three factor categories
Multi-factor authentication means proving your identity with credentials from at least two different categories — not just two credentials. There are three:
- Something you know — a password, a PIN. This is the one factor every other post on this site covers in depth.
- Something you have — a phone, a hardware security key, a smart card.
- Something you are — a fingerprint, a face scan, another biometric.
Two passwords, or a password plus a security question, is still one category repeated — not MFA, whatever a login form calls it. The security value comes specifically from needing to compromise two independent categories at once, which is a fundamentally different, harder problem than guessing or stealing one more string.
MFA vs. 2FA vs. "2-step verification"
Two-factor authentication (2FA) is just MFA with exactly two factors — every 2FA setup is MFA, not every MFA setup is 2FA (a hardware key plus a PIN plus a biometric would be three). "2-step verification" is looser marketing language that sometimes describes real MFA and sometimes describes two steps that aren't actually independent — an SMS code sent to the same phone number an attacker could port via a SIM swap isn't a fully separate factor from "something you have" in the way a physical hardware key is. The label on the box matters less than which category each step actually falls into.
Common mechanisms, and their real tradeoffs
- SMS/voice one-time codes. The most widely deployed and most widely criticized. NIST SP 800-63B classifies SMS-delivered codes as a restricted authenticator — not banned, but flagged as carrying risks a verifier has to actively mitigate, chiefly SIM-swapping (an attacker social-engineers a carrier into porting your number to their device) and SS7 network interception, neither of which requires compromising your phone itself.
- TOTP authenticator apps (Google Authenticator, Authy, and similar) — time-based one-time codes generated from a shared secret, per RFC 6238. No carrier dependency, so SIM-swapping doesn't touch it — but the seed itself is a target (extract it and the codes can be cloned indefinitely), and typing a code into a form does nothing to stop real-time phishing: a fake login page that relays your password and current code to the real site the instant you submit them, completing the login as you before the code expires.
- Push notifications (Duo, Okta Verify, and similar approve/deny prompts) — better UX than typing a code, but this convenience created a specific, well-documented attack pattern: MFA fatigue (or "push bombing"), where an attacker who already has a valid password triggers repeated push prompts until a tired or confused user approves one just to make it stop. Several real, publicized breaches have used exactly this technique as the way in.
- Hardware security keys (FIDO2/WebAuthn, e.g. YubiKey) — the one mechanism on this list that's phishing-resistant by design, not just phishing-resistant in practice. The cryptographic challenge-response WebAuthn performs is bound to the actual origin (domain) requesting it — a perfect pixel-for-pixel fake login page still fails, because the key checks the real domain cryptographically rather than trusting whatever page asked. This origin-binding property is exactly why NIST's highest assurance level requires a hardware-based authenticator specifically, not any factor that happens to be "something you have."
Where this fits NIST's framework
NIST Password Guidelines Explained covers Authenticator Assurance Levels in detail — AAL1 is satisfied by a memorized secret alone, AAL2 requires two independent factors, and AAL3 requires a hardware-based authenticator specifically resistant to verifier impersonation. That last requirement maps directly onto WebAuthn's origin-binding property above: it's not an arbitrary bar, it's the standard naming the exact property that defeats real-time phishing relays.
MFA doesn't fix a bad password, and a strong password doesn't replace MFA
These are independent controls for independent failure modes, not a ranked list where one makes the other optional. A perfectly hashed, Argon2id-stored password with no MFA is still a full account takeover the moment that password is phished, reused from another breach, or simply guessed correctly. A hardware security key with no password requirement behind it is rarely how real systems are built, and for good reason — the categories are meant to combine, not substitute. Password Storage Checker grades MFA presence alongside hashing, breach-checking, and rate limiting for exactly this reason: none of them cover for a missing one of the others.
Common mistakes
- Treating SMS as equivalent to app-based or hardware MFA. It's real protection against a password-only attack, but a meaningfully weaker one against a targeted attacker willing to attempt a SIM swap.
- No thought-out recovery path. Losing the second factor and having no account-recovery plan locks out legitimate users — and a recovery path built on weak knowledge-based questions can quietly become the actual weakest link in an otherwise strong MFA setup, undermining everything else.
- Assuming push notifications are immune to social engineering. MFA fatigue works specifically because the prompt itself looks routine — user education and number-matching (requiring the user to enter a code shown on the login screen into the push prompt, not just tap "approve") both meaningfully reduce it.
- Not accounting for real-time phishing against OTP-based methods. A code that's valid for 30–60 seconds is still enough time for an automated relay attack — this is specifically what phishing-resistant hardware keys exist to close.
FAQ
Is MFA required by NIST?
Not for AAL1 — a memorized secret alone is sufficient there. It becomes a requirement the moment a system needs AAL2 or higher, which is common for anything handling sensitive data or elevated privileges.
Which mechanism should I actually use?
A hardware security key where the option exists and phishing resistance matters most (admin accounts, anything protecting other people's data); a TOTP app as a strong, widely supported default otherwise; SMS only as a fallback when nothing else is available, not as the primary method by choice.
Does biometric authentication (Face ID, a fingerprint) count as a real factor?
Yes — it's "something you are," a genuinely separate category from a password or a possessed device. In practice it's frequently used to unlock a device or an authenticator app rather than as a factor a remote server verifies directly, which is a slightly different role than the other mechanisms above.
Try it yourself
Password Storage Checker grades whether a system actually requires MFA, alongside its hashing algorithm, breach-checking, and rate limiting — runs entirely in your browser. See Password Security: A Comprehensive Guide for how this fits the other layers of password security.