The hard part of passkeys is not WebAuthn

I implemented passkeys for the first time, and my honest reaction is that the hard part is not WebAuthn. It is everything around it, especially account recovery.

The API is a weekend of work

Registration ceremony, authentication ceremony, verify the signature, store the credential. The spec is dense, but the libraries are good now. On the server, you generate a challenge, the browser asks the authenticator to sign it with a private key that never leaves the device, and you verify that signature against the public key you stored at registration.

That part is well understood and well supported.

Then the real project starts

What happens when the user loses the device? What does account recovery look like when there is no password to reset? Do you keep the password as a fallback, and if you do, did you actually improve security or just add a second door to the same room?

That last question ate two weeks of design discussion. A passkey next to a weak password fallback is a strong lock on a door with a broken window. Attackers will always go for the weakest way in, so your security is only as good as your worst login path.

Where we landed

• Passkeys first.
• Email magic link as recovery.
• Password gone entirely for new accounts.

Support tickets about logins dropped. Nobody asked where the password field went. Users adapt faster than product managers fear.

If you are still all passwords in 2026, the blocker is probably not technical.

Takeaways

• WebAuthn itself is a small, well-supported piece of work.
• Account recovery is the real design problem.
• A weak password fallback undoes much of the security a passkey adds.
• Passkeys first with a magic link for recovery worked well for us.