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.
Why This Matters for Security Teams
Passkey login is designed to reduce phishing and credential replay, but device switching creates a lifecycle problem that many teams underestimate. If a passkey is tied to a lost, replaced, or repaired device without a clear recovery path, users either get locked out or are pushed into weaker fallback methods. That is where attackers look for the gap: account recovery, stale device bindings, and poorly logged re-enrollment.
The core issue is not the passkey itself, but how identity assurance survives device turnover. Security teams should treat device changes as a normal state transition with explicit revocation, re-binding, and audit requirements. That is consistent with the NIST Cybersecurity Framework 2.0 emphasis on identity lifecycle control and recovery governance. NHIMG research on the Ultimate Guide to NHIs shows how often organisations miss lifecycle controls in adjacent identity domains, which is useful context here even though passkeys are human identities.
In practice, many security teams encounter account takeover or support abuse only after a device replacement has already become a recovery event rather than an authentication event.
How It Works in Practice
The safest model is to separate three things: authenticating the user, binding the passkey to a device, and revoking old bindings. When a user switches devices, the new device should not inherit trust automatically. Instead, the user should complete a recovery or re-enrollment flow that is narrow, logged, and bound to an approved assurance step such as an existing session, verified email plus step-up authentication, a help-desk workflow, or an organisational identity provider.
Security teams should define the following controls:
- Record the old device as pending revocation as soon as the replacement is initiated.
- Require explicit user confirmation before enrolling the new passkey on the new device.
- Use strong identity proofing for recovery, especially if the old device is unavailable.
- Log who approved the change, what assurance was used, and when the old binding was removed.
- Invalidate any stale sessions, remembered devices, and backup factors that could bypass the new binding.
This approach aligns with modern identity guidance from NIST Cybersecurity Framework 2.0 because the control objective is not simply login success, but continuous identity assurance across lifecycle events. It also reflects the broader NHIMG position in the Ultimate Guide to NHIs: identity value depends on offboarding discipline as much as enrollment discipline, even when the identity is human rather than non-human.
Teams should also decide whether synced passkeys are allowed across devices, because cloud-synced credentials reduce friction but can complicate revocation semantics. Current guidance suggests treating sync as a policy decision, not a default assumption, and tying it to device posture, user risk, and supportability. These controls tend to break down when recovery is handled ad hoc through the service desk because the revocation step is often delayed or skipped entirely.
Common Variations and Edge Cases
Tighter recovery controls often increase support burden, requiring organisations to balance phishing resistance against user lockout risk. That tradeoff becomes sharper when users lose a phone, upgrade devices frequently, or operate in regulated environments where help-desk identity proofing must be documented.
There is no universal standard for passkey device migration yet. Some environments prefer synced passkeys for usability, while others require device-bound credentials and explicit re-enrollment on every replacement. Best practice is evolving, but the principle is stable: do not let a new device silently inherit the trust of the old one.
Edge cases include shared devices, employee departures, and mobile device management wipes. In those cases, teams should revoke the old binding immediately and check for active sessions, recovery codes, and secondary authenticators that remain usable. If the organisation uses step-up authentication for high-risk actions, that policy should be re-evaluated after device switch events, not only at initial login.
For high-assurance programs, device change should be treated as a lifecycle checkpoint with explicit owner approval, audit retention, and post-event monitoring. That is especially important when the device change coincides with travel, SIM swaps, or support escalation, because those are common moments for social engineering to target the recovery path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-7 | Passkey device switching depends on controlled identity verification and recovery. |
| NIST SP 800-63 | AAL2 | Passkeys and recovery flows must preserve the intended authentication assurance level. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Device-bound credential lifecycle and revocation mirror NHI offboarding risks. |
| OWASP Agentic AI Top 10 | LLM-04 | Runtime trust decisions and narrow recovery paths reflect contextual authorization principles. |
| NIST AI RMF | Lifecycle governance and accountability apply to identity transitions and recovery abuse. |
Assign ownership for authentication recovery and monitor device-change outcomes as managed risk.
