"We already have MFA, do we need passkeys?" is a fair question with a genuinely interesting answer, because the two aren't points on the same scale.
MFA adds a factor to password login. Passkeys replace the password entirely with something that has a security property no additional factor provides.
What MFA fixes, and what it doesn't
Password + TOTP means a stolen password alone is not enough. That's real, and it stops credential stuffing and database-breach replay outright.
What it doesn't stop is phishing, because every common second factor is something the user can be talked into typing into the wrong place.
The attack is well-worn. User lands on paypa1.com. They enter their password;
the site relays it to the real PayPal in real time. Real PayPal prompts for a
TOTP code. The fake site prompts the user for it. The user types the code, the
attacker relays it within the 30-second window, and the session is theirs.
Tooling for this is commoditized — Evilginx and similar reverse-proxy kits automate the whole flow. From the user's side nothing looks wrong: they got a legitimate prompt from their own authenticator app and entered a code that was genuinely valid.
SMS is worse, adding SIM swapping and SS7 interception on top. Push-approval MFA adds "MFA fatigue," where an attacker fires repeated prompts at 3am until someone taps approve.
The common thread: the second factor is a value the user can transfer to an attacker.
What passkeys change
A passkey is a WebAuthn credential — a public/private keypair, where the private key stays in the authenticator (Secure Enclave, TPM, hardware key, or a synced password manager) and never leaves it.
At sign-in the server sends a random challenge. The authenticator signs it. The server verifies the signature against the stored public key.
Two properties follow, and they're the whole argument:
Nothing transferable is exchanged. There's no code, no password, no shared secret. The private key cannot be extracted, so there's nothing for a user to be tricked into revealing. Phishing a passkey isn't hard — it's not a defined operation.
Origin binding. This is the part that's often missed. The browser includes the origin in the signed data, and the authenticator will only produce an assertion for the origin the credential was registered against.
So on paypa1.com, the browser passes paypa1.com as the origin. The
authenticator holds a credential scoped to paypal.com. It doesn't match, so no
assertion is produced — not "a warning is shown," not "the user must be careful."
The ceremony cannot complete. The protection is enforced by the browser, not by
the user's judgment.
There's also nothing on the server worth stealing. Public keys are public. A breached passkey database yields nothing an attacker can replay.
Where passkeys are genuinely harder
They're not free, and the difficulties are operational rather than cryptographic:
Account recovery. With passwords, recovery is an email reset link. With passkeys, losing every registered authenticator means losing the account — so recovery becomes a designed flow, and it's usually the weakest link. A passkey system with an emailed magic-link fallback is only as phishing-resistant as that email.
Registering more than one. The practical answer to recovery is multiple credentials — phone, laptop, hardware key. That means prompting during onboarding, which is friction at exactly the wrong moment.
Sync vs. device-bound. Apple, Google, and password managers sync passkeys across a user's devices, which largely solves the loss problem. It also means the key material lives in a cloud account, so your security now inherits that account's. For most consumer apps that's a good trade. For high-assurance scenarios you may want device-bound credentials, which brings the recovery problem straight back.
Coverage. Support is broad now across current browsers and platforms, but not universal — legacy environments, kiosks, and some enterprise-managed devices still need a fallback path.
Choosing
- Consumer app, phishing is your real threat: passkeys, with a considered recovery flow. This is the strongest option available.
- You have password + TOTP today: adding passkeys as an option is the incremental move. Users who adopt them get phishing resistance; nobody is locked out.
- Enterprise with compliance requirements: check whether the framework requires "two distinct factors" explicitly. A passkey with user verification is multi-factor — something you have (the authenticator) plus something you are or know (biometric or PIN) — but auditors don't always read it that way.
- Keeping SMS as a fallback: understand you've capped your security at SMS. An attacker will simply choose that path.
Debugging an implementation
WebAuthn responses are dense — nested CBOR, base64url-encoded buffers, and flags packed into single bytes. The Passkey Debugger decodes registration and authentication responses into readable form, including authenticator data, client data, and the credential itself, so you can see what the browser actually produced.
For implementation, see the passkey authentication docs and the Passkey Plus integration guide.