> ## Documentation Index > Fetch the complete documentation index at: https://docs.corbado.com/llms.txt > Use this file to discover all available pages before exploring further. # Passkey Intelligence > How Passkey Intelligence uses client, credential and journey signals to target passkey login, creation, cross-device authentication and fallback. 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](/passkey-ui-flows/web/passkey-creation/non-mfa), [Web W2.3](/passkey-ui-flows/web/passkey-creation/mfa), [Native N2.1](/passkey-ui-flows/native/passkey-creation/non-mfa) or [Native N2.2](/passkey-ui-flows/native/passkey-creation/mfa) | | A desktop login succeeds through a route intended for cross-device authentication | [Web W2.4](/passkey-ui-flows/web/passkey-creation/after-hybrid) | | An account with existing passkeys signs in from another environment | [Web W2.6](/passkey-ui-flows/web/passkey-creation/on-2nd-device) | | A passkey attempt fails or is cancelled before successful fallback | [Web W2.5](/passkey-ui-flows/web/passkey-creation/after-error) or [Native N2.3](/passkey-ui-flows/native/passkey-creation/after-error) | 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. ## Login targeting 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)](/passkey-ui-flows/web/passkey-creation/after-hybrid). 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)](/passkey-ui-flows/web/passkey-creation/on-2nd-device) 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](/passkey-ui-flows/web/passkey-creation/after-error) or [N2.3](/passkey-ui-flows/native/passkey-creation/after-error) 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](https://www.corbado.com/blog/passkey-login-best-practices) covers environment signals, availability estimates, automatic login and fallback. * **Relevant criteria:** **E1-AC03–AC07:** [Corbado: How to get high passkey adoption in creation flows](https://www.corbado.com/blog/passkey-creation-best-practices) covers client-device creation, repeated enrollment nudges and prompt frequency. * **Relevant criteria:** **E1-AC03–AC04:** [Create a passkey for passwordless logins](https://web.dev/articles/passkey-registration) covers platform-targeted creation and creation after cross-device authentication. * **Relevant criteria:** **E1-AC01 and E1-AC08–AC11:** [Web Authentication Level 3](https://www.w3.org/TR/webauthn-3/) defines client capabilities, authenticator attachment, credential transports and request hints. * **Relevant criterion:** **E1-AC01:** [MDN: User-Agent Client Hints API](https://developer.mozilla.org/en-US/docs/Web/API/User-Agent_Client_Hints_API) documents available and reduced browser and platform information. * **Relevant criterion:** **E1-AC06:** [Corbado: Passkey Fallback & Recovery](https://www.corbado.com/blog/passkey-fallback-recovery) covers cancellation, passkey errors, fallback and recovery creation. ## Reference implementation [Corbado Connect Passkey Intelligence](/corbado-connect/features/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.