Passkeys keep turning up in vendor pitches and browser prompts, and the pressure to add them to a product is real: they are backed by Apple, Google and Microsoft, standardised through FIDO2 and WebAuthn, and recognised by NIST’s SP 800-63-4 as a phishing-resistant authenticator. None of that tells you what changes in your codebase, your support queue and your compliance posture once you actually ship them. That is the part worth thinking through before committing engineering time.
What a passkey replaces, and what it does not
A passkey is a public-private key pair generated on a device and bound to your domain. The private key never leaves the device or its secure enclave; your server only ever stores a public key and a credential ID. Login becomes a challenge-response exchange instead of a password check, which is why credential-stuffing and phishing against the login form stop working: there is no shared secret to steal from your database or trick a user into typing on a fake page.
What it does not replace is your account model. You still need to know who a user is before you let them register a first passkey, you still need a way to add a second one, and you still need a path back in when every device with a passkey is lost, stolen or wiped. Vendors selling passkeys tend to lead with the login screen and leave those three problems for you to design.
The account recovery problem is the actual project
Passwords have a well-worn recovery flow: email a reset link, or fall back to a support agent who verifies identity manually. Passkeys break the assumption behind that flow, because there is no secret to reset — the credential is tied to hardware or to a platform’s keychain. If a user loses their only enrolled device, “reset your passkey” is not a meaningful sentence.
In practice this means designing, before launch, for at least these cases:
- A user with one passkey loses the device it lives on and has no other authenticator enrolled.
- A user switches from Android to iOS (or the reverse) and their platform’s passkey sync does not follow them.
- A support agent needs to verify identity for someone who cannot authenticate at all, without that process becoming the phishing vector you just closed off at the login form.
The usual answer is to keep a secondary factor around, at least for now: a verified email or phone number, or a second authenticator enrolled at signup and stored somewhere other than the primary device. Treat that fallback with the same scrutiny as the passkey flow itself, because it is where an attacker who cannot beat WebAuthn will go next. A recovery process that is easier to social-engineer than the login form it protects is a net loss, not an improvement.
Platform sync changes your threat model
The FIDO Alliance’s original vision was device-bound credentials, but the versions users actually meet today are mostly synced: iCloud Keychain, Google Password Manager and some browsers replicate the private key across a person’s devices inside their ecosystem. That is good for adoption, because it removes the “what if I lose my phone” objection for most users, but it also means the credential’s security now depends on the strength of that platform account, not just on possession of a physical device.
For anything where you need a stronger guarantee — admin accounts, financial actions, anything sitting behind a compliance requirement for a hardware-bound second factor — you may still want to support or require a roaming authenticator (a security key) rather than accept a synced platform passkey. WebAuthn lets you distinguish these at the API level through attestation and authenticator attachment, but only if you decide up front that the distinction matters for your use case, rather than discovering it after a security review.
Where this sits relative to build vs buy
Implementing raw WebAuthn — the challenge generation, attestation verification, credential storage, and the browser API calls on both registration and authentication — is a manageable amount of code, and most modern identity platforms (Auth0, AWS Cognito, Clerk, Ory) now support it directly, so you are rarely starting from the specification. The harder decision is whether passkeys sit on top of an authentication system you already run, or whether adding them is the trigger to finally move off a homegrown one.
If your current auth is already delegated to a managed identity provider, enabling passkeys is usually a configuration and UX exercise: turning on the feature, updating the sign-in screen, and building the recovery flow described above. If you are still running a hand-rolled password table, adding passkeys as a second authentication method on top of it roughly doubles the surface area you maintain, for a feature that most users will not fully adopt for some time yet. In that case it is worth asking whether the honest next step is migrating authentication wholesale rather than bolting a second scheme onto the first.
When it is worth building now
Passkeys earn their place quickly in products where credential theft is the realistic attack, and less quickly where it is not. A finance app, an HR system holding personal data, or anything an attacker would target with phishing benefits from cutting off that avenue as soon as the engineering cost is reasonable. A low-stakes internal tool with a handful of known users behind SSO already has less to gain from the exercise right now, and the recovery-flow work may not be worth doing twice as the standards and platform support continue to move.
Before scoping the work, it helps to be explicit about a few things:
- Does your identity provider already support WebAuthn, or does this require a migration first?
- What happens, step by step, when a user’s only passkey becomes unavailable?
- Do any account types need a hardware-bound credential rather than a synced one, and does your implementation let you tell the difference?
- Will passwords stay available in parallel for some period, and who decides when to retire them?
- Who owns the support process for the identity-verification cases a self-service recovery flow cannot handle?
Answer those before the first sprint, not during it. The login screen is the easy part of a passkey rollout; the recovery path is the part that determines whether it was worth doing.