> ## 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 Creation: Automatic Upgrade (conditional create)

> Conditional passkey creation in a native app after sign-in with an autofilled password, including eligibility, platform APIs and server requirements.

## 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](/passkey-ui-flows/web/passkey-creation/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.

<Info>
  **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.
</Info>

<Steps>
  <Step title="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.
  </Step>

  <Step title="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()`.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

### What your server must tolerate

<Warning>
  **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.
</Warning>

### Platform differences worth planning for

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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](/passkey-ui-flows/native/passkey-creation/non-mfa) available.
  </Accordion>
</AccordionGroup>

<Tip>
  Because the passkey is created without the user choosing to create it, keep [passkey management](/passkey-ui-flows/native/passkey-management) easy to find. A user who is surprised by the system notification should be able to see and remove the credential immediately.
</Tip>

## 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](https://www.w3.org/TR/webauthn-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](https://pages.nist.gov/800-63-4/sp800-63b/events/#binding-an-additional-authenticator) 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](https://developer.apple.com/videos/play/wwdc2024/10125/) 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](https://developer.android.com/identity/passkeys/create-passkeys) 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](https://developer.chrome.com/docs/identity/webauthn-conditional-create) documents conditional-create timing, silent behavior, verification caveats and retry behavior; it is implementation guidance aligned with the WebAuthn specification.

### Further reading

* [Conditional create](https://developer.chrome.com/docs/identity/webauthn-conditional-create) and [automatic passkey creation on Android](https://developer.chrome.com/blog/automatic-passkey-creation-android), Chrome for Developers
* [Streamline sign-in with passkey upgrades and credential managers](https://developer.apple.com/videos/play/wwdc2024/10125/), WWDC24 session 10125
* [Create passkeys](https://developer.android.com/identity/passkeys/create-passkeys), Android Developers
* [CredentialProviderEventsService](https://developer.android.com/reference/androidx/credentials/providerevents/service/CredentialProviderEventsService), Android Developers
* [Conditional create explained](https://www.corbado.com/blog/conditional-create-passkeys), Corbado blog