# Passkey Adoption Planning: A Staged Migration Guide

> Plan a staged passkey rollout around account boundaries, enrollment, device coverage, recovery, credential management, measurable release gates, and rollback.

Canonical URL: https://www.devobs.io/articles/passkeys-adoption-planning/
By: Finn Larson
Published: 2026-10-10T01:13:34.303Z
Updated: 2026-10-10T01:13:34.303Z
Section: Identity

Adopt passkeys in stages: settle account and domain boundaries, offer optional enrollment to a limited cohort, test repeat sign-in and recovery, then expand only when predefined reliability and security gates are met. Treat password retirement as a separate decision—not an automatic consequence of enabling passkeys.

WebAuthn describes two related ceremonies: registration creates a public-key credential scoped to a relying party and associated with a user's account; authentication uses that credential to authenticate the user. That distinction should shape the rollout: successful registration is one milestone, not proof that the entire account-access lifecycle works. [WebAuthn specification](https://www.w3.org/TR/webauthn-3/)

## Set account and domain boundaries before enrollment

Start with an architecture inventory. Record the following decisions before inviting users to create credentials:

- **Account association:** Which account receives the credential? How will existing accounts, new registrations, account linking, and duplicate-account handling work?
- **Domains and environments:** Which domains serve registration and sign-in? What relying-party identifier and expected origins will each environment use?
- **Tenant boundaries:** Which tenants share an identity system, and which require isolation?
- **Application surfaces:** Which journeys run in browsers, native applications, or embedded browser contexts?
- **Federation and sessions:** Which service authenticates the user, which establishes application sessions, and which communicates authentication results to downstream applications?

These are implementation decisions, not merely UI settings. WebAuthn credentials are scoped to a relying party, and web.dev's integration guide specifies that the authentication `rpId` must match the `rp.id` used when creating the credential. Do not assume a domain migration will preserve credential usability without reviewing the applicable rules and testing the intended design. [WebAuthn specification](https://www.w3.org/TR/webauthn-3/) · [web.dev integration guide](https://web.dev/articles/passkey-form-autofill)

Make the resulting architecture document a release prerequisite. Include planned domain changes rather than designing only for today's hostname.

## Design enrollment and sign-in as separate journeys

For an initial pilot, offer enrollment after an existing user has authenticated through an approved path. Define the authentication requirements for adding a credential; do not leave that decision implicit in whichever session happens to be present.

Keep new-account registration as a separate test case. Verify that a completed registration associates the credential with the intended account and that cancellation leaves a clear, recoverable state. Confirm enrollment only after the backend has accepted it, then test a subsequent sign-in rather than stopping at the success screen.

For a mixed password-and-passkey population, conditional UI is one integration option. web.dev describes presenting passkeys through a sign-in form's autofill interface while retaining the password flow. Its guide also demonstrates feature detection for conditional mediation. Treat this as an integration pattern, not a guarantee of support across every browser and device combination. [web.dev integration guide](https://web.dev/articles/passkey-form-autofill)

Keep enrollment optional during the pilot, provide an understandable cancellation path, and make alternative sign-in choices visible. Test the wording as well as the protocol behavior.

## Build a device matrix around complete user journeys

Define the supported population explicitly. Use browser, operating-system, device, and credential-provider combinations as test dimensions rather than relying on a single “supports passkeys” checkbox.

For each supported combination, test:

1. Enrollment for both existing and new accounts.
2. Sign-in after signing out and after the application session expires.
3. Cancellation, timeout, retry, and return to another approved sign-in method.
4. Adding and removing credentials.
5. Use from another device, where the proposed ecosystem supports that journey.
6. Loss of access to the original device or credential provider.
7. Shared-device use, keyboard navigation, and relevant assistive technologies.

Distinguish a journey that is intentionally unsupported from one that fails unexpectedly. Give each supported journey an expected outcome, a fallback policy, and an owner. Keep registration and repeat-authentication results separate so that enrollment success cannot conceal later access failures.

## Make recovery and credential management release gates

Decide how users regain control before expanding enrollment. For every lifecycle action, specify the required authentication, the available evidence of account control, and the resulting account state.

NIST's authentication guidance defines technical requirements for three authentication assurance levels and addresses authenticator issuance, maintenance, and invalidation after loss or theft. Its stated focus is authentication to government information systems. Assess which requirements apply to your deployment rather than assigning an assurance level from the word “passwordless.” [NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html)

A practical lifecycle review should cover:

- **Adding another credential:** What authentication is required, and how is the account owner informed?
- **Removing a credential:** What happens if it is the account's last approved sign-in method?
- **Lost-device recovery:** Which recovery routes are permitted, and which sensitive actions remain restricted afterward?
- **Suspected compromise:** How are credential removal, session termination, and account investigation coordinated?
- **Support intervention:** What evidence may support staff accept, and which actions require escalation?

