Passkeys vs passwords: what actually changes
A passkey beats a password on phishing, and it isn't close. The tradeoff is that your login now depends on a device or cloud account instead of your memory. For most accounts that's a good trade, as long as you know what you're depending on.
How each one works
A password is a shared secret. You know it, the site can check it, and you send it every time you log in. That's the core weakness: anything that convinces you to type it, like a convincing fake login page, gets a working copy.
A passkey is a key pair. The site stores a public key, and the private key stays with your authenticator: your phone, your laptop, a hardware key, or a credential manager. To log in, your authenticator signs a challenge, and you approve it with your fingerprint, face or device PIN. The private key is never sent to the site.
The comparison
| Password | Passkey | |
|---|---|---|
| Phishing | Can be typed into a fake site | Tied to the real site, so a lookalike domain gets nothing usable |
| Server breach | Leaks hashes that attackers can try to crack | Leaks public keys, which don't let anyone log in |
| Reuse across sites | Common, and one leak spreads | A separate key pair for each site |
| What you depend on | Your memory or a password manager | A device or the cloud account that syncs your keys |
| New or borrowed device | Works anywhere you can type | Needs a synced account, a nearby device or a hardware key |
| Losing access | Reset through email or support | Recover through the sync account or a fallback method |
What NIST says
The US government's digital identity guidelines are direct about this. NIST SP 800-63B states that "passwords are not phishing-resistant," and says the same about one-time codes, including codes sent by text. Cryptographic authentication, the category passkeys belong to, can be phishing-resistant when it meets NIST's additional requirements.
NIST also separates synced passkeys from device-bound ones. Keys that sync through a cloud provider are exportable, so they're allowed at its AAL2 assurance level but not at AAL3, which requires a non-exportable private key. In practice, a synced passkey is a strong choice for everyday accounts, while high-risk admin access should use a hardware key.
Where passkeys fall short
The fallback can undo the protection. If a site offers a passkey but still lets you log in with a text message code, an attacker can go after the code instead. The account is only as strong as its weakest login path.
Your cloud account becomes the key to everything. Synced passkeys are only as safe, and as available, as the account that holds them. Losing that account can mean losing every passkey in it, so set up a recovery method before you need one.
Switching ecosystems is still a job. The FIDO Alliance's Credential Exchange Protocol is designed to move passkeys between credential managers, but check that yours supports it before you count on it.
Should you switch?
Yes, for any important account that supports passkeys: email first, because it can reset everything else, then banking and work accounts. Keep a long, unique password or recovery code stored somewhere safe for the accounts that need a fallback. For everything without passkey support, use a password manager.
Where memory fits
You'll probably keep at least one secret in your head: the code for your phone, or the password that unlocks your manager. That's what we work on at Password Palace, where you log in by rebuilding a 3D room you designed, using the spatial memory behind the memory palace technique.
To be plain about the tradeoff: anything you enter from memory is a knowledge factor, so it doesn't get the phishing protection a passkey does. What it offers is login with no device to carry. Those are different jobs, and the demo shows ours.