Conditional Create for Passkeys: Support & Effectiveness

Looking for a developer-focused passkey reference? Download our Passkeys Cheat Sheet (incl. WebAuthn ceremonies, objects & Conditional UI). Trusted by dev teams at Ally, Stanford CS & more.

Get Cheat Sheet

Passkey creation is the critical first step toward passwordless authentication. Without users creating passkeys, organizations cannot realize the security and cost benefits that passkeys promise. We covered the fundamentals in our passkey creation best practices article, where we explored post-login prompts, account settings pages, and other enrollment strategies.

Today, we focus on a specific mechanism: Conditional Create (also known as automatic passkey upgrades). This feature allows browsers to automatically create a passkey after a user logs in with a saved password, removing the need for an explicit prompt.

The central question: How effective is Conditional Create across platforms and when should you implement it?

We will also answer:

• What conditions must be met for Conditional Create to work?
• Does Conditional Create benefit all passkey strategies equally?
• When does it add significant value versus marginal lift?

Conditional Create is an automatic passkey creation mechanism that triggers after a successful password login. Instead of showing users a separate prompt asking them to create a passkey, the browser silently initiates passkey creation as a natural continuation of the login flow.

After a user logs in with a password, the browser can automatically trigger a passkey creation dialog. The password manager uses the recent authentication context (e.g. biometric unlock during autofill) as implicit consent to create the passkey. This removes the friction of an extra click and makes passkey creation feel like a seamless part of the login experience. Users retain control over this behavior, all major browsers and operating systems allow disabling automatic passkey upgrades in their settings.

The following flowchart illustrates when Conditional Create succeeds versus when it fails silently. Each gate must pass for a passkey to be created automatically:

flowchart TD
    A[User logs in with password] --> B{Password<br/>autofilled?}
    B -- No --> X1[❌ No CC<br/>Manual entry]
    B -- Yes --> C{Browser supports<br/>conditionalCreate?}
    C -- No --> X2[❌ No CC<br/>Unsupported browser]
    C -- Yes --> D{Within time<br/>window?}
    D -- No --> X3[❌ No CC<br/>Too late]
    D -- Yes --> E{Password manager<br/>supports CC?}
    E -- No --> X4[❌ No CC<br/>3rd party PM]
    E -- Yes --> F{User already<br/>has passkey?}
    F -- Yes --> X5[❌ No CC<br/>Already enrolled]
    F -- No --> G[✅ Passkey Created]

The technical implementation uses mediation: "conditional" in the WebAuthn navigator.credentials.create() call. For a deep dive into the technical details, see our automatic passkey upgrades article.

For Conditional Create to work, all of the following conditions must be true:

The key constraint is that the password manager must support Conditional Create. Currently, the best integrations are available through first-party native password managers (Apple Passwords, Google Password Manager). Third-party password managers are beginning to add Conditional Create support, for example: Dashlane supports automatic passkey upgrades on iOS 18 and macOS 15. Support varies by manager and platform, so check your specific provider's documentation.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Before implementing Conditional Create, developers need to understand how to detect browser support and when to trigger the creation request. This section covers the essential technical requirements for a successful implementation.

Not all browsers and password managers support Conditional Create, so feature detection is essential before attempting to use this API. The getClientCapabilities() method provides a way to check if the current environment supports conditional passkey creation.

Websites can detect Conditional Create support using the getClientCapabilities() API:

if (window.PublicKeyCredential && PublicKeyCredential.getClientCapabilities) {
  const capabilities = await PublicKeyCredential.getClientCapabilities();
  if (capabilities.conditionalCreate) {
    // Conditional Create is supported
  }
}

This capability check is crucial for implementing graceful degradation. If Conditional Create is not supported, your application should fall back to traditional passkey creation prompts to ensure all users have the opportunity to create passkeys.

Both Apple and Google enforce timing constraints for Conditional Create to ensure the password authentication context is still fresh. These time windows balance security with user convenience, because the password manager needs confidence that the user just authenticated with a password before automatically creating a passkey.

• Chrome: Requires the password to have been used within the last 5 minutes (implementation)
• Apple: Our tests show a comparable time window; immediate execution after password login is recommended

