Cross-device passkeys expose the real governance gap in CIAM

At a glance

What this is: This is a cross-device passkey implementation guide that shows how passwordless login can move between laptop and phone while preserving user verification.

Why it matters: It matters because CIAM teams need authentication flows that work across devices without weakening identity proofing, recovery, or account recovery governance.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Descope's guide to cross-device passkey authentication

Context

Cross-device passkeys are an authentication and account recovery problem, not just a passwordless convenience feature. The core challenge is preserving user identity assurance when the same person signs in from a laptop, then a phone, then back again, without forcing unsafe fallback paths.

For CIAM teams, the hard part is not creating a passkey once. It is making device change, verification, and recovery consistent across the identity lifecycle so that authentication remains resilient when a credential is tied to one device and then needs to work on another.

This is a typical consumer and workforce-facing authentication pattern, which means the control design has to be repeatable rather than manual or one-off.

Key questions

Q: How should security teams handle passkey login when users switch devices?

A: They should treat device switching as part of the authentication lifecycle, not as an exception. The user needs a controlled recovery or re-enrollment path, clear logging, and revocation of stale bindings when a device is replaced. The goal is to preserve phishing resistance while keeping the recovery path narrow and auditable.

Q: Why do passkeys not eliminate the need for recovery controls?

A: Passkeys reduce phishing and password reuse, but they do not remove account recovery. If password resets, SMS OTP, or support overrides remain weak, attackers will target those paths instead. Mature IAM programmes treat recovery as part of the authentication system and apply the same assurance discipline to fallback routes as to sign-in itself.

Q: What do security teams get wrong about passwordless authentication?

A: The most common mistake is treating passwordless as a user-experience upgrade instead of an identity control change. Teams often focus on the login screen and ignore recovery, lifecycle governance, and fallback authentication, which is where many of the real risks emerge.

Q: How do you know whether a passkey programme is actually working?

A: A passkey programme is working when password use, phishing success, and reset-related support demand all decline without increasing account recovery incidents or access exceptions. Track login success, fallback usage, recovery events, and the proportion of applications still outside the passkey policy boundary.

Technical breakdown

Cross-device passkey binding and device registration

Passkeys are public key credentials tied to a user account and a specific authenticator, such as a phone, laptop, or security key. Cross-device flows add a registration step that can re-establish trust on a new device after the user proves prior account ownership, often through email OTP or another recovery signal. The authentication system is not just checking possession of a key. It is deciding whether a new device may become part of the user’s trusted credential set without breaking the assurance model.

Practical implication: treat device enrollment as a governed identity event, not a simple login success.

Why cross-device login still needs fallback verification

A passkey prompt alone cannot solve first-time login on a new device because the authenticator may not yet exist there. In practice, the system needs a separate proofing step before it can safely issue or update the new passkey binding. That is why email verification, OTP, or another recovery path often sits alongside the passkey flow. The security issue is not the presence of fallback. It is whether fallback is bounded, auditable, and used only when the original authenticator cannot satisfy the request.

Practical implication: constrain fallback methods so they do not become a permanent weaker path around passkey assurance.

Cross-device passkeys and identity lifecycle controls

Cross-device support changes the lifecycle of an authenticator because the user may have multiple passkey bindings across devices over time. That creates governance questions around enrollment, revocation, replacement, and recovery. If a phone is lost or a laptop is replaced, the organisation needs to know which bindings remain valid and how the account’s trusted state is updated. Without that lifecycle view, passkey deployment can become a set of disconnected device events rather than a controlled identity posture.

Practical implication: map passkey enrolment and revocation into your identity lifecycle and access review processes.

NHI Mgmt Group analysis

Cross-device passkeys expose an authentication continuity problem, not a pure login problem. The real governance issue is whether identity assurance survives device changes without forcing users into inconsistent fallback paths. When teams treat passkey setup as a single event instead of a lifecycle, they create gaps between first enrollment, replacement device access, and recovery. Practitioners should frame this as authentication continuity across the user lifecycle, not as a one-time MFA replacement exercise.

