Conditional create is a WebAuthn flow that can create a passkey after a recent password sign-in without a separate prompt. It supports background migration from passwords to passkeys, which makes rollout easier but also means policy must account for whatever credential manager the browser uses.
What Conditional Create Does in WebAuthn
Conditional create is a WebAuthn flow that lets a user create a passkey immediately after a recent password sign-in, without forcing a separate, interruptive enrollment step. It is especially useful during password-to-passkey migration because it lowers friction while preserving the existing login path.
Why Conditional Create Changes Rollout Strategy
The main value of conditional create is adoption. Instead of asking users to stop and enroll a passkey, the browser or credential manager can present creation at the moment the user is already authenticated. That makes migration easier to start, but it also means the rollout experience is shaped by whatever credential manager the browser chooses to surface, so policy and UX expectations need to account for that variability.
For teams moving from passwords to passkeys, the practical trade-off is simple: lower user friction usually means better uptake, but less explicit prompting can also make it easier to assume the wrong enrollment path is being used. The authentication state is still important, but the control point is the transition from password session to passkey creation, not a separate registration ceremony.
Browser Mediation and Credential Manager Behaviour
Conditional create is not just an application setting, it is an interaction between the relying party, WebAuthn, and the browser environment. The browser decides how the user is prompted, which credential manager is exposed, and how creation is presented after the recent sign-in. That makes the feature convenient, but also less deterministic than a hand-built enrollment flow.
Because the browser mediates the experience, organizations should treat it as part of the trust boundary. Differences in platform behaviour, password manager integration, and user profile state can change whether conditional create appears smoothly or not at all. The result is that deployment success depends as much on client behaviour as on server-side WebAuthn support.
Security Consequences of a Low-Friction Enrollment Path
Conditional create reduces abandonment during migration, but it also compresses the time between authentication and credential creation. If the session is already compromised, or if enrollment rules are too permissive, the feature can accelerate the creation of a passkey for the wrong person or device. The security model therefore depends on strong recent-authentication assurance and careful policy around when creation is allowed.
It also changes how teams think about recovery and account lifecycle. A newly created passkey may become the preferred login method very quickly, so organizations need clear rules for fallback credentials, session revocation, and post-enrollment visibility. The operational risk is not the WebAuthn ceremony itself, but the assumption that migration is harmless simply because it is seamless.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Conditional create changes how authenticators are created and introduced into the account lifecycle. |
| Recommendation — Set authenticating-session rules and enrollment policy so new passkeys are created only under approved conditions. | ||
| NIST SP 800-63 | Digital Identity Guidelines | WebAuthn passkey creation is part of phishing-resistant digital identity guidance and authenticator binding. |
| Recommendation — Align passkey rollout with WebAuthn assurance and enrollment guidance in the digital identity standard. | ||
| CIS Controls v8 | CIS-5 — Account Management | Conditional create affects how new credentials are provisioned during account lifecycle management. |
| Recommendation — Review account enrollment and lifecycle workflows so passkey creation is governed consistently across users. | ||
Practitioner Guidance
Why practitioners should care: Conditional create is most valuable when passkey adoption is being introduced to an existing password base, because it can materially improve conversion rates without redesigning the whole login experience. The feature works best when the recent sign-in event is trustworthy and the organization has decided which client-side credential manager behaviours it will accept.
What to watch for: The main governance question is whether the rollout policy clearly defines when passkey creation may occur, how browser variation is handled, and what happens if the user never completes enrollment. Teams should also verify that the creation path does not bypass any higher-assurance step they still require for sensitive accounts.
Related resources from NHI Mgmt Group
- Why do conditional approval flows create governance risk?
- Why do conditional fields create security risk in platform forms?
- Why do configuration drift and conditional access mistakes create so much risk in Microsoft 365 environments?
- Why does relying on only conditional rendering create risk in a role-based React app?