Skip to content
FANKAARstudio

Security · 5 min read

Passkeys and the slow end of passwords

Passkeys are ready and adoption is uneven. What they are, what they fix, and whether your site should support them yet.

Passkeys replace a password with a key pair held by your device and unlocked with a fingerprint, face or device PIN. The private key never leaves the device and is never sent to your server.

What that actually fixes

  • Phishing. A passkey is bound to the site that created it, so a convincing fake cannot use it. This alone is the argument.
  • Credential stuffing. There is no shared secret to reuse across sites.
  • Breach impact. A stolen database contains public keys, which are useless.
  • Friction. Face or fingerprint beats typing a password on a phone.

What it does not fix

Account recovery, which becomes the weakest link and gets more important rather than less. If someone loses every device holding a passkey, your recovery flow is the entire security boundary. A poorly designed recovery email flow undoes the benefit completely.

Should you support them yet

SituationRecommendation
Consumer app with repeat loginsYes, as an option alongside existing methods
Store with guest checkoutLow priority. Most buyers never create an account
Internal toolYes. Controlled device estate, highest phishing risk
Anything holding money or health dataYes, and prioritise it

How to add them sensibly

  1. 01Offer as an additional method, not a replacement. Removing passwords before adoption is high locks people out.
  2. 02Allow multiple passkeys per account, so a phone and a laptop both work.
  3. 03Design recovery first, and treat it as the real security design.
  4. 04Explain in plain language at the prompt. Most users have not met this and "create a passkey" means nothing on its own.

The realistic position

Support is now good across major browsers and platforms, and the remaining friction is user familiarity rather than technology. Offering it costs little and the people who use it get materially better security. Requiring it, for most consumer sites, is still premature.

Working on something like this?

We build websites, stores and custom applications, and we will tell you honestly if the thing you are describing does not need one.