Conditional Create for Passkeys: Support & Effectiveness

Looking for a dev-focused passkey reference? Download our Passkeys Cheat Sheet. 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, and 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{Credential provider<br/>supports CC?}
    E -- No --> X4[❌ No CC<br/>Unsupported provider]
    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:

(async function detectConditionalCreateSupport() {
    if (!window.PublicKeyCredential || !PublicKeyCredential.getClientCapabilities) {
        return false;
    }
 
    const capabilities = await PublicKeyCredential.getClientCapabilities();
    return Boolean(capabilities.conditionalCreate);
})();

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.

When Conditional Create can’t run (time window expired, unsupported provider, user disabled the feature, already enrolled), browsers typically fail silently. Implement it as a best-effort enhancement: handle expected errors (e.g. NotAllowedError, AbortError, InvalidStateError) without user-visible error UI, and fall back to your normal passkey prompts where appropriate.

Conditional Create is designed to minimize user friction, which impacts what signals are available during passkey registration. In Chrome, conditional create registrations may have User Presence (UP) and User Verification (UV) set to false. This is expected behavior; servers should not use UP/UV to accept or reject passkey registrations. (For login assertions, UV/UP semantics remain relevant.)

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. In practice, if your iOS autofill share is in the 20-50% range, Conditional Create can upgrade a meaningful fraction of those autofilled password logins (bounded by that autofill ceiling).

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.

When planning your rollout, it is helpful to understand how Conditional Create performs across platforms and how combining it with other strategies compounds adoption.

The effectiveness of Conditional Create varies significantly by platform. The table below shows the gap between theoretical browser support (WebAuthn Client Capabilities) and actual working rates (accounting for autofill share and default authenticator configuration).

The gap between browser support and actual rate reflects real-world constraints: autofill must be used (not manual password entry), and the default authenticator must support Conditional Create (e.g., Samsung devices default to Samsung Pass, not GPM).

Given these platform constraints, how do different implementation strategies impact overall passkey adoption? The following visualization shows how each additional layer compounds adoption—from ~20% with CC alone to 60-80% with full best practices:

The table below provides detailed breakdowns based on data from large, mobile-dominated consumer applications.

The progression from A to C illustrates how each additional layer compounds adoption. Scenario A represents a "glass ceiling" where Conditional Create silently upgrades users who rely on password managers, but adoption plateaus at the autofill rate (~20%). Adding a basic manual prompt in Scenario B doubles your reach to ~40%, with roughly half of passkeys created via silent upgrades and half via explicit prompts. Scenario C achieves 60-80% adoption through intelligent, adjusting, and well-timed prompting that takes user behavior into account across all devices—capturing users who initially skip, recovering from errors, and leveraging every touchpoint (post-hybrid logins, in-app nudges, etc.) to maximize conversions.

Implementing all creation best practices including Conditional Create correctly with A/B testing, gradual rollout, and edge case handling across all platforms takes months of product, engineering and testing work. Corbado provides observability and adoption intelligence on top of your existing identity stack, so you can go live in days instead of months while keeping authentication fully in-house.

Corbado's headless SDKs implement all passkey creation best practices automatically, including Conditional Create:

All SDKs handle edge cases automatically: browser quirks, timing windows, device-specific issues. Device-level kill switches let you deactivate problematic OS/browser combinations instantly if issues arise, preventing crash loops without requiring app store updates.

Whether you're building passkey support yourself or looking for a managed solution, Corbado helps you understand what's happening, prove business impact, and maximize adoption.

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 is a stronger signal of a personal device than manual entry (though not a guarantee)

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.