Passkey Creation: Automatic Password to Passkey Upgrade (conditional create)

Support (August 2026): Chrome 136+ on desktop and Chrome 142+ on Android with Google Password Manager, Safari 18+ / macOS 15+ and all browsers on iOS 18+ with Apple Passwords. Firefox does not support it and third-party password manager coverage is still uneven. It requires a recent password-manager fill. The active credential provider decides whether its internal conditions are met, while the relying party supplies known credential IDs to prevent avoidable duplicates.

Users logging in via a browser follow a standard login flow enriched by automatic passkey creation via Conditional Create after successfully using a password manager to autofill their password. Passkey Intelligence is one implementation of the eligibility logic. Automatic creation is attempted only when the required conditions are met.

macOS
Windows
iOS

The blue background indicates product-specific steps, such as a verification code. Passkey creation occurs within the same application flow.

User logs in with their password, which is then autofilled by e.g. Apple Passwords / Google Password Manager.

Credential manager authorizes password autofill where required

The active credential manager may require a supported device-unlock method before filling the saved password. The exact modality and whether a prompt appears are platform-dependent.

Complete configured sign-in verification

The user completes any additional verification required by the relying party’s sign-in policy. This step is omitted when no additional factor is required.

Automatic passkey creation

After the configured sign-in has completed, the application promptly requests Conditional Create (navigator.credentials.create({ mediation: 'conditional' })). The credential provider decides whether the request is eligible and can silently decline it.
If the provider returns a credential and the server verifies and stores it, creation succeeds and provider or operating-system feedback may appear.
If the provider silently declines or returns no credential, sign-in continues without a success state; the normal explicit enrollment route remains available.

Redirection to app dashboard

User is redirected to the app dashboard.

Acceptance criteria

Benchmark as	User reach
Enhancement	Mid

Conditional Create is a progressive automatic upgrade, not a complete enrollment strategy. Its whole-audience reach is limited by client and credential-provider support, recent use of a saved password, and user settings. It runs only after all authentication required by the relying party’s sign-in policy has completed; a second factor is not universally required.

ID	Level	Acceptance criterion	How to verify
W2.1-AC01	Core	The implementation checks WebAuthn support and confirms `getClientCapabilities().conditionalCreate` before requesting a conditional registration. Browser version or user-agent matching is not the sole capability signal.	Test a supporting client, a client without `getClientCapabilities()`, and a client that does not report `conditionalCreate`. Only the supporting client may start the request, and all three complete sign-in normally.
W2.1-AC02	Core	Conditional Create is requested immediately after a successful password sign-in for the same authenticated account and only after the relying party’s configured sign-in requirements have completed.	Test saved-password autofill, manual password entry, unsuccessful sign-in, federated or link-based sign-in, and accounts with and without policy-required MFA. Only an eligible recent saved-password use can result in automatic creation, and no path bypasses configured verification.
W2.1-AC03	Core	Any outstanding WebAuthn operation is aborted before at most one `navigator.credentials.create()` request with `mediation: "conditional"` is started for the completed sign-in.	Begin Conditional UI authentication, finish the password route, and inspect WebAuthn calls. Confirm the earlier request is aborted and no duplicate conditional registration request is issued.
W2.1-AC04	Core	Registration options are generated for the authenticated account and include a fresh server challenge, the expected RP ID, a stable non-PII user handle, appropriate credential parameters, and known credential IDs in `excludeCredentials`.	Generate options twice for each of two authenticated accounts and inspect them before client use. Challenges differ, account and user-handle values match the active session, and every server-known account credential appears in `excludeCredentials`.
W2.1-AC05	Core	A conditional registration accepted without user presence or user verification where the platform permits it does not weaken verification rules for later authentication ceremonies.	Complete the conditional registration cases, then perform an assertion that requires user verification. The later assertion must still enforce that requirement.
W2.1-AC06	Core	The stored credential can authenticate the same account later.	Complete an automatic upgrade and use the credential on a later sign-in to the same account.
W2.1-AC07	Quality	Expected no-op errors such as `NotAllowedError`, `InvalidStateError`, and `AbortError` produce no application error and do not interrupt the signed-in journey.	Force each expected exception. Confirm the user reaches the signed-in destination without false success, a blocking error or a prompt loop.
W2.1-AC08	Quality	If the client creates a credential but server registration fails, the implementation records the mismatch for credential-state reconciliation.	Reject the response after client creation. Confirm the mismatch remains diagnosable and retryable.

References

Relevant criteria: W2.1-AC02 and W2.1-AC07–AC08: Conditional Create for passkeys covers provider eligibility, expected silent results and client/server reconciliation.
Relevant criteria: W2.1-AC01–AC03 and W2.1-AC05–AC08: Help users adopt passkeys more seamlessly covers capability detection, immediate post-password timing, aborting an outstanding conditional request, conditional UP and UV semantics, graceful exceptions and server-registration failure.
Relevant criteria: W2.1-AC02 and W2.1-AC05–AC08: Streamline sign-in with passkey upgrades and credential managers covers account matching, provider-controlled eligibility, progressive-enhancement behavior, non-interrupting failure and reconciliation after server failure.
Relevant criteria: W2.1-AC01 and W2.1-AC03–AC06: Web Authentication: Level 3 covers Conditional Create capability and mediation semantics, request cancellation, registration options, conditional UP and UV handling, and later authentication with the stored credential.
Relevant criteria: W2.1-AC04, W2.1-AC06 and W2.1-AC08: Server-side passkey registration covers account-bound options, duplicate prevention, future authentication data, and rejected registration handling.

Overview

Web

Native

Passkey Creation: Automatic Password to Passkey Upgrade (conditional create)

Acceptance criteria

References

​Automatic Passkey Creation after Login (Conditional Create)

​Acceptance criteria

​References

Automatic Passkey Creation after Login (Conditional Create)

Acceptance criteria

References