Passkey Recovery: What to Test Before You Require It

A passkey recovery drill tests how a teammate regains access when their usual authenticator is unavailable. Before requiring passkeys, rehearse an available backup credential and the loss of every usable credential. Verify who can approve replacement, which accounts remain accessible, and what happens to sessions that were already signed in.

That is a useful response to the argument running through Hacker News this week. Scott Helme’s October 14 post, “Passkeys Are Not a Trap”, challenges claims about passkey attestation. The discussion also raises ordinary access questions: where was the credential saved, what happens on another device, and who helps when it disappears? Those comments are anecdotes, not a measured failure rate. They still describe situations your rollout should handle.

You can support phishing-resistant authentication and demand a usable recovery process. For a startup, the way to assess that process is to try it before a teammate needs it during an interview or a production incident.

Start with a lost laptop

Use a test workspace and a fictional teammate, Maya. She has an interview in half an hour, her usual laptop is unavailable, and she needs the recruiting system from another browser. The rehearsal should establish what she can actually do, including the steps that require another person.

Write down her starting position before touching settings. Which credential normally gets her in? Where is it stored? Can she use her phone without the laptop? Is a separate security key already registered? Can she reach the email address used for recovery? Who has permission to help her?

These questions describe different dependencies. A phone may hold a synced passkey, receive a recovery email, and approve access to the password manager. Listing it three times does not create three independent ways back in.

First, leave a registered spare available and make the usual device unavailable for the exercise. Open a separate browser and authenticate with the spare. Seeing a second credential in an account’s settings is insufficient evidence: the test is whether Maya can use it from the environment she would have after the loss.

Then try adding a replacement credential. The application may demand a fresh authentication step before allowing changes, even when a page remains open. Note the exact point where it asks, which method it accepts, and whether the spare can complete that step.

Record the time and the obstacles you observe. You do not need a target borrowed from another company. You need enough evidence to decide whether your own team can tolerate the interruption and whether the instructions make sense without the person who designed them standing nearby.

Separate backup sign-in from passkey account recovery

Using a remaining registered credential is different from asking an application to establish trust again after every usable credential is gone. Your instructions should give those situations different names, because they ask different things of the user and the administrator.

The FIDO Alliance’s enterprise deployment paper distinguishes synced passkeys from credentials bound to a hardware key. Sync can help after replacing a device. A hardware key registered in advance can provide another authentication route. Its usefulness depends on whether it is available and supported in the environment where the teammate needs it.

Suppose Maya’s phone can use a synced credential after her laptop fails. That is a successful backup sign-in. Now suppose both devices depend on the same credential provider account, and access to that provider is also unavailable. The first successful test has not answered the second problem.

Keep an inventory that names the dependencies rather than counting devices:

This table is a planning aid. Put your actual observations alongside it in an internal runbook. A blank result means the route has not been tested, even if a vendor’s documentation describes it clearly.

Do not use “passwordless” as shorthand for everything involved in the recovery path. A passkey can protect one authentication ceremony while a provider account, mailbox, or administrator decision remains part of getting back in.

Rehearse losing the credential provider too

A synced passkey can improve availability, but the sync provider is another system your teammate may need to recover. Test what your application can do when access to that system is unavailable, rather than assuming another device will always supply the credential.

For this part of Maya’s drill, treat all usable passkeys as unavailable. Do this with a test identity; do not erase a production administrator’s credentials to make the scenario realistic. Follow the application’s documented route from a fresh browser and note the first requirement she cannot meet.

Perhaps she can still sign in with another method and reach a restricted enrollment page. Perhaps the application permits only passkeys and sends her to a separate identity recovery process. Perhaps an administrator can issue a narrowly scoped replacement permission. These are materially different recovery designs.

The FIDO paper on synced passkey deployment discusses alternative authentication and recovery alongside synced credentials. The operational lesson is to examine both the credential provider’s process and the application’s process. One working route does not prove the other works, and the word “passkey” does not promise export between your chosen providers.

Ask Maya to follow the instructions without access to her usual notes or browser bookmarks. If the runbook lives behind the same access gate she is trying to clear, make the necessary recovery instructions available through another appropriate channel.

Also test the delivery address. A recovery message going to an old mailbox can turn an otherwise sound procedure into an access failure. An address that belongs to the person requesting help still does not establish that the request is legitimate if mailbox compromise is part of the scenario.

Decide who can authorize a replacement

Administrator-assisted recovery transfers trust to the person approving the request and the evidence they accept. Name that responsibility before enforcement, including who acts when the usual administrator is unavailable.

Maya’s message arrives: “Lost my phone and laptop. Can you reset my passkey?” The approval should depend on a procedure that your administrator can explain and repeat. A convincing display name and an urgent email reply are weak grounds for granting a new way into a workspace containing candidate information.

Use an independent channel appropriate to your team and the risk. For example, an administrator could call Maya using contact details already held through a trusted process. Do not take a new phone number supplied in the same recovery request as independent confirmation. Record that the check occurred without collecting unnecessary personal information in a support ticket.

