Passkey Creation: Automatic Upgrade (conditional create)

Automatic Passkey Creation in Native Apps (Conditional Create)

When a user signs in to your app with a password supplied by their credential manager, the OS can create a passkey for that account without showing any UI at all. There is no sheet, no biometric prompt and no interruption to your app. The credential manager notifies the user afterwards. This is the same conditional create mechanism as the web automatic upgrade, available to native apps on both platforms. It requires no additional user interaction for eligible users, but provider, platform and password-autofill requirements make it an enhancement rather than a complete enrollment strategy.

Support (August 2026): iOS 18+, iPadOS 18+, macOS 15+ and visionOS 2+ via ASAuthorizationPlatformPublicKeyCredentialProvider. Android relying parties use androidx.credentials 1.6.0 (stable since 8 April 2026); Google Password Manager support requires Google Play services 25.13 or newer. On both platforms, the user’s preferred credential manager can participate when it supports conditional registration. Android providers receive these requests through CredentialProviderEventsService, whose provider-facing library is separately versioned and may not yet be implemented by every provider.

User signs in with an autofilled password

The user’s credential manager fills a saved username and password for your app, and the sign-in succeeds.
The user completes every additional factor required by the account’s active sign-in policy. Password-only progress on an MFA account is not enough to bind a credential.
This is the hard precondition. Sign-ins that do not use a stored password (magic links, SMS or email OTP, and federated or SSO sign-in) do not qualify.

Your app requests a conditional registration

Promptly after the complete configured sign-in succeeds, the app issues a registration request marked as conditional while the credential provider’s recent autofill context can still apply.
On Apple platforms, request ASAuthorizationPlatformPublicKeyCredentialRegistrationRequest.RequestStyle.conditional.
On Android, set isConditional = true on CreatePublicKeyCredentialRequest and send it through CredentialManager.createCredential().

The credential manager decides, silently

The provider checks its own conditions, such as recent matching-password autofill, passkey readiness and whether it already holds a matching passkey. The relying party cannot infer account-wide credential absence from this result.
If an eligibility condition fails, the request returns an expected no-op error and no UI is shown to the user. Nothing went wrong; a passkey simply was not created this time.

Passkey created, user informed by the system

On success the passkey is created with no prompt and no user interaction.
The credential manager, not your app, notifies the user that a passkey now exists. Do not add your own confirmation screen on top of it.

What your server must tolerate

The registration response carries UP and UV as false. No user interaction takes place, so there is no user presence or user verification to assert. A registration verifier configured to reject UV=0 will fail every automatic upgrade. This is the most common integration bug on this flow, and it fails silently from the user’s point of view.

Platform differences worth planning for

Duplicate prevention differs by platform

Supply server-known credential IDs through the platform’s exclusion mechanism on Android and Apple where supported, and retain server-side credential uniqueness. Exclusion helps the selected provider avoid duplicates it recognizes, but the relying party must not suppress the conditional request merely because another provider may hold a credential. Issue the request after an eligible sign-in and let the active credential manager evaluate its own context.

Android uses the preferred credential provider

Credential Manager forwards a conditional create request to the user’s preferred provider when the provider supports the flow. Google Password Manager requires Google Play services 25.13 or newer; older versions may fail with CreateCredentialUnsupportedException. Third-party providers can receive conditional requests through CredentialProviderEventsService, but support is provider-dependent, so keep the explicit creation fallback described below.

Apple platforms support third-party credential managers

Credential managers implement performWithoutUserInteractionIfPossible(passkeyRegistration:) and declare SupportsConditionalPasskeyRegistration in their extension capabilities. A provider is not permitted to show UI while fulfilling the request.

Expected failures should not interrupt the user

Do not show a user-facing error when conditional creation is simply ineligible, but do not swallow every exception. On Android, handle CreateCredentialNoCreateOptionException as the explicit no-op outcome. Preserve a CreatePublicKeyCredentialDomException as a normalized ambiguous or technical result unless the request context and current platform contract support a more specific stable interpretation; do not assume that every InvalidStateError, NotAllowedError or AbortError means ordinary ineligibility. Record unsupported, provider-configuration, malformed-request and unexpected failures in telemetry. On Apple platforms, suppress UI for documented eligibility or cancellation outcomes while logging association, entitlement, request-construction and unexpected failures. Retry an expected no-op on a later policy-compliant password sign-in.

