Passkey Login: Identifier-First

This is an identifier-first flow where users enter their identifier (email, phone, or username) first. A readiness or routing layer then estimates whether to offer local passkey authentication, cross-device authentication or policy-compliant fallback. The decision is probabilistic: server records and client capability cannot enumerate provider-held credentials or guarantee assertion success.

Reference implementation: Corbado Passkey Intelligence is one implementation of the readiness layer. The benchmark checks the selected routes, not this product or its internal signals.

User enters identifier

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

Readiness layer selects an authentication route

The routing layer evaluates server-known account state, current client capability, policy and scoped first-party outcomes.
It selects among:
- Platform authentication: When an account-scoped credential is reasonably likely to be available through the current provider
- Cross-device authentication: When an explicitly supported remote route is plausible
- Fallback: When a viable passkey route is not sufficiently likely
No route selection is presented as proof of credential presence or absence.

System passkey sheet appears

If the declared routing policy selects a passkey route, the system starts the account-scoped request.
User verifies their identity using their screen lock (e.g., fingerprint, PIN, or face recognition).

Access granted

User is seamlessly logged in and redirected to the dashboard.

Acceptance criteria

Benchmark as	User reach
Strategy	High

Identifier-first has a High user reach only when automatic passkey prompts are selective and the fallback remains predictable.

ID	Level	Acceptance criterion	How to verify
W1.3-AC01	Core	After explicit identifier submission, the implementation starts a passkey route only when account, credential and client evidence predicts that route is usable.	Run a matrix covering a known local credential, a remote-only credential, no credential, an unsupported client and an unknown account; confirm the selected route matches the available evidence.
W1.3-AC02	Core	The authentication request does not exclude any active account credential that the current client could reach.	Inspect request options for accounts with multiple active credentials and providers; confirm every active, reachable credential descriptor is present.
W1.3-AC03	Core	Explicitly choose whether identifier-first login prioritizes account-enumeration protection or more helpful account-specific guidance. Enumeration-protected flows keep application-controlled text, status, response shape, timing and routing aligned across active, disabled, unknown and passkey-enabled identifiers. Guidance-focused flows may intentionally reveal selected differences, but must protect the lookup against automated probing with bot protection, rate limits or an equivalent control.	Record the chosen approach and test every account state. For enumeration protection, confirm that no application-controlled difference reveals the state. For guidance-focused login, confirm that only the intended differences appear and that repeated automated lookups activate the configured abuse protection.
W1.3-AC04	Quality	Include stored transport hints for each account-scoped credential descriptor when those hints are available.	Register credentials with different recorded transports and inspect the generated request options. Each descriptor should retain its stored transport values.

References

Relevant criteria: W1.3-AC02 and W1.3-AC04: W3C Web Authentication Level 3 recommends including all account credentials and available transports for an identified user.
Relevant criteria: W1.3-AC03: W3C Web Authentication Level 3 documents username-enumeration and credential-ID privacy risks and distinguishes mitigable lookup responses from residual credential-routing signals.
Relevant criteria: W1.3-AC01 and W1.3-AC03: Corbado: How to get high passkey adoption in login flows supports selective identifier-first routing and limiting repeated account probing. Its adoption figures provide context, not acceptance thresholds.

Overview

Web

Native

Passkey Login: Identifier-First

Acceptance criteria

References

​Identifier-First Login

​Acceptance criteria

​References

Identifier-First Login

Acceptance criteria

References