Draw the recovery paths
List the exact paths that can add or replace a passkey. Include a signed-in add flow, a lost-device flow, support-assisted recovery, and any fallback to email or SMS. Mark which identity proof each path accepts and when a new credential becomes active. If one path is much weaker than normal sign-in, an attacker can target it instead of the passkey prompt.
Use a synthetic account to test a lost phone. Do not let the tester control every channel at once: first give them only email access, then only a phone number, then only public account facts. Record whether each combination can enroll a new passkey. Repeat after a recent password reset or new-device event. Check notices to trusted channels and the rule for high-value actions after recovery. A support override needs a named actor and a recorded reason.
Test cases and proof
| Case | Expected result | Proof to keep |
|---|---|---|
| Lost device; attacker controls email | Do not silently enroll passkey | Recovery record |
| New passkey added | Notify old trusted channels | Notification proof |
| Recovery followed by transfer | Apply step-up or hold rule | Transaction decision |
Synthetic example
A customer loses their only device. An attacker has access to the customer’s email, but not the old device. Walk through the exact recovery path and note when a new passkey becomes usable. Send notice to an earlier trusted channel before high-risk activity resumes.
Protect the next transfer, not just sign-in
A recovered account can have a fresh passkey controlled by the legitimate customer or by an attacker who passed a weak reset. A notice to an old trusted channel helps the customer spot a change, but the policy may also delay a new beneficiary or large transfer until recovery risk settles. Set that policy before testing. Record when the new credential becomes active, when old credentials are removed, and what action triggers extra proof. Make sure the legitimate lost-device customer has a route to regain service.
Related reading
Why these checks matter
FIDO explains how passkeys work as phishing-resistant sign-in credentials. NIST’s recovery guidance sets out separate rules for regaining access and calls for recovery notice. A passkey does not remove the need for a recovery path. The test checks whether that path can add a new credential with weaker proof than the account policy allows.
Use a true lost-authenticator fixture
First test ordinary alternate sign-in: account A has passkeys P1 and P2. Losing the device with P1 while P2 still works can permit sign-in and binding a replacement. That is different from full account recovery. For the recovery fixture, remove access to every authenticator needed by the stated assurance policy, then test the documented recovery method. Do not label a successful P2 login as proof that lost-all recovery is safe.
Name whether the passkey is synced or device-bound. A synced credential may be available on another device through its provider account, so losing one phone need not mean losing it. The relying party still tests its own recovery and new-credential binding; it must not assume possession of a device label proves the passkey was used.
Compare the exact proof set
For synthetic account A, the recovery policy may require a saved recovery code and a separate check, or repeated identity proofing when no usable authenticator remains. These are example paths, not a universal rule for every bank. Test email-only control against the policy, then run a legitimate lost-all case with the accepted proof. Record whether any old authenticator or session remains active and when sensitive actions resume.
Use NIST’s Authenticator Event Management section for binding and recovery scope. Its assurance rules depend on IAL and AAL; define those before claiming NIST compliance. Keep recovery event, evidence types, new credential ID, notification delivery, and affected sessions without recovery secrets. An undelivered notice needs its documented handling path rather than a silent “sent” success.