The controlled movement of passwords, passkeys, or shared secrets from one system to another. In enterprise identity programmes, it is not just data transfer. It is a governance event that can create duplicates, preserve old access paths, or expose unmanaged stores if ownership and closure are not defined.
Expanded Definition
Credential migration is the controlled transfer of passwords, passkeys, API keys, certificates, or shared secrets between systems, vaults, pipelines, or identity platforms. In NHI programmes, it is not a simple copy operation because the migration can create parallel trust paths, inherited permissions, or orphaned secrets if ownership, revocation, and cutover timing are not governed.
Industry usage is still evolving because some teams treat migration as a one-time lift and shift, while others include secret rotation, format translation, and decommissioning of legacy stores in the same scope. The operational difference matters: a migrated credential that remains valid in the source system is still a live attack path. That is why credential migration should be planned alongside lifecycle controls described in the OWASP Non-Human Identity Top 10 and the assurance concepts in NIST SP 800-63 Digital Identity Guidelines.
The most common misapplication is treating migration as storage relocation, which occurs when teams move the secret but fail to revoke the old binding, rotate dependent tokens, or validate the downstream workload that still authenticates against the original source.
Examples and Use Cases
Implementing credential migration rigorously often introduces temporary operational friction, requiring organisations to balance continuity of service against the risk of duplicated access paths and failed cutovers.
- Moving database passwords from application config files into a central secrets manager while ensuring the old file-based credentials are immediately invalidated.
- Transferring CI/CD deploy keys during a platform change so that build jobs continue to run, then rotating the keys and closing the legacy repository access path.
- Migrating service account credentials during a cloud tenancy split, where ownership must follow the workload and not remain with the old platform team.
- Reissuing certificates during workload consolidation so that downstream services trust the new certificate chain without leaving the prior certificate usable.
- Replacing shared API keys with per-environment credentials after a breach review, using lessons from the Guide to the Secret Sprawl Challenge and the CI/CD pipeline exploitation case study.
In practice, the migration window should include inventory, mapping, validation, rotation, and decommissioning. A well-run changeover often borrows patterns from Ultimate Guide to NHIs — Static vs Dynamic Secrets, because moving to dynamic credentials reduces the chance that an old secret survives beyond the intended cutover. When the term appears in platform change plans, it usually indicates a dependency chain that spans multiple identities rather than a single secret object.
Why It Matters in NHI Security
Credential migration matters because the failure mode is usually invisible until attackers or auditors discover that the old secret still works. In NHI environments, that can mean duplicate access in source and target systems, broken ownership chains, or secrets copied into uncontrolled locations such as tickets, chat threads, or build logs. NHIMG research shows that 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which makes migration events especially risky when teams use ad hoc coordination instead of controlled workflows. The 2024 Non-Human Identity Security Report also highlights that 88.5% of organisations say their NHI practices lag behind or only match human IAM maturity, which helps explain why migration is often under-governed.
The security issue is not the move itself, but the incomplete closure of the previous trust boundary. If a credential is migrated without revocation, the old system remains an exploitable foothold. If the destination is not validated, workloads may silently fall back to older secrets. These failures are common in breached environments such as the Cisco Active Directory credentials breach and the 230M AWS environment compromise, where exposed credentials were operationally useful almost immediately.
Organisations typically encounter credential migration as an urgent recovery task only after a platform move, compromise, or audit finding reveals that the old secret path was never fully retired, at which point controlled migration 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 SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret handling, duplication, and lifecycle closure during migration. |
| NIST SP 800-63 | Defines identity assurance concepts that inform credential strength and reissuance expectations. | |
| NIST CSF 2.0 | PR.AC-1 | Access rights and credentials must be managed through controlled identity lifecycle processes. |
Migrate credentials with rotation, revocation, and destination validation so old secret paths are removed.