Evaluate fallback and recovery independently of the normal passkey flow. Document whether each route meets the application's security requirements rather than treating it as an exception to them.

Also make user-verification policy explicit. web.dev notes that a request using `userVerification: "preferred"` can succeed without user verification and advises checking the user-verified flag in the returned authenticator data. Where your policy requires verification, enforce that requirement in backend validation rather than inferring it from the presence of a passkey or a displayed prompt. [web.dev integration guide](https://web.dev/articles/passkey-form-autofill)

## Check implementation-specific migration constraints

Product support is the beginning of an implementation review, not its conclusion.

For example, Ory Network's Kratos documentation describes self-service login and registration, account recovery, profile management, and support for custom user interfaces. Evaluate how those capabilities fit your account model and recovery policy. [Ory Kratos introduction](https://www.ory.com/docs/network/kratos/intro)

Ory's passkey guide documents passwordless sign-in with Kratos and lists configuration choices worth including in a migration review:

- **Authenticator attachment:** Omitting `authenticator_selection.attachment` allows either platform or cross-platform authenticators.
- **Discoverable credentials:** The documented default for `authenticator_selection.resident_key` is `required`.
- **User verification:** The documented default for `authenticator_selection.user_verification` is `preferred`.

The guide warns that changing advanced settings can prevent existing users from signing in with previously registered passkeys. These are documented settings, not evidence that a particular deployment or credential population will survive a configuration change. [Ory passkey guide](https://www.ory.com/docs/kratos/passwordless/passkeys)

For an existing deployment, inventory registered credentials and test credential continuity before changing authentication strategies or authenticator-selection settings. Confirm behavior for the exact version and deployment you intend to run, and retain an approved access path for affected users during migration.

## Measure repeat use, fallback, and recovery—not enrollment alone

Choose metric definitions and release thresholds before the pilot. The following are proposed measurements, not industry benchmarks:

| Measure | Suggested definition |
| --- | --- |
| Enrollment completion | Server-accepted registrations divided by enrollment starts |
| Passkey sign-in completion | Server-accepted passkey sign-ins divided by passkey attempts, using a documented start event |
| Repeat use | Among enrolled accounts that initiate sign-in during the observation window, the share completing at least one passkey sign-in |
| Fallback usage | Journeys that move from an attempted passkey sign-in to another method |
| Recovery outcomes | Completed, abandoned, rejected, and escalated recovery journeys |
| Support burden | Authentication-related contacts normalized by active accounts or sign-in journeys |

Define an “attempt” carefully. web.dev's conditional UI pattern lets users choose a passkey or a password from form autofill. A password choice alone should therefore not count as a failed passkey sign-in. Choose an observable start event, document any measurement gaps, and keep sign-in form views separate from passkey attempts. [web.dev integration guide](https://web.dev/articles/passkey-form-autofill)

Separate cancellation, timeout, validation failure, and service errors. Report journey-level outcomes separately from individual retries. Segment results by platform and rollout cohort, and compare them with the existing sign-in baseline. Collect only the telemetry needed for these decisions; avoid logging authentication payloads or unnecessary personal data.

## Expand through explicit gates and rehearse rollback

Use a staged release plan with distinct exit criteria:

1. **Preparation:** Agree on domain configuration, account association, lifecycle policy, instrumentation, and supported journeys.
2. **Limited pilot:** Offer optional enrollment to a small cohort. Require successful repeat sign-in and recovery exercises before expanding.
3. **Broader availability:** Expand by tested platform or cohort. Investigate fallback and support patterns before increasing enrollment prompts.
4. **Default changes:** Change sign-in presentation only after the relevant journeys meet the predefined targets.
5. **Password retirement:** Make a separate decision based on coverage, repeat use, recovery readiness, and security requirements.

For each gate, record the metric, threshold, observation window, and decision owner. Do not substitute a high enrollment count for evidence that returning users can access their accounts.

Design separate controls for enrollment prompts, new enrollment, and sign-in presentation where the implementation permits. Rehearse what each control does to users who already have credentials.

Rollback should preserve account access, not simply restore the old page. Before allowing passkey-only accounts, demonstrate how those users will sign in during a UI rollback or service incident. Do not make credential deletion part of a routine rollback, and do not introduce an unapproved weaker fallback to recover availability.

The adoption milestone to optimize for is dependable repeat access: users can enroll, return, manage their credentials, and recover under the intended security policy. Use that lifecycle—not enrollment totals alone—to decide when the migration is ready to advance.

## Source references

- <https://www.w3.org/TR/webauthn-3/>
- <https://web.dev/articles/passkey-form-autofill>
- <https://pages.nist.gov/800-63-4/sp800-63b.html>
- <https://www.ory.com/docs/network/kratos/intro>
- <https://www.ory.com/docs/kratos/passwordless/passkeys>