Set enrollment rules
Choose whether one or several passkeys can be enrolled and how customers name and remove them. A synced passkey can appear on another device, so decide whether that counts as a new-device event. Test a lost device and a compromised email separately. Add notices for new credentials and removed credentials. Keep a recovery path that does not let a support caller bypass all checks with public account facts.
Test the full credential lifecycle
Enroll passkey A, add passkey B, sign in with both, remove A, and try A again. Then lose the device with B and use the recovery path. Record credential IDs, enrollment and removal times, session state, and notices. A synced passkey on a new phone may be a valid sign-in but still meet the bank’s new-device rule for transfers. State that policy before testing. An unknown passkey removal should also give the customer a way to review active sessions.
Test cases and proof
| Case | Expected result | Proof to keep |
|---|---|---|
| Second passkey added | Verify and notify | Credential inventory |
| Synced passkey used on new device | Apply device-risk policy | Sign-in event |
| Last passkey lost | Use controlled recovery | Support trail |
Check origin and user verification
Register a passkey for login.example.test, then try to use it from lookalike.example.test. The RP ID and origin check must reject the lookalike. Test registration and authentication with user verification required, then test a synced passkey on a second device under the product’s policy. Save challenge ID, origin, RP ID, credential ID, UV flag, sign counter handling, and result; never save private keys. A passkey launch also needs a recovery path, duplicate registration policy, and a clear way to remove a lost authenticator. (W3C WebAuthn Level 3).
Bind the challenge to the right account
Create registration challenge C-01 for synthetic account A, then try to finish it while signed in as B. The server must reject the account mismatch. Complete C-01 for A, then submit it again; the consumed challenge must fail. In authentication, verify the expected challenge, configured origin allowlist, RP ID hash, signature, and required user-verification flag. A valid signature alone cannot replace those checks. Register two credentials, remove one, and keep the other usable. A synced credential ID does not prove which physical phone used it. If transfer policy needs device identity, test the separate device signal and record its limits.
Do not reject synced credentials by counter alone
Include an authenticator that returns a zero sign counter and a synced credential whose counter does not behave like one device’s strictly increasing number. Record the counter decision under the WebAuthn rule and the product’s risk policy; a counter anomaly is a signal to assess, not universal proof that a valid credential is a clone. The positive case must still complete the full origin, challenge, signature, and user-verification checks. Save backup eligibility and backup state flags when the server uses them. Test that enrollment cannot replace another user’s stored public key merely because a duplicate credential ID is supplied. Keep registration ownership and authentication results linked.