Passkey Login: Error States

This page covers the passkey failures that change retry and fallback behavior in a native app. These error states are part of a fallback and recovery strategy that preserves an approved next route without silently weakening account assurance. Error scenarios, user experience while general login into the application.

iOS
Android

Account cannot continue with this route

Follow the product’s declared enumeration policy and direct the user to the available recovery or support route.

Error: system / API error related to lookup

An internal error occurs while looking up the user/account.

Error: general passkey login error

Something went wrong with passkey authentication unrelated to user input.

Error: tried deleted passkey

User attempts login with a credential that has been deleted.

Restricted account state

A valid passkey does not bypass closed, disabled, inactive, locked or restricted account states.

Error scenarios, user experience while login into the application via passkeys.

Handling passkey ceremony aborts: When users cancel or abort passkey authentication, provide a clear next step and a retry option where appropriate. See passkey ceremony aborts and fallback strategies for implementation guidance.

iOS
Android

Passkey login aborted during OS prompt (first attempt)

User begins the passkey login but cancels or dismisses the OS-native authentication prompt the first time.
An automatic route returns without an error and offers a deliberate retry. It does not reopen until the user chooses retry.

Passkey login aborted during OS prompt (subsequent attempts)

After the second consecutive cancellation of an automatic route, stop opening passkey login and show the configured fallback.

Explicit passkey login is cancelled

Return to the unchanged login screen without an error or forced fallback.

The selected passkey is no longer accepted

Explain that this passkey can no longer sign in and offer another passkey plus fallback.

Acceptance criteria

Benchmark as	User reach
Baseline	Mid

This baseline covers cancellation, unavailable credentials and server-side login failures across native passkey routes.

ID	Level	Acceptance criterion	How to verify
N1.4-AC01	Core	When the app starts passkey login automatically, the first cancellation returns to the login screen without an error and offers an explicit retry. Do not reopen the ceremony until the user chooses retry. After the second consecutive cancellation, stop automatic passkey prompts and show the configured fallback. A successful login resets the cancellation count.	Cancel the first automatic ceremony and confirm that retry is available without another prompt opening. Cancel the retried ceremony and confirm that fallback appears. Complete a login and confirm that the next cancellation is treated as the first.
N1.4-AC02	Core	When the user starts login from the normal passkey button, outside the retry offered after an automatic attempt, cancellation returns to the unchanged login screen without an error or forced fallback.	Start a passkey ceremony from the normal passkey button and cancel it repeatedly. The passkey button and other login methods remain available, and no automatic redirect occurs.
N1.4-AC03	Core	A lookup timeout, network problem or server error is not treated as proof that the account or passkey does not exist. Do not start a passkey ceremony from incomplete lookup data; offer a fresh retry and the available fallback.	Fail each lookup dependency before route selection. Confirm that no account or credential conclusion is shown, no passkey request starts, and retry performs a fresh lookup.
N1.4-AC04	Core	When the server no longer accepts the selected credential, explain that this passkey can no longer sign in and offer another passkey plus fallback. Send an unknown-credential signal only when the credential ID is conclusively absent from server records. A credential known to the server but revoked through account settings uses full-list reconciliation instead.	Attempt login with a credential revoked through settings and with a credential ID absent from server records. Confirm the message and both next actions. Only the absent ID emits the unknown-credential signal; revocation uses full-list reconciliation.
N1.4-AC05	Core	A valid passkey assertion does not bypass the current account status. Closed, deleted, disabled, inactive, locked or restricted accounts do not receive a session and follow the configured account-status or recovery route.	Submit a valid assertion for every account state. Only an account currently allowed to sign in receives a session.

References

Relevant criteria: N1.4-AC01–AC03: Apple: Authorization error codes, Android: Credential retrieval exceptions and Android: PendingGetCredentialRequest cover native cancellation, request failures and assisted-request results.
Relevant criteria: N1.4-AC01–AC04: Corbado: Passkey fallback and recovery covers cancellation, retry, fallback and stale credentials.
Relevant criterion: N1.4-AC04: Android Developers: Keep credentials consistent with credential providers covers the unknown-credential signal after server rejection.

Overview

Web

Native

Passkey Login: Error States

Acceptance criteria

References

​Error States During User Login

​General Login Errors

​Passkey Login Errors

​Acceptance criteria

​References

Error States During User Login

General Login Errors

Passkey Login Errors

Acceptance criteria

References