NIST’s authentication and authenticator management guidance treats recovery separately from authentication with remaining authenticators. It describes recovery methods within an assurance framework, calls for recovery notifications, and addresses risk analysis for application-specific methods. You can use it to examine your design without claiming your startup or vendor meets a particular assurance level.

For the drill, ask the administrator to explain exactly what their action grants. Does it allow one replacement enrollment, open the whole application, reset another factor, or disable a policy for everyone? Prefer an action whose scope and duration match the task you have approved.

Then make that administrator unavailable in the scenario. Who else can perform the same authorized action? Can they find the procedure and verify Maya? If nobody can, record that availability limit and decide whether it is acceptable before you require the credential.

Do not silently turn a workspace policy off to make the exercise pass. If relaxing enforcement is an explicit emergency option, document who may authorize it, what access it opens, and how you will restore the policy. That decision deserves its own record.

Check what stays signed in

Replacing a credential and ending existing access are separate operations. Your recovery drill should establish what happens to old browser sessions and connected tokens, especially when a device might have been stolen.

WebAuthn’s credential and assertion model scopes public-key credentials to a relying party and specifies validation during authentication. Those properties underpin phishing resistance when correctly implemented. They do not mean every later request repeats the ceremony, or that deleting a credential automatically cancels a previously issued session.

Return to Maya’s original browser after replacement. For a controlled exercise, use another test browser to represent the unavailable device. Can it still read data? Can it change settings? Does removing the old credential alter either result? Observe the behavior rather than assuming the name “reset” implies a complete account cleanup.

Next, inspect the tools connected to the account. An API token may continue to work because it is an independent credential. An assistant connection may have its own authorization and revocation controls. Decide which should remain available during ordinary device replacement and which should be revoked when compromise is suspected.

Our SSO offboarding acceptance checklist covers related questions about sessions and connected access. The same distinction matters here: a change in how someone authenticates does not, by itself, establish which previous permissions or credentials have ended.

Record the result in concrete terms: the old browser was revoked, the missing credential was removed, and a named token was rotated, if those actions actually occurred. “Account recovered” is too broad to tell the next administrator whether an attacker could still hold a usable session.

Make the rollout decision from the drill

Require passkeys when you understand the supported authentication routes and have accepted the remaining recovery limits. A successful drill should produce a usable procedure, an accountable administrator, and a record of the access that survives replacement.

Keep the evidence compact. For each scenario, write the starting condition, the route attempted, the observed result, and the change needed. Note where the process depended on a particular person, mailbox, provider, or device. Fix the failed steps and rehearse those steps again before widening enforcement.

Separate the technical result from the decision. “The spare key authenticated from the replacement laptop” is an observation. “Every teammate should register a separately available spare before rollout” is your policy choice. “We accept a delay until an authorized administrator returns” is another possible choice, provided the affected team understands it.

You can track completion time, support requests, and abandoned enrollment attempts during your rollout. Those are measurements for your own process. They do not require an invented industry baseline or a promise that passkeys will reduce your support workload by a particular percentage.

Finally, communicate what people should do before the requirement starts and how they ask for help afterward. Tell them where their credentials are managed, which spare routes your team supports, and what an administrator will ask before permitting replacement. A short message tied to a tested procedure is more useful than a broad assurance that nobody will be locked out.

What passkey recovery looks like in Kit

Your application must make its access and recovery boundaries clear enough to rehearse. In Kit, a passkey belongs to the person, while an account can require passkey verification before a browser opens that workspace. This is team access to the product; candidate portal access is a separate flow.

Before enabling the requirement, the administrator taking that action must already hold a passkey. The setting uses the manage security permission, available to Admin and Security Analyst roles. There is no general owner exemption. Review the member compliance table first: enforcement takes effect immediately, with no built-in grace period or staged rollout.

A browser must have passkey verification recorded for its session. A teammate having a credential enrolled is not proof that every existing browser has used it. Once verified, that session can remain compliant for its lifetime; the policy does not demand a new assertion on every page. A session authenticated through enforced SAML can also satisfy the requirement. The strength of that authentication depends on your identity provider’s policy.

If a signed-in teammate loses every passkey, an authorized security administrator can issue a re-enrollment pass. Kit emails it directly to the member. Opening the link shows a confirmation page; confirming uses the pass and opens a 15-minute enrollment window for that account. The pass is single-use within 24 hours, and issuing another supersedes the previous one. The requiring passkeys documentation explains the flow.

That route still requires the member to be signed in as the matching user. It is not a promise to recover a completely inaccessible Kit identity. The administrator must verify the request independently, and email delivery remains part of the trust path. Re-enrollment also does not automatically revoke old browser sessions.

API tokens and MCP connections have a different limit: they check whether their user has a passkey enrolled, rather than performing a WebAuthn assertion. Treat that as weaker assurance than passkey verification in a browser when assessing connected tools.

Run the drill against these boundaries before enabling the setting. Start with the passkey setup guide, then test replacement and review sign-in security with another authorized administrator. The useful outcome is a teammate who can follow the recovery procedure and an administrator who knows exactly what access they have restored.