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 pas...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
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
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.
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.
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?
The phishing-resistance story is airtight for the cryptographic ceremony, but it quietly assumes the attacker has to go through the ceremony at all. The real soft spot is the account recovery flow behind the passkey. Most services still let you fall back to "email me a login link" or "answer these security questions" if you can't produce a passkey — and that fallback is exactly the phishable, socially-engineerable path the passkey was supposed to eliminate. An attacker doesn't fight your Secure Enclave; they call support or trigger the recovery email and route around it. Your effective security is the max of passkey-strength and whatever-your-weakest-recovery-path is, not the min.
That's also why the sync story deserves a sharper caveat than "eggs in one basket." Once passkeys sync through iCloud Keychain or Google Password Manager, the private key's security collapses onto your cloud account's security — which for most people is a password plus a phone-based 2FA. A synced passkey is only as unphishable as the account it syncs through, and that account usually isn't passkey-only. The hardware-bound YubiKey case is genuinely "private key never leaves the chip"; the synced case is "private key never leaves the chip, unless you count the chip as your entire Google account." Worth naming that distinction explicitly, because the two get sold under one word.
100%. Passkeys fix the front door, but if the back door is still a legacy email link, the effective security of the app hasn't actually changed. might need to start evaluating auth security by its weakest recovery mechanism.
Good introduction, thank you!
One question: you said that "a passkey is cryptographically bound to the site for which it was created". How exactly is that achieved?
This was a good read. I've heard of this before when I was learning about SSH, so as a newbie, I really appreciate this post. And I especially appreciate the "What if I lose my phone" part because I always wondered what'd happen if I lost my laptop at any point when using passkeys for anything. I don't think I have many passkeys set up on my accounts, only using it for some services I use, so I'll definitely be incorporating that more. Thanks!
This is helpful. I don't think the problem with passkeys is the technology but rather the adoption of the technology. When presented the choice to use a passkey in any condition, I turn it down. Instead, I'd rather use entropy focused or dictionary focused password generation be something that I just keep up with and use a program like 1Password. I have been a Visionary ProtonMail subscriber for many years now and I am familiar with ProtonPass and enjoy using it. I still built and made open source password generators that I wrote - before AI - and made open source.
The domain-binding detail is the part that actually sells this over passwords for me a password manager can still be tricked into autofilling on a lookalike domain if a user overrides the warning, but the browser/OS simply won't offer the passkey at all on
paypa1.com. That's the phishing-resistance being structural instead of relying on user vigilance.The account recovery point in the comments is the real weak spot though, and I don't think this article oversells past it. If iCloud/Google sync is the backup mechanism, then the passkey system's security now inherits whatever the recovery flow for that account looks like, which for a lot of people is still an SMS-based reset or a support ticket. You've basically moved the attack surface up one level instead of removing it.
Curious how you'd handle a site that wants to support passkeys but also needs a break-glass recovery path for someone who loses their device and their iCloud/Google access at the same time is a physical backup key (YubiKey) the only real answer there, or are sites building something softer than that in practice?
Came here for a simple explanation. This was anything but. This site is aimed at developers but a normie friendly explanation is needed. The most helpful section of the article was what happens if I lose my device. The article still doesn't answer the question of whether passwords will continue to work if I set up passkeys. And what is the point of storing my passkeys in Google password manager ifgoogle sign in itself needs a passkey
The article does not specify whether passwords will be replaced, but that is a possibility. It mainly explains how a passkey works