A password is a secret you prove you know by typing it somewhere — the same string, every time, sent to whatever asked for it. A passkey is a different kind of thing entirely: a cryptographic key pair, generated per site, where the half that could ever be stolen or phished never leaves your device in the first place. This isn't a stronger password. It's a structurally different credential, and the difference is what closes attacks a password can never fully close, no matter how long or how well hashed.
What a passkey actually is
A passkey is a WebAuthn public-key credential. Your device generates a key pair for a specific site: the private key is created and stored inside a secure enclave or platform keystore and never leaves it, and the public key — useless on its own for signing in as you — is what the site stores. Signing in means the site sends a challenge, your device signs it with the private key, and the site verifies that signature against the public key it already has. Nothing reusable ever crosses the network.
Two properties fall directly out of that design. First, the credential is bound to the origin that created it — the same cryptographic property Multi-Factor Authentication Explained describes for hardware security keys, since a passkey uses the same underlying WebAuthn mechanism. A pixel-perfect fake login page still fails, because the browser checks the real origin before it ever asks the device to sign anything. Second, a passkey can be discoverable — the device can find the right credential for a site without you typing a username first, which is what makes a fully passwordless sign-in flow possible rather than just a password with better MFA behind it.
What breaks when there's no shared secret
- A database breach exposes nothing usable. Minimum Password Length Recommendations is entirely about how long a password needs to be to survive an offline cracking attempt against a leaked hash. A passkey has no equivalent question — the server only ever held a public key, and there is no cracking attempt that turns a public key back into a private one. The entire threat model that post walks through simply doesn't apply.
- Credential stuffing has nothing to reuse. A leaked password works against every other site where the same person reused it — the actual mechanism behind most large-scale account takeovers. A passkey is generated fresh per site by construction; there is no shared value to try anywhere else, because there never was one.
- Phishing has nothing to relay. Multi-Factor Authentication Explained covers how a real-time phishing relay defeats a typed one-time code by forwarding it to the real site within its validity window. A passkey never produces a value that could be relayed in the first place — the signature is bound to the origin that requested it, so a relay from a fake domain to a real one breaks the signature, not just the user's judgment.
Is a passkey MFA, a password replacement, or both?
Both, in a way that doesn't map cleanly onto the three factor categories Multi-Factor Authentication Explained lays out. Unlocking a passkey usually requires a device PIN or biometric first — the device itself is "something you have," and unlocking it is "something you know" or "something you are." One tap satisfies both categories at once, which is exactly why NIST Password Guidelines Explained places a hardware-based authenticator resistant to verifier impersonation at AAL3, its highest assurance level — a passkey isn't a password with an extra step bolted on, it's a single credential that reaches a higher assurance level than a password ever can, MFA or not.
The real tradeoffs — why passwords aren't gone yet
- Account recovery is a genuinely hard problem. A forgotten password has a well-worn recovery path: a reset link to an email you still control. Lose every device holding a passkey and there's no equivalent — recovery depends entirely on whatever the platform's synced-backup story offers, and if that account itself is locked out, there's no secret to reset.
- Syncing is a platform ecosystem, not a single standard. iCloud Keychain, Google Password Manager, and Windows Hello each sync passkeys within their own ecosystem; moving a passkey between an iPhone and a Windows PC still routes through a QR-code-based cross-device flow rather than a clean, universal sync. It works, but it's a rougher edge than password managers settled years ago.
- The password fallback usually isn't actually gone. Most "passkey-enabled" sites still accept the old password as an alternative sign-in path — which means a leaked, weak, or reused password can still compromise the account even after a passkey is set up, unless that fallback is explicitly disabled. A passkey only closes the attacks above once the weaker path next to it is actually turned off.
- Support still varies. Adoption across sites, browsers, and older devices keeps improving but isn't universal — a passkey-first strategy today still needs a fallback for the accounts and devices that don't support it yet.
Passkey vs. a plain hardware security key
Both are WebAuthn credentials with the same origin-binding property — the difference is syncability. A traditional FIDO2 hardware key (a YubiKey, say) holds a credential that lives only on that physical device; lose it and that credential is gone, which is exactly the property that makes it the right choice for the highest-assurance accounts. A passkey adds syncing across a platform's ecosystem on top of the same underlying mechanism — more convenient, more recoverable, and a meaningfully different loss scenario than a single physical key.
FAQ
Can a passkey be phished the way a password can?
No — the origin-binding described above means a fake site simply can't obtain a valid signature, regardless of how convincing the page looks or how much the user is fooled. This is the same property that makes hardware security keys phishing-resistant by design, covered in Multi-Factor Authentication Explained.
Do I still need a password manager?
Increasingly, it's the same tool — most major password managers now store and sync passkeys alongside passwords, and act as the cross-device bridge between platform ecosystems that don't sync with each other natively.
What actually happens if I lose every device with my passkeys?
It depends entirely on the platform's account-recovery design, not on anything specific to the site you're signing into — worth checking before treating a passkey as the only way into an account that matters.
Should I turn off the password fallback once a passkey is set up?
Where the option exists, yes — a passkey only delivers its full security benefit once the weaker password path next to it is no longer a valid way in. Leaving both active means an attacker just uses whichever one is weaker.
Try it yourself
Password Storage Checker grades whether a system requires MFA alongside its hashing and rate-limiting practices, and Password Security: A Comprehensive Guide maps out how passwords, policy, storage, and MFA fit together as layers — the same map a passkey slots into as a stronger alternative to the first one.