You’ve probably seen that little prompt that says “Sign in with Face ID” or “Use a passkey” instead of the traditional password field. That’s a passkey. And no, it’s not just a password hidden behind your fingerprint.
The best password is the one you never have to type.
The Problem with Passwords
A password is a secret that you have to remember, and that the website has to store (ideally hashed). The problem is that this system relies entirely on two weak points:
- You, who reuse the same password everywhere because you’re tired of coming up with a new one.
- The website, which can be hacked and have its password database leaked.
Add phishing to that: a fake website that perfectly mimics the real one can steal your password without you even realizing it. And this isn’t just a minor issue: as the Verizon DBIR report reminds us every year, social engineering, phishing, and stolen credentials remain among the leading causes of hacking worldwide, alongside software vulnerabilities.
Source: Data Breach Investigations Report, Verizon
Even with a password manager and 2FA, the fundamental vulnerability remains: a secret that you could accidentally share.
What exactly is a passkey?
A passkey is based on asymmetric cryptography, the same principle as SSH, if you've ever generated a key pair to connect to a server.
When you create a passkey for a website:
- Your device (phone, computer, security token) generates a key pair: a private key and a public key.
- The private key never leaves your device. It is stored in a secure chip: the Secure Enclave on iPhone/Mac, the TPM on Windows, or directly on the chip of a USB key such as a YubiKey.
- The public key, on the other hand, is sent to the website and stored on the server.
To log in, the site sends you a challenge (a random number), your device signs it with the private key, and the site verifies the signature using the public key. If they match, you're authenticated.
No secrets ever travel over the network only a signature. It’s written in black and white in the W3C WebAuthn spec: nothing to steal, nothing to phish.
Why It’s More Secure
| Password | Passkey |
|---|---|
| Shared secret, transmitted with every login | Nothing is transmitted, just a signature |
| Reusable across multiple sites | Unique per site, tied to the domain |
| Vulnerable to phishing | Resistant to phishing (tied to the exact domain) |
| Can be leaked in the event of a server breach | The server stores only the public key, which is useless to an attacker |
| Must be memorized or managed via a manager | Unlocked via biometrics or a local code |
The key point: a passkey is linked to the domain on which it was created. If you go to paypa1.com instead of paypal.com, your device won't even offer the passkey. It's the browser/OS that performs this verification, not you. Google explains it very well: unlike a password, a passkey is cryptographically bound to the site for which it was created, so it’s impossible to intercept or reuse on a fake site. They’re resistant to phishing by design, not because of the user’s good faith.
Under the Hood: WebAuthn and FIDO2
Technically, passkeys are based on the WebAuthn (W3C) standard, which is part of the broader FIDO2 standard promoted by the FIDO Alliance (whose members include Google, Apple, Microsoft, and Yubico). It is this API that browsers expose via JavaScript to create and use credentials.
Diagram of the registration flow, based on the W3C WebAuthn spec
Creating a client-side passkey looks like this:
const credential = await navigator.credentials.create({
publicKey: {
challenge: new Uint8Array(32), // provided by the server
rp: { name: "My Super Site", id: "mysupersite.com" },
user: {
id: new Uint8Array(16),
name: "thomas@example.com",
displayName: "Thomas",
},
pubKeyCredParams: [{ alg: -7, type: "public-key" }], // ES256
authenticatorSelection: { userVerification: "required" },
},
});
And to log in with an existing passkey:
const assertion = await navigator.credentials.get({
publicKey: {
challenge: new Uint8Array(32), // provided by the server
userVerification: "required",
},
});
The server generates the challenge, the browser handles all the biometrics and unlocking, and sends you back a signature to verify. On the server side, libraries like @simplewebauthn/server in Node.js do most of the verification work.
What if I lose my phone?
This is the question that stumps everyone, and if this topic resonates with you, I’ve already written an entire article on the hassles of 2FA after a phone theft, the same “single point of failure” principle applies to passkeys. Since 2022, Apple, Google, and Microsoft have added passkey synchronization:
- On iOS/macOS, they sync via your iCloud Keychain.
- On Android/Chrome, they sync via your Google Account, using Google Password Manager, which encrypts everything end-to-end.
- On Windows, via Windows Hello, although cross-device synchronization is even more limited there than with Apple or Google.
So if you lose your phone but regain access to your iCloud or Google account on a new device, your passkeys will be restored as well. You can also use a physical security key (YubiKey) as a backup, which doesn’t sync but works on any compatible device exactly the same advice as for traditional 2FA: never put all your eggs in one basket.
How to Use Them Today
More and more services already offer them: Google, Apple, GitHub, Microsoft, PayPal, Amazon, X... Google has even gone a step further by making passkeys the default for personal accounts. You’ll usually find them in your account’s security settings, under “Access Key” or “Passkey.”
The typical workflow:
- Go to the service's security settings.
- Click “Add an access key” or “Create a passkey.”
- Your browser or operating system will ask you to confirm using Face ID, Touch ID, Windows Hello, or your phone's passcode.
- That's it. The next time you log in, you won't need a password.
If you want to manage your passkeys somewhere other than your OS’s keychain (useful if you’re on multiple different platforms), ProtonPass can also create and store them—end-to-end encrypted—in the same place as your passwords.
Conclusion
| Question | Answer |
|---|---|
| What is it based on? | Asymmetric cryptography (private/public key pair) |
| Does the password travel over the network? | No, never |
| Resistant to phishing? | Yes, by design (domain-bound) |
| Technical standard | WebAuthn / FIDO2 |
| Device loss | Recoverable via iCloud/Google sync, or physical backup key |
Passkeys aren't just “a password hidden behind a fingerprint”, they represent a complete shift in the model: nothing to remember, nothing to steal. If a service offers you the option to create one, go for it it's significantly more secure and faster than your current password.
The ProtonPass link in this article is an affiliate link, which means I may receive a commission if you decide to sign up through this link, at no additional cost to you. This helps me cover hosting and domain name fees. Thank you for your support!


