2FA vs Passkeys: What Each One Actually Stops — and Why Your Recovery Path Undoes Both

The Ladder, Worst to Best

"Turn on 2FA" is good advice that hides an enormous range. Here is what each method actually buys you.

Method	Stops a breached / reused password	Stops a convincing phishing page	Stops a stolen session cookie
Password only	No	No	No
SMS code	Yes	No	No
Authenticator app code (TOTP)	Yes	No	No
Push approval	Yes	Not reliably	No
Push with number matching	Yes	Partly	No
Passkey / hardware security key	Yes	Yes	No

Read the last column first. Nothing in it says yes. That is not a flaw in the methods — it is a reminder that a second factor protects the act of logging in, and a stolen session cookie is not a login. It is a login that already happened, resumed by someone else. Different problem, different defence, covered in our piece on infostealers.

Why SMS is bottom of the list

A text message is a second factor delivered over a channel you do not control. Three separate weaknesses:

• SIM swapping. Someone contacts your carrier, convinces a representative they are you, and moves your number to a SIM they hold. Your codes then arrive at their phone. The information used to pass that check — address, date of birth, account details — is exactly what brokers publish.
• Port-out fraud. The same outcome via a transfer to a different carrier.
• Network-level interception. Weaknesses in the signalling protocols between carriers have been demonstrated repeatedly for redirecting texts.

Regulators have responded — US carriers are now subject to rules requiring stronger customer authentication before a SIM change or a number port. That raises the bar; it does not remove the category. Treat SMS as better than nothing and worse than everything else.

Why authenticator codes are a real step up, but still phishable

A time-based code from an app never travels over the phone network, so SIM swapping is irrelevant. That is a genuine improvement, and for most accounts it is the practical default.

What it does not survive is a real-time relay. A phishing page proxies your login: you type your password, it forwards it to the real site, the real site asks for a code, the page asks you for the code, you type it, it forwards that too. The code is valid, the attacker is logged in, and you are looking at an error message. The code was correct. It was just typed into the wrong place — and any secret you can read and retype can be relayed this way.

Why push prompts are better and still not sufficient

An approve/deny prompt removes the typing, which removes the simplest relay. The failure mode is fatigue: send enough prompts, at a bad enough moment, and someone eventually taps approve. Number matching — where the site shows a number you must select in the app — substantially reduces that, because there is no longer a single button to press reflexively. It is a good option where offered.

What a Passkey Actually Is

A passkey is not a password, and not a code. It is a cryptographic key pair.

When you create one, your device generates two halves. The private half stays on your device, in hardware designed to keep it there, and is released only after you prove you are present — a fingerprint, a face, a PIN. The public half goes to the website. To log in, the site sends a random challenge; your device signs it with the private key; the site verifies the signature against the public key it stored.

Three properties fall out of that, and they are the whole argument:

• Nothing reusable is transmitted. The signature is valid once, for that challenge. There is no shared secret to intercept, relay or replay.
• Nothing worth stealing is stored on the server. A breach leaks public keys, which are public. There is no password hash database to crack.
• It is bound to the real domain. This is the one that kills phishing. Your browser will only use a passkey with the exact origin it was created for. On a lookalike domain, the passkey is not offered at all — and if it were, the resulting signature would be for the wrong origin and rejected. The attack does not fail because you noticed. It fails because the mathematics does not cooperate.

That last point is why passkeys are a genuine category change rather than a nicer code. Every other method on the ladder depends, at some moment, on a human correctly judging whether a page is real.

What Passkeys Do Not Solve

This is the section most passkey coverage skips, and it is where the real decisions are.

• Device loss. Passkeys are either synced through a platform or password manager, or bound to one device. Synced is far more practical for most people — but it means your passkeys are exactly as safe as the account that syncs them. Device-bound keys are stronger and demand a spare, because losing the only one locks you out.
• The sync account becomes the crown jewels. If your passkeys live in your Apple, Google, Microsoft or password manager account, that account now protects everything else. Secure it with the strongest method available and the tightest recovery path you can tolerate.
• Stolen session cookies, again. A passkey authenticates a login. It has nothing to say about a session someone copied afterwards.
• Malware on your device. A passkey cannot be exfiltrated the way a saved password can, which is a real gain. But malware running as you, on an unlocked machine, is in a strong position regardless — it may not need your credentials at all.
• Uneven support. Coverage is good at large providers and patchy elsewhere, and plenty of sites that offer passkeys keep a weaker fallback permanently enabled. A passkey plus an always-available SMS fallback is, for an attacker, an SMS account.

The Step Almost Nobody Takes

Spend twenty minutes on this and you will get more security than from any other change in this article.

For each important account, write down three things: the strongest factor it requires, every way the account can be recovered without that factor, and therefore the weakest route in. The third column is your actual security level.

Account	Strongest factor	Recovery paths	Real strength
Email	Passkey	SMS code, backup email	SMS
Bank	App approval	Phone call + knowledge questions	Knowledge questions
Password manager	TOTP	None — recovery code only	TOTP

That table is an example, not a finding about your accounts. Filling it in for real is the exercise, and the pattern is usually the same: the front door has been upgraded and the side door has not.

Then, where the provider allows it: remove the weak recovery path, or replace it. Many services let you delete a recovery phone number once another method exists. Some let you turn off SMS as a factor but quietly keep it for recovery — which is why you have to read the recovery settings specifically, not just the two-factor page.

What to Do, in Order

Where This Meets the Data Broker Problem

Two of the weakest links above do not run on technology at all. They run on facts about you.

A SIM swap is a social engineering attack on your carrier. Whoever calls needs to sound like you: your address, your date of birth, maybe a previous address or the last four digits of something. Knowledge-based recovery questions are the same attack aimed at a support desk. Previous addresses, relatives' names, the city you were born in — these are not secrets. They are product categories, compiled and sold.

So the honest framing: passkeys and hardware keys close the technical routes in, and what remains is the human route, which is powered by published data. Removing that data does not replace 2FA — nothing does. It narrows the channel that the strongest key on the market cannot defend, because the attacker never touches your key. They talk to someone who can reset it. We have written about the sharpest version of this in what happens when a data broker gets your Social Security number, and the general scope in what data brokers know about you.