Passkeys vs passwords vs 2FA: what each one actually stops
A passkey is not a prettier password. It is a different mechanism that removes the thing an attacker needs to steal — here is what each option stops, and what passkeys genuinely cost you.
The short answer on passkeys vs passwords: a password is a secret you and the server both know, which means it can be copied, guessed, leaked in a breach, or typed into a convincing fake. A passkey is a private key that never leaves your device and is cryptographically tied to the real site's address, so there is nothing for an attacker to collect and nothing to type into the wrong place.
Two-factor authentication sits in between, and it is the one people misunderstand. An SMS or app code is still a secret you type, which means it can still be phished — just within a shorter window.
I have spent a year testing login flows, and the thing that changed how I think about this was realizing the question is never "how strong is the secret". It is "how many places does the secret exist".
What a password is on the server side
When you set a password, the server stores something derived from it — a slow hash, if the engineers did their job. Every login recomputes that hash and compares. The design requires both sides to hold the secret, and that requirement is the root of nearly every failure that follows.
The server's copy can be stolen in a breach. Your copy can be captured by a fake login page. The same string, sitting in two places plus a password manager plus possibly a sticky note, has four chances to leak instead of one. If you want the full picture of what happens after a database goes missing, that is the subject of our post on checking whether your email was breached.
Password rules do not change this. Length and uniqueness reduce guessing and reuse, which are real wins, and neither touches the problem that a stranger with a convincing page can get you to hand the secret over directly.
Why one-time codes still get phished
This surprised me when I first saw it demonstrated, because the whole promise of 2FA is supposed to be that a stolen password is not enough.
The attack is a relay. The fake page sits between you and the real site. You type your password into it, the attacker's server types it into the real site, the real site sends you a code, you type the code into the fake page, and the attacker uses it within its validity window. Every box you filled in was genuine. The site on the other end was not.
Worse, what the attacker often keeps at the end is not your password but your session cookie, which means your next password change does not evict them.
Push approvals have their own version: send enough prompts at eleven at night and somebody taps approve to make it stop. Number matching, where you have to type a digit shown on screen, exists specifically to break that reflex.
SMS adds a separate failure. The code goes to a phone number, and a phone number can be moved to another SIM by someone with a convincing story at a telecom counter. SIM swap is routine, not exotic.
None of this makes 2FA pointless. It makes 2FA a control against stolen credentials, not a control against phishing, and those are different attacks.
Passkeys vs passwords: the actual mechanism
A passkey is a public-private key pair created for one site. The private half is generated on your device and stays there — in the secure element on your phone, the TPM on your laptop, or a hardware key. The site stores only the public half.
Logging in works by challenge and response. The site sends a random challenge, your device signs it with the private key after you approve with a fingerprint, face or PIN, and the site verifies the signature against the public key it holds. Nothing reusable crosses the network. There is no shared secret for a breach to expose, which is why a site losing its passkey table is not the emergency that losing a password table is.
The part that actually stops phishing is the origin binding. The credential is registered against a specific domain, and your browser or operating system will not produce a signature for a different one. A page at a lookalike domain cannot ask for the real site's passkey, and it does not matter how carefully the design was copied or how tired you are. The check is made by software that cannot be fooled by appearances.
That is the difference worth holding on to. Everything else is a defense that depends on you noticing something. This one does not.
| Method | Stops credential stuffing | Stops real-time phishing | What it costs you |
|---|---|---|---|
| Password alone | No | No | Nothing, and that is the problem |
| Password + SMS code | Mostly | No, and exposed to SIM swap | Free, works on any phone |
| Password + authenticator app | Yes | No | A one-time setup, recovery codes to store |
| Password + push with number matching | Yes | Partly, if you read the number | App install, prompt fatigue |
| Passkey or security key | Yes | Yes, by construction | Device dependency and a recovery plan |
What passkeys actually cost
Advice without a trade-off reads as an advertisement, so here is the honest list.
Recovery is the hard problem. Lose every device holding the key and you are relying on whatever fallback the site offers. Platform passkeys from Apple, Google and Microsoft sync through the account you are already signed into, which solves device loss and quietly means your cloud account is now the thing protecting everything else. Hardware keys do not sync, so the honest answer there is to register two and keep the spare somewhere else.
The fallback is your real security level. Most sites still let you log in with the old password, or mail you a magic link, when the passkey is not available. An attacker will simply choose that path. Until a site lets you remove the password entirely, a passkey raises your convenience more than your security, and it is worth checking which sites allow passwordless-only.
Portability is improving and is not finished. Moving credentials between ecosystems has been the weak point, and the import and export work going on in the FIDO Alliance is aimed squarely at it. Check the current state before you commit a whole team to one vendor.
Shared accounts get awkward. A password in a team vault is trivially shared. A passkey bound to one person's device is not, which is a feature for security and a genuine friction for small teams who share a billing login.
Frequently asked questions
Is a passkey the same as a fingerprint login? No. The fingerprint or face check unlocks the private key on your device. The biometric data never reaches the site, and it is not what is being checked at the other end — the signature is.
If my phone is stolen, can someone use my passkeys? Not without unlocking the device, since the key only signs after a successful biometric or PIN check. Device lock quality is the whole dependency, which is a good reason not to use a four-digit PIN you also use elsewhere.
Do I still need a password manager? Yes, for years. Plenty of sites will never add passkeys, and the manager is also where your recovery codes and the passwords you cannot delete should live.
Should I turn off two-factor authentication once I have a passkey? No. The passkey replaces the password and the second factor together on sites that support passwordless login, but leave the existing factors in place for every other login path that still works.
Are passkeys worth it for a small team? On the accounts that matter most — email, cloud console, code hosting, payments — yes, because those are the ones worth phishing. Do them first and leave the long tail on a password manager.
Where to start
Turn on a passkey for your email account before anything else. It is the reset path for everything you own, so it is the account an attacker wants, and it is also one of the few places where you can usually remove the password fallback afterward.
Then check one thing people skip: after adding the passkey, look at whether the old recovery options are still live. A phone number from four jobs ago, or a backup email you no longer control, undoes the work you just did.