Users can switch it off

Google Password Manager offers a setting that disables automatic passkey creation and syncs it across the user’s devices. Plan for adoption that never reaches 100%, and keep an explicit creation path such as the post-login nudge available.

Because the passkey is created without the user choosing to create it, keep passkey management easy to find. A user who is surprised by the system notification should be able to see and remove the credential immediately.

Acceptance criteria

Benchmark as	User reach
Enhancement	Mid

Automatic upgrade removes the explicit enrollment step for eligible users. Password autofill, platform and credential-provider requirements limit where it applies. It complements rather than replaces explicit creation paths.

ID	Level	Acceptance criterion	How to verify
N2.6-AC01	Core	Issue no conditional registration request until the account’s complete sign-in policy, including required MFA, has succeeded.	Test password-only progress, failed or expired second-factor, completed MFA and lower-assurance recovery. Only the completed policy-compliant sign-in can proceed to registration.
N2.6-AC02	Core	Mark the registration request with the platform’s conditional or automatic-registration mode.	Inspect the native request for every supported target. A request without the conditional mode fails this criterion even if a provider happens to create a credential without visible UI.
N2.6-AC03	Core	Generate creation options for the account that completed sign-in; do not reuse an earlier account context merely because the provider still recognizes it.	Switch from one authenticated account to another while the provider retains both, then inspect the conditional creation options. The account and opaque user-handle context matches only the account that completed the current sign-in.
N2.6-AC04	Core	Send server-known credential IDs through every duplicate-prevention input exposed by the target platform.	Inspect conditional requests for an account with known credentials on every supported target. Each available exclusion input contains the expected credential IDs.
N2.6-AC05	Core	Send one conditional request promptly after complete sign-in and let the platform and credential provider decide whether the recent password-autofill context qualifies. Expected ineligibility or no-create results remain silent, and another automatic attempt waits for a later qualifying sign-in. A separate manual creation nudge may still be shown.	Compare matching autofill, manual entry and mismatched stored-account sign-in. Return an expected no-create result and keep using the current session. No user-facing error or automatic retry appears, and a later qualifying sign-in can issue one new request.
N2.6-AC06	Core	Reject the registration response if logout, account switching or a superseding login makes its transaction context stale.	Delay the response while performing each context change. No stale response changes any account’s credential list.

References

Relevant criteria: N2.6-AC03–AC04 and N2.6-AC06: Web Authentication: An API for accessing Public Key Credentials: Level 3 defines account and relying-party binding, duplicate-prevention inputs and current ceremony context.
Relevant criteria: N2.6-AC01: NIST SP 800-63B authenticator binding supports requiring the configured server-session assurance before adding an authenticator. WebAuthn itself does not generally require prior authentication.
Relevant criteria: N2.6-AC02 and N2.6-AC05–AC06: Streamline sign-in with passkey upgrades and credential managers describes matching autofill context, conditional native requests, silent no-op behavior, later retry and the relationship to explicit enrollment on Apple platforms.
Relevant criteria: N2.6-AC02–AC06: Create a passkey on Android defines conditional native creation, request data, duplicate controls, response handling, provider notifications and failures on Android.
Relevant criteria: N2.6-AC02 and N2.6-AC05–AC06: Help users adopt passkeys more seamlessly documents conditional-create timing, silent behavior, verification caveats and retry behavior; it is implementation guidance aligned with the WebAuthn specification.

Overview

Web

Native

Passkey Creation: Automatic Upgrade (conditional create)

Automatic Passkey Creation in Native Apps (Conditional Create)

What your server must tolerate

Platform differences worth planning for

Acceptance criteria

References

Further reading

​Automatic Passkey Creation in Native Apps (Conditional Create)

​What your server must tolerate

​Platform differences worth planning for

​Acceptance criteria

​References

​Further reading

Automatic Passkey Creation in Native Apps (Conditional Create)

What your server must tolerate

Platform differences worth planning for

Acceptance criteria

References

Further reading