Should your app use passkeys?
For most apps, yes — as an option people can choose, with a sound recovery path, rather than the only way in. Passkeys are the strongest defence against phishing that ordinary users will actually adopt. The criticism they attract in 2026 is about who controls them, and it is worth understanding before you design sign-in around them.
- Published
- 22 October 2026
- From
- Kramiva
01
What a passkey is
A passkey replaces a password with a cryptographic key pair. The private key stays on the person's devices and is unlocked with a fingerprint, face or device PIN; your server stores only the public key. Each passkey is unique to one service, so there is nothing to reuse across sites and nothing useful to steal from your database.
Crucially, browsers and operating systems only ever use a passkey on the site it was created for. A convincing fake login page on a look-alike domain simply gets nothing — which is why passkeys stop phishing in a way that one-time codes, which a phishing page can relay, do not.
02
What NIST now says
The US National Institute of Standards and Technology finalised its digital identity guidelines, SP 800-63B-4, in July 2025. Passkeys that sync between a person's devices are allowed up to its second assurance level (AAL2), though not the highest (AAL3), which requires a key that cannot leave the device. At AAL2, services must offer at least one phishing-resistant option.
The same guidelines have useful advice for passwords that remain: no composition rules, no forced periodic changes unless there is evidence of compromise, and a minimum of 15 characters when a password is the only factor, or 8 when it is one of several.
03
The case against
In October 2026, a widely discussed post titled “Passkeys are a trap” argued that users lose control of their credentials: that “passkey” hides many different variants, that attestation lets websites decide which devices and software are acceptable, and that the system favours large platforms. Its author recommends authenticator-app codes and hardware security keys instead.
04
The case for
The security researcher Scott Helme replied days later that synced passkeys report no attestation at all, that where attestation exists it identifies only the authenticator's make and model, and that consumer sites have long been advised not to require it. He also pointed out that hardware security keys — the critic's preferred alternative — are the devices that do provide attestation.
Both posts agree on one thing: what matters is how a service implements passkeys. That part is in your control.
05
Adding passkeys well
- Offer passkeys as an option at sign-up and in account settings, not as a forced migration
- Let people register more than one passkey, and see and remove them
- Do not require attestation for a consumer app; accept passkeys from any provider
- Keep a recovery route that does not depend on the lost device, and protect it as carefully as sign-in
- Keep any remaining password rules in line with NIST: length over complexity, no forced rotation
- Test sign-in on every platform your users have, including shared and older devices
Related services
Sources
- What are passkeys? — passkeys.dev (FIDO Alliance and W3C community)
- SP 800-63B-4: Authentication and Authenticator Management — NIST, 31 July 2025
- Passkeys are a trap — Non-Functional, 10 October 2026
- Passkeys are not a trap — Scott Helme, 14 October 2026
Accessed 22 October 2026. Kramiva is not affiliated with these publishers.
Tell us what you are building.
A short brief gets you a real reply from a founder within one business day — an honest read on fit, scope, and budget.