Passkey Intelligence - Corbado docs

The name Passkey Intelligence is taken from Corbado Connect. In this benchmark, it is used more broadly for the capability that decides whether to start a ceremony automatically, show a passkey action, wait or continue with fallback. The benchmark checks the resulting behavior, not a particular product or architecture.

Measurement

Passkey Intelligence starts with detailed journey and environment data. It should be possible to follow a user from the targeting decision through the passkey or fallback result and, after creation, to later passkey use.

Area	Record
Decision	Selected action and flow, reason, account group, nudge count and active cooldown
Journey	Eligibility check, offer shown, user action, ceremony start, success, cancellation, error, fallback start and fallback success
Credential	Creation, later use, credential ID, AAGUID or provider label, authenticator attachment, stored transports and backup state where returned
Environment	Web or native, browser or app version, operating system and version, device class and model where available, User-Agent or Client Hints, capability results and first-party environment history

Some environment values are unavailable or reduced on certain clients. Keep those values unknown instead of inventing precision.

Decision actions

Action	Meaning
Attempt	Start a passkey ceremony automatically.
Offer	Show a passkey action that the user can choose.
Defer	Do not show an optional passkey prompt in the current context.
Fallback	Continue with another login or recovery method.

Creation targeting

Before showing a broad post-login creation nudge, check that the current client can likely create a passkey that is usable from this environment without another device or security key. On the web, platform-authenticator availability and client capabilities are useful inputs, but they do not guarantee that a credential provider will accept the request. Cross-device or security-key creation can still be offered explicitly where the product supports it. It should not be treated as equivalent to a client-device creation route when estimating broad nudge acceptance. Passkey Intelligence should also recognize the situations covered by the more specific creation flows:

Situation	Target flow
A suitable client completes a normal non-passkey login	Web W2.2, Web W2.3, Native N2.1 or Native N2.2
A desktop login succeeds through a route intended for cross-device authentication	Web W2.4
An account with existing passkeys signs in from another environment	Web W2.6
A passkey attempt fails or is cancelled before successful fallback	Web W2.5 or Native N2.3

Creation nudges use one account-level history across post-login, signup and in-app entry points that target the same enrollment goal. Cancellation and explicit skip can have different cooldowns. Multiple nudges across separate eligible sessions are the default until the goal succeeds, while daily, monthly or yearly limits apply across every entry point. For identifier-first login, an account must have at least one accepted passkey before Passkey Intelligence selects an account-specific passkey route. That server record does not prove that the passkey is available from the current client.

Availability estimate	Action
A usable passkey is likely available from the current client	Attempt the selected passkey login automatically.
The account has a passkey, but current availability is uncertain	Offer an explicit passkey action.
The account has no passkey or the intended route is unlikely to work	Continue with fallback without opening a passkey ceremony expected to fail.

When availability is uncertain, an explicit passkey route can remain available through Offer. When the intended route is unlikely to work, start fallback login immediately.

Cross-device and security-key routes

When a cross-device route is likely, prepare the user before opening the system experience. Explain that a phone and QR code will be used. Name a device or provider only when account-specific history supports that wording and the information is still applicable. Transport and attachment data have different roles. During authentication, use the account’s credential descriptors, stored transports and supported request hints to guide client-device, hybrid or security-key routes. authenticatorAttachment is not an authentication request selector. During creation, authenticatorSelection.authenticatorAttachment can prefer platform or cross-platform, or it can be left unset so the client can choose. An unset value is not a third authenticator type.

Acceptance criteria

Benchmark as	Expected adoption impact
Supporting capability	High

The review checks the resulting decisions. It does not require a named decision engine, model or product.

