Passkey Creation after Error
After a passkey login error, users may need to complete an approved fallback before adding another passkey. This flow covers that recovery case on desktop and mobile web.Common Scenarios leading to Passkey Login Errors
Passkey login errors can occur in several situations:- Locally deleted passkeys: The user has deleted their passkey from their device or password manager
- Different cloud account: The user is using a familiar device that is now connected to a different iCloud account or, on Android, a different Google account
- Logged-out password manager: The user has signed out of their password manager that stored the passkey
How Readiness Logic supports Recovery
A readiness layer can use repeated outcomes and successful policy-compliant fallback as evidence that another usable passkey may help. A local failure does not prove an existing credential is broken everywhere. The relying party does not silently revoke an older server record, although the active credential provider may replace its own provider-side passkey.1
User enters identifier
- User enters their identifier (email/username) on the login page.
- System now knows which user account is attempting to log in.
2
System routes an account with registered passkeys
- Server state shows that the account has one or more registered passkeys, and the routing layer estimates that a passkey attempt is appropriate in this context.
3
Passkey login errors occur
- User encounters one or more passkey login errors.
- Common causes: deleted passkey, different cloud account, logged-out password manager.
- System recognizes repeated login failures.
4
Complete approved fallback or recovery
- After the declared passkey retry policy is exhausted, the user completes an approved fallback or recovery for the same account, including every factor required by account policy.
5
Recovery: Passkey append initiates
- After policy-compliant fallback, the user is offered an option to add another usable passkey for future sign-ins.
- Older server credentials remain accepted unless a separate lifecycle decision revokes them. Provider-side storage may retain or replace a local passkey and must not be guessed.
6
System passkey-creation sheet appears
- The user authorizes creation with a platform-supported device-unlock method.
7
Additional passkey creation succeeds
- The relying party verifies and adds the new credential to the account.
- The new passkey can be used for future sign-ins; this result does not claim that an older credential was repaired or removed.
8
Redirection to app dashboard
- User is redirected to the app dashboard.
Acceptance criteria
A web authentication exception is not proof that a passkey was deleted or
is permanently broken. This flow creates an additional usable credential;
the relying party does not silently revoke older server records or infer
provider-side replacement from a successful client ceremony.
References
- Relevant criteria: W2.5-AC01–AC02 and W2.5-AC04–AC05: How to get high passkey adoption in creation flows covers recovery eligibility after fallback, additional-passkey messaging, successful creation and state-aware re-evaluation.
- Relevant criteria: W2.5-AC01–AC02: Ultimate WebAuthn errors in production guide covers requiring context beyond ambiguous browser exceptions and avoiding unsupported repair or replacement claims.
- Relevant criteria: W2.5-AC01: Passkey fallback and recovery covers triggering recovery-oriented creation only after policy-valid fallback and evidence of an access problem.
- Relevant criteria: W2.5-AC02–AC05: Passkeys user journeys covers adding rather than replacing passkeys, preserving multiple credentials and later use of the added credential.
- Relevant criteria: W2.5-AC03: NIST SP 800-63B: Authenticator event management covers permitting multiple authenticators and requiring separately authorized, risk-based invalidation.