The three factors
MFA combines two or more credentials drawn from different categories. The categories are old (NIST has been writing them down since the 1970s) and useful precisely because they fail in different ways. A stolen password doesn't compromise a stolen phone; a stolen phone doesn't compromise a stolen fingerprint.
Something you know
A secret stored in your head. Defeated by phishing, shoulder surfing, dictionary attacks, and database leaks. The original credential and the weakest member of the family.
Something you have
A physical object that proves possession. Defeated by theft, SIM swapping, malware on the device, or remote code that intercepts the one-time value. Stronger than knowledge, weaker than inherence for high-value targets.
Something you are
A biometric — what your body looks like. Convenient and hard to phish, but unrevocable: you cannot get a new fingerprint after a leak. In practice biometrics unlock a local have credential rather than authenticating to the server directly.
Three other factors are sometimes named: somewhere you are (location / geofencing), something you do (behavioral biometrics), and someone you know (social verification). All three are weak as primary factors but useful as risk signals.
The second-factor menagerie, ranked
Not all second factors are equal. The only useful question for picking an MFA method is — does this factor survive the user being phished? Anything that can be read aloud, typed into a fake site, or relayed in real time fails. Anything cryptographically bound to the destination origin survives.
| Factor | How it works | Phishing-resistant? | Why |
|---|---|---|---|
| SMS / Voice OTP | Server sends a 6-digit code to the registered phone number. | No | SIM swap; user reads code into phishing form; SS7 interception. |
| Email OTP | Code emailed to registered address. | No | Phishable; only as strong as the email account itself. |
| TOTP (Google Authenticator-style) | App generates 6-digit code from a shared secret + current time. | Partial | Code can still be typed into a phishing form; real-time relay attacks work. |
| Push notification (e.g. Duo) | App prompts "Approve this login?" on the registered device. | Partial | "MFA fatigue" attacks: spam approvals until the user taps yes. Number-matching variants help. |
| FIDO2 security key (YubiKey) | Hardware key signs a server challenge with a key bound to the origin. | Yes | Origin binding. Browser refuses to use the key on the wrong domain. |
| Passkey (platform / synced) | Same FIDO2 protocol, key stored in device OS keychain (and synced via iCloud / Google). | Yes | Same origin binding. See the Passkeys page for the full mechanism. |
| Biometric (Face ID / fingerprint) | Local sensor unlocks a stored credential. | Yes* | *Only because what the biometric unlocks is a phishing-resistant credential. The biometric itself never reaches the server. |
CISA's official guidance since 2022: deploy phishing-resistant MFA for everyone you can; treat anything else as defense in depth, not as MFA proper.
See it — a phish against three second factors
A real attack: the victim follows a phishing link to accounts-northgate.cn — a lookalike domain. The fake page is a pixel-perfect clone of the real Northgate login. The attacker's server proxies the inputs to the real Northgate server in real time. Step through what each second-factor method does in this scenario.
Common implementation mistakes
- Allowing SMS fallback on otherwise-strong accounts. Coinbase, Reddit, and Twitter have all been breached this way. If a user has a FIDO key registered, do not let them "recover" with SMS.
- Accepting any registered second factor. If a user has both a FIDO key and SMS enabled, the attacker picks SMS. Force phishing-resistant when available.
- Trusting client-side MFA flags. "Skip MFA on this device" cookies have been forged in multiple breaches. Sign the trust signal server-side or do not trust it.
- Counting backup codes as a separate factor. A printed code in a desk drawer is — in spirit — a password. It is reusable, phishable, and not bound to anything.
- Ignoring MFA fatigue. The Uber breach (2022) used push spam — the attacker tried 50+ times until the user tapped Approve to make it stop. Number-matching (user must type a number shown on the login page into the prompt) defeats it.
Notable incidents that drove the ranking
- Reddit (2018). SMS-MFA on employee accounts compromised by SIM swap. Source code and old user data leaked. Reddit moved to TOTP company-wide; eventually to hardware keys.
- Twitter / Jack Dorsey (2019). CEO's own phone was SIM-swapped via his carrier. Attackers used it to tweet from his account.
- Twilio (2022). Employees phished via TOTP relay; the attacker site forwarded the code to the real Twilio in real time. Downstream effect: Signal accounts of journalists were compromised.
- Uber (2022). Contractor's account flooded with push notifications until they approved one. Attacker moved laterally into internal systems and onto the developer Slack.
- Cloudflare vs. the same attacker (2022). Same campaign as Twilio. Cloudflare employees were also phished, but every account required a hardware FIDO key. The login failed at the browser; no account was compromised. The single best public case study for why phishing-resistant MFA matters.