Passkey Recovery Handoff for an Offshore Product Team

Recovery changes the passkey threat model

Treat recovery as a security ceremony, not a forgotten link beside sign-in. Diagram registration and assertion challenges, relying-party identity, allowed origins, user verification, discoverable credentials, attestation posture, credential naming, and revocation. Then draw the paths for a new device, a lost device, a stolen authenticated session, a deleted platform credential, and a person who has lost every enrolled authenticator. Each fallback must state what proof it accepts and what authority support holds. Test replayed challenges, wrong origin, wrong RP ID, missing verification, cloned support evidence, repeated recovery, revoked credentials, and notification failure. Do not log challenges, authenticator data, session secrets, or identifying support material unnecessarily. A recovery that is easier to phish than the primary method can erase the security benefit. Product, security, privacy, and support owners approve the final journey; engineering demonstrates exact state transitions and audit evidence.

Write the account states on paper before designing screens: no credential, one usable credential, several credentials, a revoked credential, a lost device, and an account with no remaining authenticator. For each state, identify who may add or remove a credential and what proof that action requires. A recovery email that skips those rules is another authenticator, even if the interface calls it support.

Keep WebAuthn checks intact

Exercise registration and assertion with the exact relying-party ID and origins used by the product. Preserve challenge creation and consumption, user verification requirements, credential identifiers, and the result of signature verification. Then send a reused challenge, a response for another origin, a response for another relying party, and a revoked credential. The expected result belongs in the test record beside the observed result.

Do not use logs as a second credential store. The evidence needs safe identifiers and decision reasons, not challenges, session cookies, signatures, or support documents. If a failure cannot be diagnosed without sensitive material, security and privacy owners should define a narrower diagnostic field rather than letting developers improvise.

Buyer decision record

Scroll sideways to read every column on a small screen.

Test device loss as a journey

Maintain an account-state ledger for the test persona: verified contact methods, enrolled credential IDs, backup eligibility and state where exposed, active sessions, recovery holds, notifications, and support actions. Verify that adding a passkey from an existing session follows the organization’s reauthentication rule. Recovery should not automatically preserve sessions that the incident model says may be compromised. Test two tabs attempting recovery, delayed email delivery, an authenticator restored from platform backup, and a user who recognizes an unexpected enrollment notice. Give support staff bounded outcomes rather than raw credential data. The handoff should state which uncertainty requires specialist identity review and which customer-facing claims are intentionally avoided.

A lost phone is not one case. The user may still have an authenticated laptop, a synced credential on another device, a recovery factor, or nothing. Run each path with a synthetic account. Check which sessions survive, when notifications arrive, whether a hold applies, and whether an attacker with an old session can add a fresh credential during recovery.

Give support bounded authority

Support needs explicit outcomes: explain an existing path, start a reviewed recovery case, place a temporary hold, or escalate. It should not receive raw authenticator data or silently override verification because a caller sounds convincing. Record the evidence support may request, retention rules, approval owner, rate limits, and the event sent to the account owner. Test repeated attempts and two agents handling the same case.

Reconcile sessions and credentials

Successful recovery should end in a known account state. List active credentials, remove those the user or security owner has revoked, and decide which sessions must end. Confirm that an old credential fails after revocation and that an unexpected enrollment triggers a useful notice. A green sign-in test is incomplete if compromised sessions or recovery artifacts remain usable.

Make notifications useful under attack

Send notices when recovery starts, when a credential is added or removed, when support changes a hold, and when recovery completes. The message should name the action and provide a safe route to report an unrecognized change without embedding a reusable recovery secret. Test delayed delivery, duplicate delivery, and a mailbox that an attacker may already control. An email cannot be treated as independent warning evidence when email possession is also the recovery proof.

Rate limits should cover account, contact method, network source, device, and support workflow as appropriate to the reviewed threat model. Test repeated starts, alternating identifiers, simultaneous browser tabs, and a recovery attempt while another hold is active. Record which state wins and how a legitimate user regains access after the limit. A generic success screen can reduce account discovery, but the internal event still needs a precise decision reason.

Review authenticator replacement on an active session

An authenticated session may be stolen even when the original passkey remains secure. Require the organization’s approved reauthentication before adding a credential, changing recovery contacts, or removing the last known authenticator. Test a recently authenticated session, an old session, a session created before recovery began, and a session that loses authorization during the ceremony.

After a replacement, show the user enough information to distinguish credentials, such as the approved device label and enrollment time, without exposing authenticator internals. Verify the user can revoke the unexpected entry and that security can trace the event through safe identifiers. Product copy should not promise that a displayed device name proves physical possession.

Acceptance and handoff

The journey passes when valid credentials work, revoked credentials fail, challenges cannot replay, origin and RP checks reject neighbors, and total device loss follows the approved recovery proof with timely notification. Any support shortcut, reusable recovery artifact, silent enrollment, or missing revocation evidence keeps the feature in review.

The handoff includes account-state fixtures, browser and authenticator conditions, RP and origin settings, allowed fallback factors, notification results, denial evidence, support permissions, and open decisions. Product owns the recovery experience. Security approves proof and session consequences. Support owns the operating procedure. The developer implements the reviewed transitions and must stop when a requested shortcut changes that authority.

Questions about assessing Philippine developers