Secrets migration

Expanded Definition

Secrets migration is not just copying credentials from one vault to another. It is a controlled transition of OWASP Non-Human Identity Top 10 scope, where the same secret may need new storage, new access policy, new rotation behavior, and new audit expectations. In NHI operations, the term usually covers API keys, certificates, tokens, and application secrets that must remain usable while their backend governance changes. Definitions vary across vendors on whether migration includes re-issuing the secret, remapping it to a different identity, or only relocating encrypted material. For that reason, a migration plan should state whether the goal is storage replacement, credential replacement, or full control-plane replacement. The distinction matters because a secret can remain technically functional while becoming operationally noncompliant if entitlement, ownership, or rotation state is not updated at the same time.

The most common misapplication is treating secrets migration as an infrastructure copy job, which occurs when teams move vault contents without validating application dependencies or revocation timing.

Examples and Use Cases

Implementing secrets migration rigorously often introduces short-term application friction, requiring organisations to weigh continuity of service against the cost of staged dual-running and validation.

• Moving database credentials from a legacy secrets store into a centralized platform while keeping both stores valid during a controlled cutover.
• Replacing long-lived CI/CD tokens after a supply chain review, then re-binding build jobs to new identities and access policies, as seen in cases discussed in the CI/CD pipeline exploitation case study.
• Converting static API keys into rotated, environment-specific secrets after a service account redesign, using the lessons in the Ultimate Guide to NHIs — Static vs Dynamic Secrets.
• Relocating secrets from developer-managed files into governed storage after repository scanning shows hidden coupling, a pattern aligned with the Guide to the Secret Sprawl Challenge.
• Reissuing certificates and API tokens when an organisation adopts tighter separation of duties, least privilege, and new audit controls under a unified identity program.

In practice, the safest migrations preserve rollback capability, verify every dependency before revocation, and confirm that applications can authenticate after the old secret is retired.

Why It Matters in NHI Security

Secrets migration is a security event because exposed or stale secrets often become the failure point after platform changes, mergers, incident response, or vault replacement. NHIMG research shows that 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, underscoring how often secrets remain embedded in workflows even after governance changes. The problem is not only leakage during transfer; it is also policy drift, where the new store enforces different rotation, access, or inheritance rules than the old one. That can leave valid credentials accessible to machines, pipelines, or teams that no longer should have them. NHI practitioners should treat migration as a chance to remove standing access, shorten secret lifetime, and rebuild ownership around the actual service rather than the historical storage location. The security value comes from coupling movement with cleanup, not from the move itself.

Organisations typically encounter the consequences only after a vault decommission, pipeline outage, or leaked secret forces emergency rotation, at which point secrets migration becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams prioritise migration from secrets to federation?
• How should security teams handle credential migration without exposing secrets?
• What is secrets sprawl and why does it create security risk?
• What is a secrets vault and which tools are available?