Turning on two-factor authentication is the single best security decision most people can make. But the options are usually presented as a ladder — SMS is basic, an authenticator app is better, a passkey is best — and that picture is misleading in a way that matters.
The real shape is not a ladder. It is a cliff. One property separates methods that can be defeated by a convincing fake login page from methods that cannot, and it is called phishing resistance. On one side sit SMS codes, authenticator app codes, and push approvals. On the other side sits exactly one commonly available option.
That does not make the first three worthless. Any second factor stops a huge class of attack, and using one is far better than using none. But it does mean the honest comparison is not "how strong is each," it is "which attacks does each actually stop."
The Four Methods You Will Be Offered
| Method | How it works | What you do |
|---|---|---|
| SMS code | A one-time code is texted to your phone number | Read the text, type the code |
| Authenticator app | Your app and the server share a secret and both compute the same rotating code | Open the app, type the code |
| Push approval | The service sends a prompt to a trusted app | Tap "Approve" |
| Passkey / security key | A private key on your device signs a challenge from the site | Confirm with fingerprint, face or PIN |
The first three all end with a human passing along a piece of information or an approval. That shared characteristic is the entire story.
The Line That Actually Matters
CISA is unusually direct about this: "the only widely available phishing-resistant authentication is FIDO/WebAuthn authentication." Everything else, in CISA's framing, is vulnerable to common bypass attacks — and it names authenticator codes, SMS codes, and push notifications specifically.
The reason is structural rather than a matter of encryption strength. If your second factor is something you read and retype, then anyone who can convince you to type it somewhere has it. The code does not know which website it is being given to. You are the one making that judgement, in a hurry, on a page designed to look identical to the real one.
This is why the ladder framing does real harm. It tells people that moving from SMS to an authenticator app has solved their phishing problem. It has not. It has closed off some other attacks, which is genuinely worth doing, while leaving the most common one open.
How a Real-Time Proxy Beats Any Code
The attack that defeats codes is worth understanding, because once you have seen it you will never fully trust a retyped code again.
An attacker sets up a page that sits between you and the real site, relaying in both directions in real time:
- You land on the fake page and enter your username and password.
- The attacker's server immediately passes them to the real site.
- The real site asks for your second factor. The fake page asks you for it too.
- You read the code from your app and type it in.
- The attacker relays that code to the real site inside its validity window and is logged in.
The 30-second lifetime of the code is no defence, because the attacker is not storing it for later — they are using it instantly. CISA's own assessment is blunt: although phishing a code out of an authenticator app is harder than phishing an SMS code, it remains possible with real-time proxies, and such attacks are "extremely simple" to run.
Attack by Attack
This is the comparison that actually tells you something. The question is not which method is "strongest" but which specific attacks each one closes.
| Attack | SMS code | Authenticator app | Push approval | Passkey |
|---|---|---|---|---|
| Password reused from another breach | Stops | Stops | Stops | Stops |
| Password guessed or brute-forced | Stops | Stops | Stops | Stops |
| Password leaked in a server breach | Stops | Stops | Stops | Stops |
| Convincing fake login page (real-time proxy) | No | No | No | Stops |
| SIM swap or port-out fraud | No | Stops | Stops | Stops |
| SS7 network interception of messages | No | Stops | Stops | Stops |
| Repeated prompts until you tap Approve | Stops | Stops | No | Stops |
| Second-factor secret exposed in a server breach | No | No | Stops | Stops |
Read the rows in order and the logic becomes clear. Every method handles the password-related attacks — that is what a second factor is for, and it is why any of them is a large improvement over none. The rows underneath are where they diverge, and the fake-login-page row is the one that separates three from one.
SMS: Better Than Nothing, and Being Retired
SMS is the most widely offered second factor and the weakest, for reasons that regulators and standards bodies have documented rather than merely suspected.
NIST classifies SMS and voice delivery as a restricted authenticator in SP 800-63B, meaning it "should not be used for new implementations" and may be dropped from future editions of the guidance. The cited reasons are specific: attackers can get a phone number reassigned to a device they control, weaknesses in the SS7 telephone signalling system allow message interception, and messages can often be forwarded elsewhere.
The first of those is SIM swapping — persuading a mobile carrier to move your number to the attacker's device. Once the number moves, every SMS code follows it.
This is a recognised enough problem that the FCC adopted rules in November 2023 requiring wireless providers to use secure customer authentication before redirecting a number to a new device or carrier, and to notify customers immediately when a SIM change or port-out is requested. Those rules help. They do not make a phone number a secure channel.
Practical upshot: if SMS is the only second factor a service offers, switch it on. It closes the password-reuse and credential-stuffing attacks, which are extremely common. Just do not treat it as protection against being phished, and get it out of your account recovery settings wherever a better option exists.
Authenticator Apps: A Real Upgrade With One Hard Limit
An authenticator app generates codes locally using the TOTP algorithm, standardised in RFC 6238 in May 2011. Your app and the server each hold a copy of a secret, combine it with the current time, and independently compute the same six digits. The recommended default time step is 30 seconds.
Because nothing travels over the phone network, TOTP eliminates the entire SIM-swap and SS7 problem in one move. That is a substantial, genuine upgrade, and it is why authenticator apps are the right recommendation for most accounts today.
Two limits are worth knowing. First, TOTP is still a code you retype, so the real-time proxy attack above works against it. Second, RFC 6238 specifies that "the prover and verifier MUST either share the same secret or the knowledge of a secret transformation to generate a shared secret" — meaning the server holds a copy too. The RFC itself recommends encrypting those stored secrets using tamper-resistant hardware, which tells you the risk is understood. A passkey has no equivalent exposure, because the site only ever stores a public key.
Push Approvals: Convenient, and Vulnerable to Fatigue
Push approval replaces typing with tapping. That removes the retyping problem in one narrow sense but introduces a different one: push bombing, also called MFA fatigue.
The attack is depressingly simple. Having obtained your password, the attacker triggers login attempt after login attempt, and your phone fills with approval prompts — often late at night. Eventually someone taps Approve to make it stop, or taps it half-asleep by mistake.
CISA's guidance on this recommends number matching as the mitigation where phishing-resistant MFA is not available: instead of a bare Approve button, the login screen shows a number that you must type into the prompt. You cannot approve something you are not looking at, which defeats blind tapping.
If your service offers push with number matching, enable it. If it offers bare tap-to-approve, treat an unexpected prompt as an alarm — it means someone already has your password.
Passkeys: The Only One That Changes the Category
A passkey is different in kind, not degree. Instead of producing a secret for you to relay, your device holds a private key and signs a challenge from the site.
The part that defeats phishing is that each passkey is bound to one domain, and the browser enforces it. On a lookalike page the browser compares the domain against the credential's scope, finds a mismatch, and never offers the credential. You are removed from the decision entirely — which is why you cannot be talked out of it.
We cover the mechanism, the trade-offs and the recovery gap in detail in our guide to what passkeys fix and what they don't. The short version for this comparison: a passkey is the only option here that sits on the right side of the phishing-resistance line, and its main weakness is not the login step at all but whatever you leave configured as a fallback.
What You Should Actually Use
Match the method to what the account can cost you.
Tier 1 — email, password manager, banking, anything holding money or identity. Use a passkey where offered, and remove SMS from recovery as well as login. Keep printed recovery codes. These accounts are worth ten minutes of settings work, because email in particular is the reset path for everything else.
Tier 2 — social, shopping, subscriptions, work tools. An authenticator app is the sensible default. Add a passkey when the service supports it.
Tier 3 — accounts where SMS is the only option. Switch it on anyway. It closes the most common attacks. Just do not let it be the recovery method on a Tier 1 account.
Across all tiers: the weakest route into an account sets its real security, so audit recovery settings, not just login. An attacker will always pick the easier door — the same principle that makes account takeover a precursor to the kind of fraud worth checking your credit report for.
Common Misconceptions
"I use an authenticator app, so I can't be phished." You can. The code is relayed to the real site within seconds by a proxy page. Authenticator apps solve SIM swapping, not phishing.
"SMS 2FA is useless." It is not. It stops credential stuffing, password reuse and brute force — attacks that account for an enormous share of real-world compromise. It is the weakest option and the wrong choice for recovery, but it beats nothing by a wide margin.
"A code that expires in 30 seconds is safe." Expiry protects against reuse later. It does nothing against relay now, which is how the attack actually works.
"Any 2FA is basically the same." They differ on exactly which attacks they stop, which is why the attack-by-attack table above is more useful than a strength ranking.
"Passkeys make my account unphishable." They make the login step unphishable. If a password and SMS recovery are still active on the account, the phishable route is still there.
The Bottom Line
Turn something on. That is the first-order decision and it dwarfs the choice between methods.
Then understand the line. SMS, authenticator apps and push approvals all stop the password-based attacks that cause most compromise, and they differ usefully from each other — TOTP removes the SIM-swap problem, number matching removes blind approval. But none of them survives a convincing fake login page, because all three end with a person relaying something. Passkeys break that pattern by handing the domain check to the browser.
So: use a passkey where you can, an authenticator app where you cannot, SMS where that is all there is — and in every case, go and look at what the account will accept when you say you have lost your device. That setting, not the one you use daily, is where your real security level is decided. Explore more in our cybersecurity hub.
Frequently Asked Questions
Which two-factor method is the most secure?
A passkey or FIDO security key, by a clear margin. CISA describes FIDO/WebAuthn as the only widely available phishing-resistant authentication, because the credential is bound to a specific domain and released by the browser rather than by you. Every code-based method — SMS, authenticator app, push — can be defeated by a real-time phishing page that relays what you type, so they sit on the other side of that line regardless of how the code itself is generated.
Is SMS two-factor authentication safe enough?
It is much better than no second factor, and it stops password reuse, credential stuffing and brute-force attacks. But NIST classifies SMS delivery as a restricted authenticator that should not be used for new implementations, citing number reassignment, SS7 interception and message forwarding. Use it if it is the only option offered, avoid it as your account recovery method, and move to an app or passkey when you can.
Can an authenticator app be phished?
Yes. The app itself is not compromised, but the code is. An attacker running a page between you and the real site asks for the code and relays it within its 30-second window. CISA notes that phishing a code from an authenticator app is harder than from SMS but still possible with real-time proxies, and describes such attacks as extremely simple to carry out.
What is push bombing?
An attacker who already has your password triggers repeated login attempts so your phone fills with approval prompts, hoping you eventually tap Approve to stop the noise or do so by mistake. CISA recommends number matching as the fix where phishing-resistant options are unavailable: the login screen displays a number you must enter into the prompt, so approving requires actually looking at the login attempt.
Should I use SMS or an authenticator app if I can only pick one?
The authenticator app. It generates codes locally rather than sending them over the phone network, which removes SIM swapping and SS7 interception entirely. Both remain phishable, so the app is not a complete answer — but it closes a whole family of attacks that SMS leaves open, at no real cost in convenience.
Do I still need two-factor authentication if I use a passkey?
Generally no, because a passkey already combines two factors: possession of the device holding the private key, and the biometric or PIN that unlocks it. Most services treat a passkey as replacing both the password and the code. What you should still do is check the account's recovery options, since a weak fallback undoes the benefit.
Sources
- Next Level MFA: FIDO Authentication — Cybersecurity and Infrastructure Security Agency (CISA)
- CISA Releases Guidance on Phishing-Resistant and Numbers Matching Multifactor Authentication — CISA
- NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management — National Institute of Standards and Technology
- RFC 6238: TOTP: Time-Based One-Time Password Algorithm — Internet Engineering Task Force
- FCC Adopts Rules to Protect Consumers' Cell Phone Accounts (SIM swap and port-out fraud) — Federal Communications Commission
- Web Authentication: An API for accessing Public Key Credentials, Level 3 — W3C
