Skip to main content

Passkey Creation after Login Error

After a passkey attempt fails, an approved fallback can restore access and create an opportunity to add another usable passkey. The failed attempt does not prove the older credential is broken on every device or provider.

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 cancellation or failure can indicate that the expected passkey is unavailable on this client, for example after a device or credential-provider change. It does not prove that the passkey is broken everywhere.
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 one or more registered passkeys and the routing layer estimates that a passkey attempt is appropriate.
3

Passkey login errors occur

  • The user cancels or the passkey attempt fails.
  • Common causes include a deleted passkey, device change, different cloud account or logged-out password manager.
4

Complete approved fallback or recovery

  • After the declared passkey retry policy is exhausted, the user completes the relying party’s approved fallback or recovery for the same account, including every factor required by account policy.
5

Additional passkey creation is offered

  • After policy-compliant fallback, the user can add another usable passkey for future sign-ins.
  • Older server credentials remain accepted unless separately revoked. Provider-side storage may retain or replace a local passkey and must not be guessed.
6

System passkey-creation sheet appears

  • The platform asks the user to authorize creation with a supported device-unlock method.
7

Additional passkey creation succeeds

  • The relying party verifies and adds the new credential without claiming the older credential was repaired or removed.
  • The additional passkey can complete a later sign-in to the same account from this client.

Acceptance criteria

This flow restores passkey coverage after a passkey could not be used on the current client. A local failure does not prove that the registered credential is globally broken: a credential can remain usable through another device or credential provider.

References