Multi-Factor Authentication (MFA):A Simple Guide
Passwords leak. They get guessed, reused, phished, and stolen in breaches every day. Multi-factor authentication is the control that makes a leaked password almost worthless on its own, which is why security teams treat it as the single highest-value defence for any login page. This guide explains the factor types in plain language, compares the common methods, and shows how to roll MFA out without locking your users out of their own accounts.
What Is Multi-Factor Authentication?
Multi-factor authentication is a login that requires proof from at least two different categories, called factors. The three categories are: something you know, something you have, and something you are. A password plus a code from an authenticator app is MFA because it combines two categories. A password plus a second password is not MFA, because both come from the same category. Two-factor authentication (2FA) is simply MFA with exactly two factors, so the terms are often used to mean the same thing.
| Factor Category | What It Means | Examples |
|---|---|---|
| Something you know | A secret stored in your memory | Password, PIN, security question |
| Something you have | A physical or digital item you possess | Authenticator app, security key, phone |
| Something you are | A physical trait unique to you | Fingerprint, face scan, voice |
Why Does MFA Stop So Many Attacks?
Almost every common attack on login pages ends with the attacker holding a valid password: credential stuffing replays leaked passwords, password spraying guesses common ones, phishing tricks the user into typing theirs, and a database breach can leak them directly. MFA breaks the final step. Even with the correct password, the attacker still lacks the second factor sitting on the user's phone or key, so the login fails. That one change neutralises a whole family of attacks at once, which is why guidance from OWASP and NIST puts MFA near the top of every checklist.
Which Type of MFA Should You Use?
Not all second factors are equally strong. The table below ranks the common methods from strongest to weakest so you can choose the right default and the right fallback.
| Method | Strength | Notes |
|---|---|---|
| Passkeys / security keys (FIDO2) | Strongest | Phishing resistant. The key checks the real site before it responds, so a fake page gets nothing. |
| Authenticator app (TOTP) | Strong | A six-digit code that changes every 30 seconds. Works offline. Can be phished if the user types it into a fake page. |
| Push notification | Strong | Approve or deny on your phone. Watch out for MFA fatigue, where attackers spam prompts hoping you tap approve. |
| Email code | Moderate | Only as strong as the email account, which is often the weakest link. Use as a fallback. |
| SMS code | Weak | Vulnerable to SIM swapping and interception. Better than nothing, but never your only factor. |
A good default for most apps is TOTP authenticator codes for everyone, with passkeys offered to users who want the strongest option, and SMS kept only as an emergency fallback. High-value or admin accounts should require a phishing-resistant factor such as a passkey or hardware key.
How Does TOTP Actually Work?
TOTP stands for Time-based One-Time Password. When a user enables it, your server generates a random secret and shows it as a QR code. The authenticator app stores that secret. From then on, both the app and your server run the same formula over the shared secret and the current time to produce the same six-digit code, which changes every 30 seconds. At login, the user types the code and your server checks it against its own calculation. Nothing is sent between the app and your server, which is why it works with no internet on the phone.
# Enrolment: generate a secret, show it as a QR code
secret = generateRandomBase32() // store per user
otpauthUrl = "otpauth://totp/App:alice?secret=" + secret
# Login: server recomputes the code and compares
expected = totp(secret, currentTime)
if (userCode === expected) allowLogin() // allow small clock driftHow Do You Roll Out MFA Without Locking Users Out?
The most common MFA mistake is not the cryptography, it is the recovery flow. If a user loses their phone and has no backup, they are locked out, and a weak recovery flow can undo all the protection MFA gave you. Plan recovery before you launch.
- 1Offer TOTP authenticator apps as the default second factor, and passkeys for users who want phishing-resistant login.
- 2Generate single-use backup recovery codes at enrolment and tell users to store them somewhere safe.
- 3Require a phishing-resistant factor (passkey or hardware key) for admin and other high-value accounts.
- 4Keep SMS only as a fallback, never as the sole factor, because of SIM swapping.
- 5Rate limit the code entry step so attackers cannot brute force the six-digit code.
- 6Re-prompt for MFA on sensitive actions such as changing the password, email, or payout details.
- 7Log MFA enrolment, use, and reset events so you can spot an attacker trying to disable it.
- 8Design account recovery carefully: a support agent who resets MFA on a phone call is a bypass of your whole system.
What Are Passkeys and Should You Move to Them?
Passkeys are a newer standard built on FIDO2 that can replace the password entirely rather than sit next to it. Instead of a shared secret, the device holds a private key and proves possession without ever sending anything reusable. Crucially, a passkey checks the real website's identity before it responds, so a phishing page that looks identical gets nothing. That makes passkeys phishing resistant in a way that codes are not. You do not have to switch overnight: offer passkeys alongside your existing password and TOTP flow, and let users adopt them at their own pace. For a passwordless approach that is simpler to ship today, see passwordless magic links.