Vault migration is the controlled copying of stored secrets or shared access data from one account to another. In this model, each destination receives its own re-encrypted copy, preserving separation between accounts. It supports structured onboarding after linking accounts and creates a clean audit record for administrators.
Expanded Definition
Vault migration is more than moving a secret from one location to another. In NHI operations, it is a controlled re-issuance process that preserves account separation, re-encrypts the secret for the destination context, and maintains evidence for audit and rollback. That distinction matters because a copied secret should not become a shared trust artifact across applications or environments.
The term is often applied alongside onboarding, vault consolidation, and credential rotation, but it is not the same as bulk export. A proper migration validates source ownership, destination authorization, encryption boundaries, and post-move access policy. This aligns with least privilege expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where secret handling, access enforcement, and auditability are required.
Usage in the industry is still evolving, and some vendors describe migration as an administrative convenience while others treat it as a security-sensitive lifecycle event. NHIMG recommends treating it as a governed change, not a background sync. The most common misapplication is treating vault migration as simple copying, which occurs when teams move secrets without re-encryption, destination scoping, or access review.
Examples and Use Cases
Implementing vault migration rigorously often introduces temporary operational friction, requiring organisations to weigh faster onboarding and cleaner inventory against change control, revalidation, and downstream application testing.
- Onboarding a newly acquired business unit into a central vault while preserving separate tenant boundaries and producing a clean audit trail for each destination copy.
- Moving application secrets from a legacy vault into a modern platform after validating that each destination is individually re-encrypted and not shared across workloads.
- Consolidating duplicate credentials discovered during a review of the Guide to the Secret Sprawl Challenge, where migration is used to reduce duplication without exposing plaintext.
- Rehousing static secrets into a more controlled lifecycle, then separating them from dynamic secrets as described in the Ultimate Guide to NHIs.
- Transferring service-account credentials during cloud platform restructuring, while enforcing destination-specific policy, rotation after cutover, and decommissioning of the old vault record.
These use cases map to common governance patterns in secrets management and to the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, where secure handling and traceable configuration changes matter.
Why It Matters in NHI Security
Vault migration becomes a security issue when it is used to mask poor lifecycle discipline. If teams repeatedly move the same secret across environments, they can create hidden duplication, ambiguous ownership, and stale access paths that survive long after the business reason has ended. NHIMG research shows that 62% of all secrets are duplicated and stored in multiple locations, a pattern that makes migration discipline central to reducing exposure.
The governance risk is not just accidental leakage. Poorly managed migration can preserve overused credentials, bypass approval workflows, or leave old vault entries active after cutover. That is why migration must be paired with source decommissioning, destination validation, and follow-up review of downstream consumers. The same discipline helps prevent secret sprawl and reduces the chance that one compromise becomes a multi-system incident.
Organisations typically encounter the consequences only after a vault consolidation, incident response, or platform migration exposes duplicated access paths, at which point vault 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 CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret handling and duplication risks during NHI secret movement. |
| NIST CSF 2.0 | PR.AA-1 | Identity and access governance applies when secrets are re-bound to a new destination. |
| NIST SP 800-63 | Identity proofing and authenticator assurance inform how migrated secrets are trusted. |
Treat migration as controlled re-issuance, then verify storage, access, and rotation against NHI-02.
Related resources from NHI Mgmt Group
- What do security teams get wrong about Vault migration projects?
- What breaks when child accounts are populated manually instead of using controlled vault migration processes?
- What is a secrets vault and which tools are available?
- How should security teams reduce vault sprawl without disrupting delivery?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
