Passkeys are often introduced as a sign-in improvement: less typing, fewer passwords, and stronger protection against phishing. That is real value, but it is not the product decision customers will remember.
They will remember the morning they replace a phone, lose a laptop, or find that an unfamiliar device is trying to enter their account. At that point, the question is not whether the sign-in ceremony is elegant. It is whether the product can help the right person regain control without quietly making it easier for the wrong person to do the same.
The recent WebAuthn Level 3 Recommendation gives teams a stable web standard for public-key credentials. It does not choose an account-recovery policy for them. That policy still belongs to product, design, engineering, support, and security together.
Define the recovery promise before the sign-in screen
“Support passkeys” describes a capability. A useful requirement describes the person and the moment that matters:
An account holder who changes their primary device can regain access through a deliberate, understandable path without lowering the account’s normal security.
That sentence is intentionally more demanding than “the customer can reset their password.” It prompts the decisions that determine whether recovery is dependable:
- Which events count as recovery: a new device, a missing authenticator, a forgotten password, suspected takeover, or all of them?
- What evidence is strong enough for this account and this action?
- When should the product let a person add a new credential immediately, and when should it introduce a delay, notification, or review?
- What can support do, and what must support never be able to bypass?
- How will a customer recognise that control has actually been restored?
The answers should vary with the consequence. A reading app and a payroll system should not recover accounts in the same way. The right aim is not to create the most frictionless path in isolation. It is to make the path proportionate, clear, and safe for the job the account enables.
Treat a device change as a journey, not an exception
Many passkey experiences work beautifully until the original device is unavailable. The implementation may be correct while the product journey is incomplete.
Map the ordinary changes before launch. For each one, write the acknowledgement, available evidence, state changes, customer communication, and safe next action.
- A trusted device is still available. Let the customer add or confirm access on the new device from an authenticated session. Explain what is being added and notify them afterward.
- The old device is gone. Offer the recovery method that was prepared for this account—not an improvised route that depends on the very credential that is missing.
- A new credential is registered. Make it easy to see its date and approximate device context, rename or remove it, and review active sessions.
- The account may be compromised. Separate recovery from containment: revoke sessions or credentials where appropriate, send a clear security notice, and avoid a silent handoff of control.
NIST describes syncable authenticators—commonly called passkeys—as a way private keys may be synchronised between devices, with benefits that can include phishing resistance and easier recovery. It also stresses that the choice brings threats and policy considerations, not a universal answer. The NIST supplement on syncable authenticators is a useful reminder to design for the account’s context instead of treating synchronisation as a recovery plan by itself.
Do not hide a weaker fallback behind a stronger front door
Public-key authentication can be phishing-resistant because the cryptographic exchange is bound to the intended verifier or channel. NIST explains that a manually entered one-time code is not phishing-resistant in the same sense: it can be relayed to the legitimate verifier by an impostor site. See its guidance on phishing-resistant authenticators.
That does not make every fallback wrong. It means a fallback is part of the security design, not an embarrassing edge case to bury in a help article. If a person can add a new passkey after clicking a link in a long-lived inbox, the account may be no safer in practice than that inbox. If a support agent can override every factor after a persuasive phone call, the support process has become the authenticator.
Make each fallback explicit:
- state what it proves and what it does not prove;
- use a different, pre-established factor where the risk warrants it;
- notify the account through an independent channel when a recovery or credential change happens;
- delay high-impact changes when that creates a meaningful chance to stop fraud; and
- give the customer a visible way to report an action they did not take.
For a lower-risk service, verified email plus a security notification may be a proportionate choice. For financial, administrative, or regulated access, recovery may need stronger evidence and a carefully designed review. The product should say this plainly rather than presenting a generic “we could not verify you” dead end.
Give people control they can understand
Credential management is part of the recovery experience. After customers regain access, they need to know what remains trusted.
Avoid making them decode internal implementation terms. A practical account-security page can answer four direct questions:
- Which sign-in methods and sessions are active?
- Which one was added or used most recently?
- How can I remove access I no longer control?
- What happens next if I do not recognise this activity?
The WebAuthn specification describes credentials as key pairs scoped to a relying party, while allowing people to use an available authenticator method such as a device PIN or biometrics. That flexibility is useful only if the surrounding product makes its consequences legible. A customer should be able to remove a lost device without being asked to identify its hardware model, and should understand whether removing it signs it out immediately.
Use clear, non-alarming confirmation language. “New sign-in method added. If this was not you, secure your account” gives an account holder an immediate decision. “Credential created” asks them to translate system language while they are already uncertain.
Measure recovery quality separately from sign-in success
Authentication dashboards often stop at successful and failed sign-ins. A polished recovery flow needs a small set of journey signals too:
- recovery started, completed, abandoned, and escalated to support;
- time to restored access, separated from time spent under a deliberate security hold;
- newly added credential or session later revoked as suspicious;
- repeated recovery attempts for the same account; and
- customer reports following recovery or security notifications.
Review those signals by account type and recovery route. A low completion rate may indicate confusing instructions. An unusually fast completion rate may expose a path that is too easy to abuse. More prompts are not necessarily safer; more evidence about the real journey is usually more useful.
Test the moments when certainty breaks: a lost primary device, an expired recovery route, an attacker who controls one channel but not another, a newly added device, and a customer who needs to remove access after a successful recovery. Invite support and quality engineers to run the flows before release. They will find unclear language and unsafe shortcuts that a happy-path sign-in test cannot reveal.
Stronger sign-in begins with a stronger recovery promise
Passkeys can remove a great deal of password friction and help resist common phishing attacks. Their product value is realised only when recovery is equally intentional. Define the evidence, map device changes, make fallbacks honest, and give customers a clear way to see and revoke trust.
The result is not merely a new sign-in button. It is an account that remains understandable and defensible when someone’s circumstances change.
If your next product needs design, engineering, quality, and security to make those decisions together, bring BugSquad the challenge.