Passkey Creation: On 2nd Device

Passkey Creation on Device without Access to existing Passkeys

This flow applies when server state shows existing passkeys, the user completes an approved fallback and available history indicates that those passkeys could not have been created on the current device. They may still be available through a syncing provider, so the offer remains optional.

User enters identifier

User enters their identifier (email/username) on the login page.
System now knows which user account is attempting to log in.

System identifies passkeys created elsewhere

The server shows at least one registered passkey, but the existing passkeys were created before the current device was first seen.
A synced passkey may still be available through the current credential provider, so this history does not prove that passkey login will fail.
If the user cannot sign in with a passkey, the system proceeds to an approved fallback.

Complete approved fallback or recovery

The user completes an approved policy-compliant fallback or recovery for the same account.

Passkey append initiates on current device

After successful fallback, the system optionally offers to create an additional passkey through the current platform or credential provider.
The user can decline on a shared or temporary device without losing the authenticated session.

System passkey-creation sheet appears

The user authorizes creation with a platform-supported device-unlock method.

Passkey creation successful

The relying party verifies and adds the new passkey.
The credential becomes available according to the selected provider’s storage and sync behavior; the application does not guarantee device-only or multi-device storage.

Redirection to app dashboard

User is redirected to the app dashboard.

Acceptance criteria

Benchmark as	User reach
Conditional	Mid

WebAuthn cannot reliably list which account passkeys are usable in the current browser. Creation history can show that the existing passkeys were created before this device was first seen, but a synced passkey may still be available here. The offer therefore remains optional.

ID	Level	Acceptance criterion	How to verify
W2.6-AC01	Core	This secondary-device flow is considered only when the account already has at least one registered passkey, the current session completed through an allowed non-passkey fallback, and available history indicates that the existing passkeys could not have been created on this device, for example because they were registered before the device was first seen. An account with no passkeys is routed to first-passkey enrollment instead.	Test an account with no passkeys, one with a passkey created on the current device, and one whose passkeys were registered before the current device was first seen and therefore uses fallback. Confirm the three cases route to first-passkey enrollment, normal signed-in use, and this flow respectively.
W2.6-AC02	Core	Duplicate and concurrent registration attempts are harmless. `excludeCredentials` prevents avoidable duplicates, while `InvalidStateError` or other evidence that the provider already has the credential triggers a refresh or no-op instead of a user-facing failure.	Run concurrent registrations and a journey where the provider already contains a matching credential. Confirm that there is no duplicate server record, blocking error or repeated prompt.
W2.6-AC03	Core	The stored credential can complete a later passkey sign-in from the target environment.	Complete creation and perform a later sign-in from the target environment with the added credential.
W2.6-AC04	Core	Registration targets the current client’s platform or passkey provider, using client-device guidance and the compatible platform-authenticator setting where supported.	Inspect creation options across supported clients. Confirm the current-client creation route is promoted instead of a QR or security-key route.
W2.6-AC05	Quality	The offer identifies this as an additional passkey and explains the future same-environment benefit. It does not describe the operation as moving an existing passkey or guarantee that the credential is stored only on the physical device rather than a syncing provider.	Review rendered and localized copy on a personal and one-off device. Test users should distinguish additional coverage from first enrollment and understand that provider syncing may apply.
W2.6-AC06	Quality	Registration options contain every server-known account credential ID in `excludeCredentials`, and the server still rejects a duplicate returned by the client.	Generate options for an account with several known credentials and inspect `excludeCredentials`. Every known ID is present. Then return a duplicate and confirm that the server rejects it.

References

Relevant criteria: W2.6-AC01 and W2.6-AC05: How to get high passkey adoption in creation flows covers secondary-device eligibility and differentiated additional-credential messaging.
Relevant criteria: W2.6-AC01, W2.6-AC03 and W2.6-AC05: Payment provider passkeys: multi-device coverage covers first versus additional credentials, device-healing journeys, and later device coverage.
Relevant criteria: W2.6-AC02–AC04 and W2.6-AC06: Create a passkey for passwordless logins covers duplicate handling, response processing, later use and current-client targeting.
Relevant criteria: W2.6-AC03–AC05: Synced Passkey Deployment: Emerging Practices covers syncing semantics, later authentication, current-platform registration and additional-credential messaging.
Relevant criteria: W2.6-AC02–AC04 and W2.6-AC06: Server-side passkey registration covers duplicate prevention, response verification, multiple credentials and future authentication data.

Overview

Web

Native

Passkey Creation: On 2nd Device

Passkey Creation on Device without Access to existing Passkeys

Acceptance criteria

References

​Passkey Creation on Device without Access to existing Passkeys

​Acceptance criteria

​References

Passkey Creation on Device without Access to existing Passkeys

Acceptance criteria

References