Top comments (29)
Great explanation. One thing I’d add is that passkeys are only one part of the authentication story. In practice, the overall security of an account is often limited by its account recovery process. If recovery falls back to weak email or SMS verification, attackers will usually target that path instead of the passkey itself. Authentication and recovery should be designed with the same level of security.
Yes totally!
I think the biggest hurdle now isn't the technology anymore, it's adoption.
WebAuthn has been solid for years, but many apps still default to passwords because they don't want to redesign recovery flows or support multiple authenticators.
Curious how many people here have actually shipped passkeys in production. Was the technical implementation the hard part, or was it the UX around recovery?
Great breakdown! I've been considering implementing passkeys for a side project, but I keep wondering about account recovery: what's your recommended strategy or fallback pattern when a user loses access to all their synced devices?
Some time ago developed system using passkeys widely , and answer to your question is: some secret question/answer on onboarding and getting other data related to user via support. (anyway at least user must remember password also even if losses passkey devices at all)
For me, I use Proton pass to save almost all my Passkeys
Implementing passkeys has been surprisingly tricky when dealing with cross-device authentication flows. I recently noticed that while WebAuthn handles the cryptography beautifully, syncing the credential across a user's ecosystem still relies heavily on the underlying OS vendor's implementation. Have you found any reliable fallback strategies for enterprise environments where users might not have a synced Apple or Google account on their work machines? It seems like the transition period is going to require supporting both passkeys and traditional MFA for quite a while.
As a developer working with secure systems, I appreciate how passkeys simplify authentication while improving security by removing reliance on password managers or local storage. It’s interesting to see FIDO2/WebAuthn finally gaining real traction—especially when combined with hardware-backed keys or secure enclaves. On projects involving VoltageGPU, we also look at how to securely offload cryptographic operations to the GPU, and passkeys align well with that kind of architecture.
Solid breakdown. 👊
I've been looking for a way to frame passkeys in a narrative context for an ongoing series I'm writing (36 Stratagems, AI security stories). The asymmetric key model — replace the shared secret entirely instead of making a better password — fits a few of the stratagems better than I expected.
The recovery flow point in the comments is gold too. Thanks for writing this.
Thank you! 🌞
nice
Thanks you!
I never really understood this, but now I do! Thanks!!!
Thanks for read my post !
@adamthedeveloper Exactly — the recovery path is the real threat model, and passkeys don't touch it. If I can trigger a "forgot device" flow that emails a magic link, I've just rebuilt password reset with extra steps. The phishing-resistant login becomes theater.
The part that bites teams: recovery is where the account-takeover volume actually lives, and it's the flow nobody tests against a determined attacker because it's the "sad path." I've watched a launch where the shiny new login was airtight and the recovery flow still fell back to SMS OTP, which is exactly the channel passkeys were supposed to kill.
"Weakest recovery mechanism" is a good way to frame it. The honest version is uglier though — real recovery usually means a second registered passkey, a hardware key in a drawer, or a support process with human identity checks, and all three cost UX or money. That tradeoff is the actual design problem, and "just add passkeys" quietly pretends it doesn't exist.
yup. btw i dont know why the previous comment of yours was hidden.
This main comment is hidden because it looks like it was written by an AI. But if a real person actually wrote the original text, I can display it.
ooooh, got it. now that i read it again, it does sound like one.
Aah I'm not alone aha 😅
It's like a bunch of words but an introduction and a resume of my post, not a relevant comment
How secure is that? Do I need to actively opt out and use a physical backup, like for private ssh keys, instead?
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more