What Is MFA? Multi-Factor Authentication Explained
MFA requires two or more independent proofs of identity to log in. How the factor categories work, common methods, and why MFA stops most account takeovers.
Multi-factor authentication (MFA) requires a user to prove their identity with two or more independent types of evidence before granting access — typically something they know, something they have, and something they are. A stolen password alone isn’t enough to log in, because the attacker would also need to satisfy the second factor.
The three factor categories
Security factors fall into three families, and MFA specifically means combining factors from different categories — not just adding more of the same kind:
- Something you know. A password, a PIN, a security question answer. This is the factor everyone starts with, and the one attackers target most, since it can be phished, guessed, or reused across breached sites.
- Something you have. A physical device: a phone receiving a one-time code, a hardware security key, an authenticator app generating rotating codes. Compromising this factor usually requires physical access or a separate exploit against the device itself.
- Something you are. A biometric — fingerprint, face, iris. Hard to steal remotely, but also hard to change if it’s ever compromised, which is why biometrics are typically verified locally on a device rather than transmitted to a server.
Two passwords in a row isn’t MFA — it’s still one factor, just entered twice. The security value comes from requiring an attacker to defeat fundamentally different attack surfaces simultaneously.
Common MFA methods, ranked
Not all “something you have” implementations are equally resistant to attack:
| Method | How it works | Phishing-resistant? |
|---|---|---|
| SMS/voice codes | One-time code sent to a phone number | No — vulnerable to SIM swapping and interception |
| Authenticator app (TOTP) | Time-based code generated locally on a device | No — codes can still be phished and relayed in real time |
| Push notification | Approve/deny prompt sent to a trusted device | Partially — vulnerable to “MFA fatigue” prompt-bombing |
| Hardware security key (FIDO2/WebAuthn) | Physical key performs a cryptographic challenge tied to the origin | Yes — the key won’t respond to a lookalike domain |
| Passkeys | Public-key credential bound to a device and origin | Yes — same cryptographic binding as hardware keys |
SMS-based MFA is far better than no MFA, but it’s also the weakest link, since phone numbers can be ported to an attacker-controlled SIM through social engineering at the carrier. Passkeys and hardware keys close that gap by binding the credential to the actual website origin, so even a convincing phishing page can’t extract anything usable.
Why MFA blocks the attacks passwords alone don’t
Passwords fail in predictable, high-volume ways: credential stuffing replays passwords leaked from one breach against other services, phishing pages harvest passwords directly, and rainbow tables crack weakly hashed ones offline. Every one of these attacks yields the same thing — a valid password — and every one of them is neutralized by requiring a second, independent factor the attacker doesn’t also have.
This is also why password hashing with bcrypt or argon2 and MFA solve different problems: hashing protects passwords at rest if a database is breached, while MFA protects the login itself even when the password is already known to an attacker through some other channel entirely.
MFA fatigue and its defenses
Push-based MFA introduced a new attack: MFA fatigue (or prompt bombing), where an attacker who already has valid credentials repeatedly triggers login prompts until an annoyed or confused user approves one by mistake. Defenses include requiring a number displayed on the login screen to be entered into the push prompt (number matching), rate-limiting how many prompts a user can receive, and — most robustly — moving to phishing-resistant methods like hardware keys or passkeys that don’t have a simple “approve” button to fatigue someone into tapping.
Where MFA fits in a broader auth strategy
MFA is usually layered on top of an existing authentication flow rather than replacing it outright. In an OAuth or federated login setup, the identity provider is typically where MFA gets enforced once, and every downstream application inherits that guarantee instead of implementing its own factor checks. Enterprises often go further with adaptive or risk-based MFA, which only prompts for a second factor when a login looks unusual — a new device, an unfamiliar location — rather than on every single sign-in.
The takeaway
MFA works by requiring an attacker to compromise two fundamentally different things at once — typically a password and a physical device — rather than just one. Not every second factor is equally strong: SMS and TOTP codes can still be phished in real time, while hardware keys and passkeys are cryptographically bound to the real site and resist that entirely. If you’re choosing what to roll out, phishing-resistant factors are worth the extra setup friction, especially for anything protecting sensitive accounts.
Tagged
Keep reading
The Lycoris Team · · 5 min read Biometric Authentication Explained
Biometric authentication verifies identity using fingerprints, faces, or other traits — here's how enrollment, matching, and liveness checks work.
Chisato · · 4 min read What Is a Man-in-the-Browser Attack?
A man-in-the-browser attack uses malware inside the browser itself to alter what a user sees and submits, bypassing HTTPS and session protections entirely.
The Lycoris Team · · 5 min read CSRF vs. XSS: What's the Difference?
CSRF forges a request using a victim's login session; XSS runs the attacker's own code inside the victim's browser. Different mechanisms, different fixes.