Passkey Login: Identifier-First

This is an identifier-first flow where users enter their identifier (email, phone, or username) first. The app then automatically checks for an immediately available passkey accepted for that account. If none is available, the user continues with fallback. The app cannot enumerate which passkeys the current device or credential provider holds. A server record proves that the account has a passkey, but not that the passkey is available here.

Reference implementation: Corbado Passkey Intelligence is one way to identify passkey-enabled accounts and apply this flow. The benchmark checks the resulting login behavior, not the product.

Local and cross-device login: After the user enters their identifier, the server returns allowCredentials for that account. The app first starts an automatic request with preferImmediatelyAvailableCredentials, so the platform checks for an immediately available passkey without opening a QR-code or security-key flow. allowCredentials performs the account filtering. The immediate-credential preference does not.If no credential is available, the user continues with fallback. Products that support cross-device or security-key login can also show an explicit Use another device or security key action. This starts another account-scoped request without preferImmediatelyAvailableCredentials, allowing the operating system to offer its supported QR-code or security-key routes. Keep the stored transport hints in allowCredentials, and test the optional route separately on every supported platform.

iOS
Android

User enters identifier

User types their identifier (email, phone, or username) into the login textfield in the native app.
System now knows which user account is attempting to log in.

App starts an immediate passkey request

The server returns allowCredentials containing the active passkeys accepted for the entered account.
On a supported client, the app starts the account-scoped request automatically with preferImmediatelyAvailableCredentials.
The user does not need to find and press a separate passkey button.

Passkey login or fallback continues

If an immediately available credential is offered, the user authorizes it and the server verifies the assertion.
If none is available, the request ends without starting a QR-code or security-key journey and the user continues with fallback.

Optional cross-device or security-key login

Products that support this route show an explicit Use another device or security key action.
The action starts another account-scoped request without preferImmediatelyAvailableCredentials and includes the stored transport hints.
The operating system can then offer the supported QR-code or security-key route.

Acceptance criteria

Benchmark as	User reach
Strategy	High

The strategy applies where the product collects an identifier before authentication. The automatic route checks for an immediately available account passkey. Cross-device and security-key login are optional explicit routes.

ID	Level	Acceptance criterion	How to verify
N1.3-AC01	Core	After identifier submission, the app automatically starts an account-scoped request that prefers immediately available credentials. For a known account, `allowCredentials` contains every active passkey accepted for that account.	Test an account with multiple active passkeys. Confirm that the server returns every accepted credential in `allowCredentials` and that the request starts without a separate passkey action.
N1.3-AC02	Core	If no immediately available credential is returned, the automatic request ends without starting a QR-code or security-key journey and the user can continue with fallback.	Test with no credential available from the current device or provider, including an account whose only passkey requires another device or security key. Confirm that the automatic request does not open either route and that fallback remains available.
N1.3-AC03	Core	Explicitly choose whether identifier-first login prioritizes account-enumeration protection or more helpful account-specific guidance. Enumeration-protected flows keep app-controlled text, status, response shape, timing and routing aligned across active, disabled, unknown and passkey-enabled identifiers. Guidance-focused flows may reveal selected differences, but protect repeated lookup with bot protection, rate limits or an equivalent control.	Record the chosen approach and test every account state. For enumeration protection, confirm that app-controlled behavior does not reveal the state. For guidance-focused login, confirm that only the intended differences appear and repeated automated lookups activate the configured protection.
N1.3-AC04	Quality	If the product supports cross-device or security-key login, an explicit Use another device or security key action starts a new account-scoped request without `preferImmediatelyAvailableCredentials`. The request retains the stored transport hints so the operating system can offer the supported route.	Test with an account whose matching credential is available only through hybrid transport and with one available through a supported security key. Confirm that the automatic request ends first, the explicit action starts one new request, and the operating system offers the applicable route on each supported platform.

References

Relevant criteria: N1.3-AC01–AC02: Apple: Prefer immediately available credentials, Android: GetCredentialRequest and Corbado: Passkey Fallback & Recovery cover immediate-credential requests and direct fallback.
Relevant criterion: N1.3-AC03: Web Authentication Level 3 privacy considerations supports minimizing account and credential-state disclosure.
Relevant criterion: N1.3-AC04: Web Authentication Level 3 defines credential transport hints used by the client when selecting an authenticator route.

Overview

Web

Native

Passkey Login: Identifier-First

Acceptance criteria

References

​Identifier-First Login

​Acceptance criteria

​References

Identifier-First Login

Acceptance criteria

References