ID	Level	Acceptance criterion	How to verify
E1-AC01	Core	Record the Passkey Intelligence decision and the complete result of the selected journey, including eligibility, offer or automatic attempt, ceremony result, fallback, creation and later passkey use. Record the client environment and capability results used for the decision.	Complete one passkey login, one fallback, one creation and a later login with the created passkey. Confirm that each journey can be reconstructed with its selected flow and reason, browser or app version, operating system and version, available device details, capability results and passkey outcome.
E1-AC02	Core	Saved passkey-availability information is tied to the correct account and environment, expires, and is updated when the related credentials or environment change.	Delete one of several credentials, return an unknown-credential result, switch accounts, sign out, forget the device and let the information expire. Confirm that stale information is not reused and data does not cross accounts or environments.
E1-AC03	Core	Show a broad post-login creation nudge only when the current client is expected to support passkey creation without requiring another device or security key. An explicitly selected cross-device or security-key creation route can remain available where supported.	Test a client with a usable platform or provider creation route, one that can create only through another device or security key, and one without passkey creation support. Confirm that only the first receives the broad nudge and that any optional external route requires an explicit user action.
E1-AC04	Core	When fresh authentication succeeds through a route deliberately intended for cross-device authentication and the current client is suitable for client-device creation, select the After hybrid login flow (W2.4). Use `authenticatorAttachment: "cross-platform"` as supporting evidence when returned, but describe hybrid use as likely unless a documented client or provider signal confirms it.	Compare a dedicated cross-device route with local passkey and security-key login, then repeat the cross-device route on a client that cannot create a client-device passkey. Only the successful dedicated route on the suitable client receives the W2.4 offer. Without a specific hybrid signal, the implementation does not claim that hybrid transport was proven.
E1-AC05	Core	When an account with existing passkeys completes fallback in an environment without prior successful passkey creation or use, select the second-device flow (W2.6) if that environment is suitable for creation.	Complete fallback from a new suitable environment and from a previously successful passkey environment. Confirm that only the new environment receives the W2.6 offer.
E1-AC06	Core	When a passkey cancellation or error can indicate that no usable passkey is available from the current environment, successful fallback can select W2.5 or N2.3 if the client is suitable for creation. The cancellation or error alone does not authorize creation.	Cancel or fail passkey login, then test unsuccessful and successful fallback on suitable and unsuitable clients. Confirm that the creation offer appears only after successful fallback on a suitable client.
E1-AC07	Core	Creation entry points targeting the same enrollment goal use one account-level nudge history. Cancellation and explicit skip can have different cooldowns. Multiple nudges across separate eligible sessions are the default until the goal succeeds, while daily, monthly or yearly limits apply across every entry point.	Trigger post-login, signup and in-app nudges for the same account. Confirm that cancellation and skip apply their configured cooldowns, reaching a frequency limit suppresses every entry point, and eligibility returns after the relevant period. Complete the enrollment goal and confirm that its nudges stop.
E1-AC08	Core	For identifier-first login, consider an account-specific passkey route only when the account has at least one accepted passkey. Classify current-client availability as likely, uncertain or unlikely without treating the server-side passkey record as proof that a credential is available here.	Test an account without passkeys and accounts with likely, uncertain and unlikely current-client availability. Confirm that the account without passkeys is not eligible for an account-specific passkey route and that every other case receives the correct availability classification.
E1-AC09	Quality	When cross-device authentication is the likely route, explain before the ceremony that the user will continue with a phone and QR code. Name a device or provider only when current account-specific history supports it.	Select a likely hybrid route with and without a reliable stored device or provider label. Confirm that both prepare the user for the phone and QR code, and that only the reliable case uses the more specific name.
E1-AC10	Quality	Do not start passkey login when the selected route is unlikely to reach a usable credential. Start fallback login immediately without another method-selection step.	Test accounts whose passkeys are unavailable or available only through an unsupported route. Confirm that no passkey ceremony opens and fallback login starts immediately.
E1-AC11	Quality	Use stored credential transports and supported WebAuthn hints to distinguish client-device, hybrid and security-key authentication routes. For creation, set `authenticatorAttachment` to `platform` or `cross-platform` only when that route is intended; otherwise leave it unset. Do not use `authenticatorAttachment` as an authentication request selector.	Test credentials recorded with `internal`, `hybrid` and supported security-key transports. Confirm that each explicit login route supplies the matching descriptors and hints. Then test platform-targeted, cross-platform-targeted and unrestricted creation and confirm that the intended authenticator choices are offered.

References

Relevant criteria: E1-AC01–AC02 and E1-AC08–AC10: Corbado: How to get high passkey adoption in login flows covers environment signals, availability estimates, automatic login and fallback.
Relevant criteria: E1-AC03–AC07: Corbado: How to get high passkey adoption in creation flows covers client-device creation, repeated enrollment nudges and prompt frequency.
Relevant criteria: E1-AC03–AC04: Create a passkey for passwordless logins covers platform-targeted creation and creation after cross-device authentication.
Relevant criteria: E1-AC01 and E1-AC08–AC11: Web Authentication Level 3 defines client capabilities, authenticator attachment, credential transports and request hints.
Relevant criterion: E1-AC01: MDN: User-Agent Client Hints API documents available and reduced browser and platform information.
Relevant criterion: E1-AC06: Corbado: Passkey Fallback & Recovery covers cancellation, passkey errors, fallback and recovery creation.

Reference implementation

Corbado Connect Passkey Intelligence is the implementation from which the name is taken. Other implementations can satisfy the same acceptance criteria without using its internal signals or architecture.

​Measurement

​Decision actions

​Creation targeting

​Login targeting

​Cross-device and security-key routes

​Acceptance criteria

​References

​Reference implementation