Device-bound credentials need lifecycle governance because recovery becomes part of the attack surface. If a passkey cannot follow a user across devices in a controlled way, organisations will rely on email OTP, manual support flows, or ad hoc exceptions. Those are not inherently wrong, but they must be scoped and monitored because they can become the weakest step in the chain. The useful concept here is cross-device authentication drift: the point at which the original assurance model no longer matches how users actually move between endpoints.

Cross-device passkeys strengthen the case for passwordless, but they do not remove identity proofing responsibilities. The challenge shifts from password handling to trust transfer between authenticators, devices, and recovery mechanisms. That matters for CIAM programmes, because the same policy logic must support enrolment, replacement, and revocation without creating brittle exceptions. Practitioners should design for device mobility as a standard state, not an edge case.

Authentication teams should think about passkeys the way identity teams think about other governed credentials. A passkey is still an identity artefact with ownership, lifecycle, and recovery implications. Once it is treated that way, cross-device support becomes a governance design question rather than an SDK configuration detail. The organisations that get this right will have a cleaner path to phishing-resistant authentication without sacrificing operational control.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• For a lifecycle lens on credential governance, see the Ultimate Guide to NHIs for offboarding, rotation, and revocation patterns.

What this signals

Cross-device passkeys are a reminder that authentication hardening only works when device change, recovery, and revocation are designed together. For CIAM programmes, the main risk is not passkey adoption itself, but inconsistent handling of the moments when a user moves from one authenticator to another.

Cross-device authentication drift: this is the point where the original trust decision no longer matches the user’s current device state. Teams should watch for support tickets, fallback OTP volume, and stale passkey bindings as early signs that the authentication model is leaking into exception handling.

As passwordless adoption matures, identity teams should expect more pressure to align passkey governance with lifecycle controls already used elsewhere in IAM. That means device enrollment reviews, recovery policy checks, and revocation workflows need to become part of the operating model, not just the implementation checklist.

For practitioners

• Map passkey enrollment to identity lifecycle states Define how a user moves from first registration to device replacement, revocation, and recovery. Make sure each state change is logged and reviewable so passkey bindings are not treated as invisible background events.
• Restrict fallback verification to bounded recovery paths Use email OTP or similar proofing only when a new device cannot present an existing passkey. Track when fallback is used, why it was used, and whether it remains necessary after the new device is enrolled.
• Test device migration as a standard authentication scenario Run cross-device sign-in tests for laptop-to-phone, phone-to-laptop, and lost-device recovery. Include support handoff and account recovery in the test plan so the flow reflects real user behaviour, not just happy-path login.
• Align passkey governance with recertification and offboarding When a user leaves, changes roles, or replaces a device, ensure old passkey bindings are revoked and new ones are reviewed. Connect those steps to your existing identity review process rather than leaving them to local application logic.

Key takeaways

• Cross-device passkeys improve usability, but they also create a lifecycle governance problem around device replacement and recovery.
• The weak point is usually not the passkey itself, but the fallback and revocation paths that surround it.
• Teams that want phishing-resistant authentication need to govern passkey enrollment, migration, and offboarding as a single control set.

Key terms

• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• Cross-Device Authentication: An authentication pattern that begins on one device and completes on another, often with a trusted phone approving a session started elsewhere. It reduces password exposure on shared or keyboard-limited devices and is especially useful for retail checkout and kiosk scenarios.
• Identity Lifecycle Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.

What's in the full article

Descope's full post covers the implementation detail this analysis intentionally leaves for the source:

• React SDK setup steps, including project ID wiring and Flow ID configuration for cross-device passkeys
• The exact passkey-cross-device flow logic that checks whether a user already exists before updating bindings
• Phone-to-laptop and laptop-to-phone test paths, including QR-based cross-device login
• Integration examples for teams using SAML or OIDC providers alongside passkey flows

👉 Descope's full tutorial shows the login flow, OTP verification steps, and phone-to-laptop passkey handoff.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.