The short answer
A passkey replaces your password with a key pair. A private key never leaves your device, and the site only ever stores the matching public key. You log in by signing a one-time challenge with the private key, so there is no shared secret to phish, reuse, or steal in a breach. On World Passkey Day in May 2026, the FIDO Alliance counted roughly 5 billion passkeys in use, with about half of the top 100 websites supporting them.
What is actually wrong with passwords
A password is a shared secret. You know it, and the server knows it — or knows a hash of it. That sharing is the entire problem. Anything you both hold can be stolen from either end: phished off you with a convincing fake login page, scraped from a server breach, or guessed because you reused it somewhere that already leaked.
Microsoft's 2025 Digital Defense Report put a number on the gap. Multi-factor authentication, and especially the phishing-resistant kind, blocks more than 99% of identity attacks. But most second factors are still phishable. A one-time code over SMS or from an authenticator app is just another secret you can be tricked into typing into the wrong box, and an attacker who relays it in real time still walks in. Passkeys close that hole in the protocol instead of asking you to stay alert at 2am.
The key pair, and why only half of it matters to an attacker
When you create a passkey, your device generates a brand-new key pair specifically for that one site. The phone, laptop, or hardware key keeps the private half, guarded by your fingerprint, face, or device PIN. The site receives the public key and nothing else.
That asymmetry is the whole trick. A public key is exactly that — public. If a server holding a pile of passkey public keys gets breached, the attacker leaves with material that is useless on its own. There is no hash to crack, no secret to replay against your bank. Compare that to a classic credential dump, where the stolen file is the password.
How a login actually happens
The standard behind passkeys is WebAuthn, a W3C specification, paired with CTAP for talking to the authenticator. The FIDO Alliance calls the pair FIDO2. One login runs like this:
- The site sends your browser a random, one-time challenge.
- Your device asks you to confirm with a fingerprint, a face scan, or a PIN. That unlocks the private key locally; the biometric never leaves the device.
- The device signs the challenge with the private key and returns the signature.
- The server checks the signature against the public key it stored at registration. A match means you are in.
The challenge is fresh every time, so a signature captured off the wire is worthless on the next attempt. Nothing reusable ever crosses the network.
Why a passkey cannot be phished
Here is the property most people miss. Each passkey is cryptographically bound to the exact domain it was made for — the relying party ID, in WebAuthn terms — and the authenticator refuses to sign for any other origin. A fake login page on beebeeb-login.example.com physically cannot trigger the passkey you registered on beebeeb.io. The browser and the authenticator check the origin below the application layer, where neither you nor the phishing page can reach.
No amount of "be careful what you click" matches that. With a password, a flawless replica of a real site harvests your secret and you never notice. With a passkey, the replica has nothing to harvest, because the structure does the work instead of your judgement.
Synced vs. device-bound: the real tradeoff
Two flavours exist, and each has a catch worth naming.
- Synced passkeys live in a credential manager — Apple's iCloud Keychain, Google Password Manager, a third party like 1Password — and follow you across devices. Lose your phone, sign in on the new one. The cost is that the convenience leans on that provider's cloud, and the ecosystems are still walled. iCloud Keychain does not sync to non-Apple devices; to sign in on a Windows or Android machine you bridge with a QR-code-and-Bluetooth flow that uses your iPhone to finish a single login.
- Device-bound passkeys, typically on a hardware key like a YubiKey, never leave the hardware. Smaller attack surface and full control, but lose the key with no backup and that credential is gone for good.
Cross-manager portability is finally arriving through the FIDO Credential Exchange Format. Export has shipped in early implementations and import is rolling out across managers through 2026. Until it is universal, the boring advice holds: register a passkey on more than one device, or keep a fallback you control.
Where a passkey fits in a zero-knowledge service like Beebeeb
This is the distinction that matters for an end-to-end encrypted product, and we would rather state it plainly than let it imply more than it does. A passkey secures the login. It proves you are you. It is not the key that decrypts your files.
At Beebeeb, the keys that encrypt your data are derived from your passphrase on your own device with Argon2id, and never touch our servers. Login itself uses OPAQUE, a password-authenticated key exchange that proves you know your passphrase without ever sending it to us. A passkey sits alongside that as a phishing-resistant way to sign in, removing one more reusable secret from the equation. The file encryption — AES-256-GCM under keys we never hold — is identical whether you log in with a passkey or not. You can follow the whole key chain on our security page, and the sign-in options are on the features page.
Passkeys are live on Beebeeb accounts today, next to TOTP two-factor and OPAQUE login.
So should you turn one on
For most accounts, yes. A passkey is safer than a password plus SMS and faster to use. The one thing to get right is recovery: register a second passkey or a fallback method before you lean on it, because a passkey you cannot reach is as good as a forgotten password. Set that up once, and the daily login becomes a fingerprint instead of a string you keep forgetting and an attacker keeps trying to steal.