In practice, this means you should call the conditional create API immediately after successful password authentication. Delaying the request, for example, waiting until the user navigates to another page, may cause the request to fail silently as the time window expires. For the best results, trigger Conditional Create in the same user session where the password was used.

The effectiveness of Conditional Create is fundamentally constrained by the autofill share of your platform. Since Conditional Create only triggers when a password is autofilled by a password manager, the percentage of users who use autofill sets the ceiling for potential impact.

Autofill rates vary based on several factors:

Depending on the age of the website, autofill shares can range from 20-50% on iOS. Newer websites or those with complex login flows will see lower rates, as saved passwords accumulate over time.

The effectiveness of Conditional Create varies dramatically across platforms:

High effectiveness due to iCloud Keychain's dominance in the Apple ecosystem. Most iOS users have iCloud Keychain enabled by default and Apple's tight integration between Safari and the Passwords app creates a seamless experience. Conditional Create trigger rates can reach 20-50% of eligible logins, depending on website age.

Significantly lower effectiveness due to the fragmented authenticator landscape. Key challenges include:

• Samsung Pass vs GPM: Samsung devices (which hold a significant share of the Android market) often default to Samsung Pass rather than Google Password Manager
• GPM must be "preferred authenticator": Conditional Create only works when GPM is explicitly set as the preferred service for autofill and passkeys (in the device settings)
• Effective opt-in on Samsung: Since GPM is not the default on Samsung devices, Conditional Create becomes an opt-in feature rather than automatic

The result is that Android Conditional Create trigger rates are often lower than iOS, even when comparing devices that technically support the feature.

Moderate effectiveness, depending on whether users have Google Password Manager enabled.

macOS Safari: High potential effectiveness due to Apple Passwords integration, though desktop users may be more likely to use third-party password managers than mobile users.

Become part of our Passkeys Community for updates & support.

Join

Conditional Create is most effective in scenarios where users are already interacting with password-based authentication. The following table summarizes the key use cases and their impact on passkey adoption metrics:

The post-password-login upgrade stands out as the highest-impact use case because it targets the largest user segment: existing users who already have saved passwords. Every time these users log in, there's an opportunity to silently upgrade them to passkeys. The other use cases provide valuable supplementary coverage but affect smaller user segments or occur less frequently.

It's equally important to understand where Conditional Create has no impact. The following scenarios fall outside the feature's scope:

Understanding these limitations helps set realistic expectations for Conditional Create's contribution to your overall passkey adoption strategy. For users in these scenarios, traditional passkey creation best practices like post-login prompts remain essential.

Deciding whether to invest in Conditional Create depends on your current passkey strategy and user base characteristics. The following table helps assess whether CC will deliver significant value or marginal lift for your specific situation:

Regardless of where you fall in this matrix, passwords will remain as a fallback until passkey adoption reaches high levels. Rather than viewing this as a limitation, Conditional Create turns every password login into a potential passkey upgrade, thereby gradually shifting your user base toward passwordless authentication without requiring users to take explicit action.

Conditional Create is a powerful addition to the passkey enrollment toolkit, but its effectiveness depends heavily on context. To answer our central question:

How effective is Conditional Create across platforms?

Effectiveness varies significantly by platform. Apple platforms (iOS, macOS) see the highest impact due to iCloud Keychain's dominance and tight ecosystem integration. Android effectiveness is lower due to the fragmented authenticator landscape, with Samsung devices (often defaulting to Samsung Pass) being a limiting factor. Desktop Chrome provides solid support where Google Password Manager is active. Autofill share (which can range from 20-50% depending on website age) sets the ceiling for Conditional Create's potential impact.

Key takeaways:

• Conditional Create is a low-friction upgrade path, not a standalone strategy
• It works best when combined with existing passkey creation best practices
• Strongest impact on platforms with high first-party password manager usage (Apple Passwords, GPM) and for organizations early in their passkey adoption journey
• Marginal impact for organizations already achieving high passkey creation rates through optimized enrollment flows
• Provides higher confidence for security-conscious use cases (banking) since password autofill indicates a personal, non-shared device

For organizations considering Conditional Create, the decision should factor in your current passkey adoption rate, your user base's platform distribution, and your tolerance for prompting users explicitly. When implemented thoughtfully alongside other enrollment strategies, Conditional Create can meaningfully accelerate your path to passwordless authentication.