Which MFA methods are strongest, and how do they differ?

Multi-factor authentication asks for two or more kinds of proof: something you know, something you have, or something you are. Methods differ in how well they resist phishing. Hardware keys and passkeys are the strongest common options, authenticator apps are a solid middle, and SMS codes are the weakest accepted form.

What counts as a factor?

CISA's MFA guidance lists the three categories: something you know, such as a PIN or password, something you have, such as an authenticator app or phone, and something you are, such as a fingerprint or face scan. Two passwords are still one factor. MFA means different categories.

What methods exist, and how do they fail?

SMS or voice codes. Easy to roll out, familiar to users. NIST SP 800-63B restricts them as out-of-band authenticators and warns about SIM swapping, where an attacker has the mobile operator redirect a victim's number. Email is not allowed as an out-of-band channel at all.

Authenticator app codes (TOTP). RFC 6238 defines time-based one-time passwords, generated from a shared secret and the clock. Codes are not sent over the phone network, which removes SIM swap risk. But a phishing site can ask for the code and replay it in real time.

Push approvals. One tap to approve. NIST lists authentication fatigue as a threat: an attacker sends repeated requests until the user approves one to make them stop. Number matching, where the user types a number shown on the login screen, helps.

Hardware security keys and passkeys. These use public-key cryptography, and the credential is bound to the real website, so a look-alike site gets nothing. NIST SP 800-63B-4 calls this phishing-resistant authentication. At the highest assurance level, AAL3, it requires a phishing-resistant authenticator with a non-exportable key, so syncable passkeys that export the private key cannot be used there.

Biometrics. Useful as a local unlock for a device or key. They are not secrets, so they work as part of a factor, not as a remote password.

A constructed example

A company protects its email with an app code. An attacker sends a convincing sign-in page, the employee types a password and the current code, and the attacker's script forwards both to the real site within seconds. The account is taken despite MFA. Had the company used a security key, the browser would not have released the credential to the fake domain.

How do you choose?

Match the method to the risk. For administrators, finance and anything with access to source code or customer data, require phishing-resistant methods. For general staff, use app-based or number-matched push as a floor and move toward passkeys. Keep SMS only as a fallback and track who uses it.

Plan recovery too. Account recovery that falls back to an email link or a help desk call can undo a strong method. Give help desk staff a verification script.

What do users actually experience?

Friction decides adoption. A method people bypass is worse than a slightly weaker one they use. Passkeys remove the code-typing step, which many users find easier than passwords. Hardware keys need distribution and a spare for each person. Plan for lost devices, and measure how many sign-in failures and help desk tickets each method creates before you mandate it.

How to check or apply this

1. List every system that holds sensitive data and note which MFA method it allows.
2. Require phishing-resistant MFA on admin and high-impact accounts first.
3. Turn on number matching for push approvals and limit repeated prompts.
4. Retire SMS where an alternative exists, and flag accounts that still use it.
5. Review recovery paths and confirm they are not weaker than the login.
6. Offer two registered methods per user so a lost phone is not a lockout.

Quick check

Sources

• CISA, More than a Password
• NIST SP 800-63B, Authentication and Authenticator Management
• RFC 6238, TOTP: Time-Based One-Time Password Algorithm

Last reviewed: 18 October 2026.