The planned movement of identity data, configuration, and control logic from one operating model to another. For cloud identity security, the hard part is usually preserving governance outcomes after the platform, release cadence, and support model change.
Expanded Definition
Identity migration is the controlled transfer of identity records, authentication methods, authorization rules, lifecycle processes, and administrative ownership from one platform or operating model to another. In NHI security, the term is broader than moving accounts or syncing directories because the real objective is to preserve governance outcomes after the surrounding control plane changes. That includes keeping entitlement boundaries intact, preserving auditability, and ensuring secrets, certificates, and service account relationships still behave as intended after cutover. NIST Cybersecurity Framework 2.0 frames this kind of work as an operational resilience issue, because identity changes can disrupt access, monitoring, and recovery if they are not planned as a governed transition NIST Cybersecurity Framework 2.0. Definitions vary across vendors when the migration also includes policy translation, federation redesign, or application remediation, so practitioners should be explicit about scope. At NHI Management Group, identity migration is treated as a security change program, not just a directory project. The most common misapplication is treating identity migration as a data copy exercise, which occurs when teams move accounts but fail to migrate controls, ownership, and revocation logic.
Examples and Use Cases
Implementing identity migration rigorously often introduces temporary duplication of control paths, requiring organisations to weigh continuity of access against the risk of parallel systems and inconsistent policy enforcement.
- Moving service accounts from on-premises Active Directory into a cloud identity provider while preserving least-privilege roles, key rotation, and deprovisioning workflows.
- Converting legacy API key management into a central secrets platform so that the migration includes issuance rules, access reviews, and revocation triggers, not only credential import.
- Shifting workload identity from static credentials to federated short-lived tokens, which reduces exposure but requires application changes and validation of trust chains.
- Replatforming a CI/CD environment after a merger, where pipeline identities, deploy permissions, and approval gates must be mapped carefully to avoid privilege creep.
- Documenting lessons from incidents such as the 52 NHI Breaches Analysis and aligning remediation with migration planning so old and new paths do not remain active at the same time.
For implementation patterns, teams can compare migration sequencing against identity governance guidance in the Ultimate Guide to NHIs and validate that migration tasks reflect access architecture expectations in the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Identity migration is where governance often breaks quietly. NHI Management Group notes that 97% of NHIs carry excessive privileges, and that makes migration especially dangerous when old entitlements are copied forward instead of re-evaluated Ultimate Guide to NHIs. If the target environment changes support models, token formats, or rotation mechanics, a technically successful migration can still leave hidden exposure behind. A common failure mode is retaining the legacy identity system as a fallback long after cutover, which creates dual control planes and weakens accountability. That is why migration planning must include inventory, ownership assignment, validation, rollback boundaries, and explicit retirement of the source state. This is also where breach history becomes useful: the Cisco DevHub NHI breach and JetBrains GitHub plugin token exposure show how identity sprawl and unmanaged secrets can persist across operational transitions. Organisations typically encounter the cost of identity migration only after a cutover exposes stale access or a decommissioned system is found still issuing credentials, at which point the term becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity migration can preserve or break NHI lifecycle and ownership controls. |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and access architecture must remain valid across migration. |
| NIST Zero Trust (SP 800-207) | PA/TA | Zero Trust migration hinges on reestablishing trust and policy enforcement. |
Revalidate identity and access controls after cutover and before decommissioning.
