--- url: 'https://www.corbado.com/blog/conditional-create-passkeys' title: 'Conditional Create for Passkeys: Support & Effectiveness' description: 'Learn how Conditional Create upgrades passwords to passkeys on iOS, Android & Windows. Discover platform support, prerequisites & strategic value.' lang: 'en' author: 'Vincent Delitz' date: '2025-12-11T17:34:27.871Z' lastModified: '2026-03-27T07:01:55.786Z' keywords: 'conditional create, conditional create passkeys' category: 'Passkeys Strategy' --- # Conditional Create for Passkeys: Support & Effectiveness ## Platform Support Overview | **Platform** | **Web Browser** | **Native App** | **Password Manager** | | ----------------- | ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | -------------------- | | **iOS/iPadOS** | ✅ [Safari 18+](https://developer.apple.com/documentation/safari-release-notes/safari-18-release-notes) | ✅ [iOS 18+](https://developer.apple.com/videos/play/wwdc2024/10125/) | iCloud Keychain | | **macOS** | ✅ [Safari 18+](https://developer.apple.com/documentation/safari-release-notes/safari-18-release-notes) | ✅ [macOS 15+](https://developer.apple.com/videos/play/wwdc2024/10125/) | iCloud Keychain | | **Android** | ✅ [Chrome 142+](https://developer.chrome.com/blog/automatic-passkey-creation-android) | ⏳ [Credential Manager 1.6+](https://developer.android.com/jetpack/androidx/releases/credentials#1.6.0-alpha01) (beta) | GPM | | **Windows/Linux** | ✅ [Chrome 136+](https://developer.chrome.com/release-notes/136) | ❌ Not available | GPM | > Platform and version information is accurate as of **Dec 2025**. Support and minimum > versions may change; always verify against vendor documentation. > For technical implementation details, code examples and screenshots, see our > [automatic passkey upgrades](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades) article. > This article focuses on **effectiveness and strategic considerations** for Conditional > Create. ## Key Facts - **Platform effectiveness** for Conditional Create is highest on iOS due to iCloud Keychain dominance; Android is weakest because Samsung devices default to Samsung Pass over GPM. - **Autofill share** sets the ceiling: iOS autofill rates range from 20-50%, meaning Conditional Create only upgrades users who log in via password manager autofill. - **CC-only deployments** achieve approximately 20% passkey adoption; adding basic manual prompts doubles this to 40%; full best practices reaches 60-80% for large mobile-dominated consumer applications. - **Chrome's 5-minute authentication window** requires calling the Conditional Create API immediately after password login; delayed requests fail silently as the context expires. - **Browser support** requires Safari 18+ for Apple platforms, Chrome 136+ on Windows and Chrome 142+ on Android, as of December 2025. ## 1. Introduction [Passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices) is the critical first step toward [passwordless authentication](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/passkey-creation-best-practices) 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](https://www.corbado.com/blog/passkey-creation-best-practices) after a user logs in with a saved password, removing the need for an explicit prompt. > Try Conditional Create in this > [Conditional Create Demo](https://passkeys.eu/automatic-passkey-upgrade) **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? ## 2. What is Conditional Create? Conditional Create is an [automatic passkey creation](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades) mechanism that triggers after a successful password login. Instead of showing users a separate prompt asking them to [create a passkey](https://www.corbado.com/blog/passkey-creation-best-practices), the browser silently initiates [passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices) as a natural continuation of the login flow. ### 2.1 How it works After a user logs in with a password, the browser can automatically trigger a passkey creation dialog. The [password manager](https://www.corbado.com/blog/passkeys-vs-password-managers) 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](https://www.corbado.com/blog/ios-18-passkeys-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: ```mermaid flowchart TD A[User logs in with password] --> B{Password
autofilled?} B -- No --> X1[❌ No CC
Manual entry] B -- Yes --> C{Browser supports
conditionalCreate?} C -- No --> X2[❌ No CC
Unsupported browser] C -- Yes --> D{Within time
window?} D -- No --> X3[❌ No CC
Too late] D -- Yes --> E{Credential provider
supports CC?} E -- No --> X4[❌ No CC
Unsupported provider] E -- Yes --> F{User already
has passkey?} F -- Yes --> X5[❌ No CC
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](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades) article. ### 2.2 Prerequisites For Conditional Create to work, **all** of the following conditions must be true: | **Prerequisite** | **Description** | | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Device is passkey-ready** | The device must support passkey creation (biometrics enabled, authenticator configured) | | **No existing passkey exists** | The account must not already have a passkey for this RP in the active credential provider | | **Credential provider supports CC** | The credential provider must support Conditional Create; best integrations today are first-party providers (Apple Passwords, Google Password Manager), with some third-party providers adding support on specific platforms | | **User authentication context** | The password manager uses the recent authentication context (e.g., biometric unlock) as consent; behavior varies by platform | | **Browser support** | The browser must support the Conditional Create extension (Safari 18+, Chrome 136+/142+) | 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](https://www.corbado.com/blog/how-to-use-google-password-manager)). Third-party password managers are beginning to add Conditional Create support, for example: [Dashlane supports automatic passkey upgrades](https://www.dashlane.com/blog/dashlane-passkeys-ios-18) on [iOS 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades) and macOS 15. Support varies by manager and platform, so check your specific provider's documentation. ## 3. Technical Requirements 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. ### 3.1 Detection Not all browsers and password managers support Conditional Create, so feature detection is essential before attempting to use this API. The [`getClientCapabilities()`](https://www.corbado.com/blog/webauthn-client-capabilities) method provides a way to check if the current environment supports conditional passkey creation. Websites can detect Conditional Create support using the [`getClientCapabilities()`](https://www.corbado.com/blog/webauthn-client-capabilities) API: ```javascript (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. ### 3.2 Time Windows 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](https://www.corbado.com/blog/passkeys-vs-password-managers) 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**](https://issues.chromium.org/issues/377758786) ([implementation](https://chromium-review.googlesource.com/c/chromium/src/+/7018897)) - **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. ### 3.3 Registration semantics (UP/UV) 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](https://www.corbado.com/glossary/assertion), UV/UP semantics remain relevant.) ## 4. How effective is Conditional Create? 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](https://www.corbado.com/blog/passkeys-vs-password-managers), the percentage of users who use autofill sets the ceiling for potential impact. ### 4.1 Autofill Share Determines the Ceiling Autofill rates vary based on several factors: | **Factor** | **Impact on Autofill Rate** | | -------------------------- | -------------------------------------------------------------------------------------- | | **Website age** | Older websites have more users with saved passwords (accumulates over time) | | **Form implementation** | Proper autocomplete attributes help password managers save credentials | | **User base demographics** | Technical users may prefer third-party password managers (CC support varies by vendor) | | **Platform ecosystem** | Apple users more likely to use iCloud Keychain; Android is fragmented | 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. ### 4.2 Platform Differences The effectiveness of Conditional Create varies dramatically across platforms: #### 4.2.1 Conditional Create on iOS (Safari) High effectiveness due to [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain)'s dominance in the Apple ecosystem. Most [iOS](https://www.corbado.com/blog/webauthn-errors) users have [iCloud Keychain](https://www.corbado.com/glossary/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). #### 4.2.2 Conditional Create on Android (Chrome) Significantly lower effectiveness due to the fragmented [authenticator](https://www.corbado.com/glossary/authenticator) landscape. Key challenges include: - **Samsung Pass vs GPM**: [Samsung](https://www.corbado.com/blog/samsung-passkeys) devices (which hold a significant share of the [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) market) often default to [Samsung](https://www.corbado.com/blog/samsung-passkeys) Pass rather than [Google Password Manager](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/blog/samsung-passkeys) devices, Conditional Create becomes an opt-in feature rather than automatic The result is that [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) Conditional Create trigger rates are often lower than [iOS](https://www.corbado.com/blog/webauthn-errors), even when comparing devices that technically support the feature. #### 4.2.3 Conditional Create on Desktop Chrome Moderate effectiveness, depending on whether users have [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) enabled. **macOS Safari**: High potential effectiveness due to [Apple Passwords](https://www.corbado.com/blog/how-to-use-apple-passwords) integration, though desktop users may be more likely to use third-party password managers than mobile users. ## 5. Use Cases ### 5.1 Where Conditional Create helps 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](https://www.corbado.com/blog/passkey-adoption-business-case) metrics: | **Use Case** | **KPI Impacted** | **Effectiveness** | **Description** | | ---------------------------------------- | ----------------------------- | ----------------- | --------------------------------------------------------------------------------------------------- | | **Post-password-login upgrades** | Passkey creation rate | High | Primary use case. Users already authenticated and in security mindset. | | **Post-signup with autofilled password** | New user passkey adoption | Medium | Establishes passkey-first behavior from day one when password manager autofills generated password. | | **Catching hesitant users** | Conversion of reluctant users | Medium | Subtle approach converts users who dismiss explicit prompts without requiring active decision. | | **Upgrading across devices** | Multi-device passkey coverage | Medium | Automatically creates device-specific passkeys when users log in on new devices. | 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. ### 5.2 Where Conditional Create does not help It's equally important to understand where Conditional Create has no impact. The following scenarios fall outside the feature's scope: | **Scenario** | **Reason** | **Consideration** | | --------------------------------- | ---------------------------------- | ----------------------------------------------------------------------------------- | | **Passkey-native signups** | No password involved | CC bridges password→passkey; not applicable for passwordless flows | | **Manual password entry** | No autofill = no biometric consent | Users must use password manager autofill to trigger CC | | **Third-party password managers** | Support is evolving | Some managers (e.g., Dashlane) now support CC; check vendor docs for current status | Understanding these limitations helps set realistic expectations for Conditional Create's contribution to your overall [passkey adoption](https://www.corbado.com/blog/passkey-adoption-business-case) strategy. For users in these scenarios, traditional passkey creation best practices like post-login prompts remain essential. ## 6. Strategic Considerations Deciding whether to invest in Conditional Create depends on your current [passkey strategy](https://www.corbado.com/blog/passkeys-product-design-strategy) and user base characteristics. The following table helps assess whether CC will deliver significant value or marginal lift for your specific situation: | # | **Scenario** | **Impact** | **Description** | | --- | ----------------------------------------------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Early passkey rollout** | ⬆️ High | If you're just starting your passkey journey without optimized enrollment flows, CC provides an easy win. Minimal UX work required while capturing users who would otherwise need explicit prompting. | | 2 | **Defensive strategy (banking, high-security)** | ⬆️ High | For organizations concerned about where passkeys are created, CC provides higher confidence. Password autofill by a credential manager is a stronger signal of a personal device than manual entry (though not a guarantee), which can be valuable for banking and financial services. | | 3 | **Conservative approach** | ⬆️ High | Organizations wanting to increase adoption without aggressive prompting can rely on CC to gradually upgrade users. Reduces risk of user frustration from repeated prompts while still progressing adoption. | | 4 | **Catching the long tail** | ⬆️ High | Some users will never actively choose to create a passkey regardless of prompt design. CC captures these users passively over time without requiring any action on their part. | | 5 | **UX-sensitive / conversion-critical products** | ⬆️ High | CC removes post-login nudges (extra decision + extra step) by leveraging the fresh autofill authentication context (often biometric), so enrollment happens immediately in-session with minimal additional user action. | | 6 | **Already optimized creation flow** | ➡️ Low | If you're following passkey creation best practices with well-timed prompts, optimized wording, and a mix of manual prompts and automatic enrollment, CC will capture many users that would have been converted by your existing implementation anyway. | | 7 | **High existing adoption rate** | ➡️ Low | When most users already have passkeys, the pool eligible for CC shrinks. The feature helps users without passkeys, so high adoption means less opportunity for impact. | | 8 | **Technical/privacy-conscious user base** | ➡️ Low | If users predominantly use third-party password managers or have disabled browser autofill, CC will have minimal reach in your user base. | Regardless of where you fall in this matrix, passwords will remain as a fallback until [passkey adoption](https://www.corbado.com/blog/passkey-adoption-business-case) 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](https://www.corbado.com/glossary/passwordless-authentication) without requiring users to take explicit action. ## 7. Benchmarks & Common Outcomes When planning your rollout, it is helpful to understand how Conditional Create performs across platforms and how combining it with other strategies compounds adoption. > **Note:** This is a simplified view chosen as a representative device split. Actual > results will vary based on your specific user base and technical environment. > [Contact us](https://www.corbado.com/contact) for your personal consulting assessment on > enrollment/creation best practices. ### Platform Coverage for Conditional Create 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](https://www.corbado.com/glossary/authenticator) configuration). | **Platform** | **Browser Support** | **Actual Rate** | **Notes** | | :----------- | :------------------ | :-------------- | :--------------------------------------------------------- | | **iOS** | 🟢🟢🟢 | 🟢🟢 | Best coverage due to iCloud Keychain dominance | | **macOS** | 🟢🟢🟢 | 🟢 | Strong, but more third-party password manager usage | | **Windows** | 🟡 | 🟡 | Moderate; depends on GPM being active | | **Android** | 🟢🟢 | 🔴 | Poor actual rate; Samsung Pass default blocks GPM-based CC | The gap between browser support and actual rate reflects real-world constraints: autofill must be used (not manual password entry), and the default [authenticator](https://www.corbado.com/glossary/authenticator) must support Conditional Create (e.g., Samsung devices default to Samsung Pass, not GPM). ### Total Adoption by Strategy 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**. | **Scenario** | **Components** | **Adoption** | | :----------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------- | | **A) Conditional Create Only** | 🟢 Conditional Create
🔴 No Manual Prompts | **\~20%** | | **B) CC + Basic Prompt** | 🟢 Conditional Create
🟢 [Basic Manual Prompt](https://docs.corbado.com/passkey-ui-flows/web/passkey-creation/non-mfa) | **\~40%** | | **C) Full Best Practices** | 🟢 Conditional Create
🟢 [Optimized Nudges](https://docs.corbado.com/passkey-ui-flows/web/passkey-creation/non-mfa)
🟢 [Post-Hybrid Prompts](https://docs.corbado.com/passkey-ui-flows/web/passkey-creation/after-hybrid)
🟢 [After-Error Recovery](https://docs.corbado.com/passkey-ui-flows/web/passkey-creation/after-error)
🟢 [In-App Nudges](https://docs.corbado.com/passkey-ui-flows/native/passkey-creation/in-app-after-cta)
🟢 [Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) | **60-80%** | 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. ## 8. How Corbado Can Help Implementing all creation best practices including Conditional Create correctly with A/B testing, [gradual rollout](https://www.corbado.com/faq/gradual-rollout-support-passkey-adoption), 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. ### 8.1 SDKs & Components: Ship in Days, Not Months Corbado's headless SDKs implement all passkey creation best practices automatically, including Conditional Create: | **Platform** | **SDK** | **Conditional Create** | | ------------ | ------------------------------------------------------------- | ------------------------------------- | | Web | [@corbado/web-js](https://github.com/corbado/javascript) | ✅ Supported | | iOS Native | [corbado-ios](https://github.com/corbado/corbado-ios) | ✅ Supported | | Android | [corbado-android](https://github.com/corbado/corbado-android) | ✅ Supported (beta constraints apply) | 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. ### 8.2 Platform Capabilities: Visibility Without the Guesswork | **Capability** | **Description** | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Creation Flow Analytics** | View passkey creation rates globally or split by app (web/native), OS, and browser. See exactly where Conditional Create triggers vs. manual prompts. | | **Adoption Policy Configuration** | Define which flows are active (manual prompts, automatic enrollment, Conditional Create) via the Management Console. Edge cases handled automatically; CC expands as browsers add support. | | **Error Tracking & Telemetry** | Conditional Create is complex to implement and debug. Corbado SDKs include extensive client telemetry optimized for all edge cases: no silent failures. | | **Anomaly Detection** | Immediate alerts when creation rates drop in any flow. Catch regressions before they impact adoption KPIs. | 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. ## 9. Conclusion Conditional Create is a powerful addition to the [passkey enrollment](https://www.corbado.com/blog/passkey-creation-best-practices) 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](https://www.corbado.com/glossary/icloud-keychain)'s dominance and tight ecosystem integration. [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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. ## Frequently Asked Questions ### Why does Conditional Create work so much better on iOS than Android? iOS achieves the highest Conditional Create effectiveness because iCloud Keychain is enabled by default and tightly integrated with Safari. Android effectiveness is significantly lower: Samsung devices, which hold a large share of the Android market, default to Samsung Pass rather than Google Password Manager, making Conditional Create effectively opt-in rather than automatic on those devices. ### How should my server handle User Presence and User Verification flags during Conditional Create registration? In Chrome, Conditional Create registrations may have User Presence (UP) and User Verification (UV) set to false, and this is expected behavior. Servers must not use UP or UV flags to accept or reject passkey registrations created via Conditional Create; those semantics remain relevant only for login assertions, not enrollment. ### Which third-party password managers support Conditional Create today? The strongest Conditional Create integrations are through first-party native managers: Apple Passwords on Safari 18+ and iOS 18+, and Google Password Manager on Chrome 136+ for Windows and Chrome 142+ for Android. Some third-party managers are adding support; Dashlane, for example, supports automatic passkey upgrades on iOS 18 and macOS 15, though support varies by manager and platform. ### When does Conditional Create add high value versus marginal lift to a passkey strategy? Conditional Create delivers the highest impact for organizations early in their passkey journey, those wanting gradual adoption without aggressive prompting, security-conscious use cases like banking where password autofill signals personal device use, and products needing to capture users who dismiss explicit prompts. It delivers marginal lift when organizations already achieve high creation rates through optimized enrollment flows or when most users already have passkeys. ### What is the maximum passkey adoption rate achievable with Conditional Create alone, and how does combining it with other strategies change that? Conditional Create alone plateaus at approximately 20% passkey adoption, bounded by the autofill share ceiling of the platform. Adding a basic manual prompt doubles adoption to roughly 40%; implementing full best practices including optimized nudges, post-hybrid prompts, after-error recovery, in-app nudges and passkey intelligence reaches 60-80% for large mobile-dominated consumer applications.