Join our Newsletter — 33% off our NHI Course
Home› Glossary› NHI Lifecycle Management› Device Migration
NHI Lifecycle Management

Device Migration

← Back to Glossary
By NHI Mgmt Group Updated October 6, 2026 Domain: NHI Lifecycle Management

The governed process of moving an authenticated identity from one trusted device to another. For passkeys, this includes re-verification, credential update, and reassociation so the user can continue signing in without creating duplicate identity states.

What Device Migration Actually Means

Device migration is not just “moving an account” from one phone or laptop to another. It is the governed transfer of a trusted sign-in state, so the new device becomes accepted without leaving behind duplicate, stale, or ambiguous access records.

For modern authentication flows, that usually means the original device trust is replaced or re-established under fresh assurance, rather than copied verbatim. That distinction matters because a migrated device must inherit access safely, not simply receive a duplicate credential set.

How Migration Differs From Backup, Sync, and Recovery

Backup and sync preserve data; device migration preserves the ability to authenticate. Recovery restores access after loss or reset; migration intentionally shifts the active trust relationship to a replacement device. Those goals overlap, but they are not the same control problem.

In passkey-based environments, migration often includes re-verification, credential update, and reassociation so the user can continue signing in while the older device state is retired. That helps prevent two devices from both appearing valid when only one should represent the current trusted endpoint.

Why Device Migration Needs Careful Identity State Handling

The main security concern is lifecycle consistency. If the old device remains trusted after migration, organisations can end up with duplicate authenticators, orphaned trust, or unclear ownership of the active login path.

Good migration design also limits friction at the moment users replace hardware. If the process is too strict, people create workarounds; if it is too loose, attackers may use a transfer flow to bind their own device to an existing identity.

Common Failure Modes in Device Migration

Device migration usually fails when the trust transition is incomplete. A stale device may still authenticate, a replacement device may not inherit the right assurance level, or the migration process may not retire the previous registration cleanly.

  • Duplicate device registrations can leave multiple valid entry points for one identity.
  • Weak re-verification can let an impostor bind a new device during a transfer event.
  • Poor inventory or lifecycle tracking can make it hard to know which device is currently authoritative.

Risk and Threat Considerations

Device migration creates a concentrated trust moment: the system is deciding whether a new device should inherit access that already proved valuable to a user or attacker. If that decision is weakly governed, migration can become a shortcut for account takeover, persistence, or recovery abuse.

Failure mechanism: An attacker intercepts or mimics the migration process, then reassociates the identity to a device they control, or exploits an uncleared old device state to keep both paths active.

Impact: The result can be unauthorized sign-in, confused account ownership, duplicate authenticators, and delayed detection of compromise, especially where the migration flow is treated as routine rather than high assurance.

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, OWASP ASVS, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementDevice migration depends on changing, replacing, and retiring authenticators safely.
Recommendation — Retire old authenticators and issue new ones under controlled lifecycle rules.
NIST SP 800-63Digital Identity GuidelinesThe term centers on re-verification and authenticator binding during device transition.
Recommendation — Use phishing-resistant re-verification before binding a new device to an existing identity.
OWASP ASVSV6 — AuthenticationMigration affects how a user is re-authenticated and how trust is reassigned to a new device.
Recommendation — Require strong re-authentication before accepting a migrated device.
CIS Controls v8CIS-5 — Account ManagementDevice migration is an account lifecycle event that should update or disable prior access paths.
Recommendation — Remove or disable obsolete device access paths as part of account lifecycle management.
NIST CSF 2.0PR.AA-05 — Identity Management, Authentication, and Access ControlMigration changes which device is authorised to authenticate for the identity.
Recommendation — Update identity and access records so only the current trusted device remains authorised.

Practitioner Guidance

Why practitioners should care: Migration is a lifecycle control, not a convenience feature. Treat it as a trust transition that should be auditable, revocable, and explicit about what is being replaced versus what is merely being copied.

What to watch for: Pay close attention to replacement-device flows that do not clearly retire the previous device, especially when users can move between devices without strong re-verification. A well-designed migration process should leave one current trusted device state, not several plausible ones.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org