Notifications
Clear all
Topic starter
25/06/2026 5:15 pm
TL;DR: Secrets migration fails when teams treat it as a big-bang project, because manual scripts, policy drift, and downtime break authentication chains across cloud and Kubernetes environments, according to Akeyless. The real issue is not moving secrets faster, but governing fragmented secret stores without exposing credentials or losing control.
NHIMG editorial — based on content published by Akeyless: secrets migration and multi-vault governance in hybrid cloud
Questions worth separating out
Q: How should security teams migrate secrets without breaking live applications?
A: Security teams should start with dependency mapping, then migrate in controlled phases by source, folder, or environment.
Q: Why do secrets migration projects create hidden risk in hybrid environments?
A: Hybrid environments multiply access models, audit trails, and ownership boundaries, so migration can easily create drift between what teams think is protected and what is actually exposed.
Q: What breaks when organisations centralise secrets too quickly?
A: What breaks first is usually application continuity.
Practitioner guidance
- Define a migration operating model before touching production secrets Map source stores, application dependencies, ownership, and rollback criteria before any cutover.
- Use central governance before consolidation Start with a control layer that can govern secrets in place across cloud vaults, Kubernetes, and legacy stores, then retire sources only after policy consistency is proven.
- Require encrypted transfer with customer-held keys Do not allow migration paths that decrypt secrets into readable form.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Configuration-level guidance for Multi-Vault Governance across AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault, and Kubernetes
- The step-by-step Automatic Migration flow, including source connection, secret selection, key application, and console verification
- Operational distinctions between unifying secrets in place and fully migrating redundant vaults into a single platform
- How the gateway and Distributed Fragments Cryptography model are used during migration to keep secrets encrypted
👉 Read Akeyless's analysis of secrets migration and multi-vault governance →
Secrets migration across vaults: what IAM teams need to know?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:50 pm
Secrets migration failure is usually a governance failure, not a tooling failure. The article describes a pattern that many programmes still underestimate: migration projects stall when controls are organised around individual vaults rather than the lifecycle of the secret itself. Policy drift, shadow vaults, and broken application dependencies are all symptoms of fragmented ownership. The practitioner conclusion is that consolidation only works when governance is designed across stores, not inside one store at a time.
A few things that frame the scale:
- From our research: 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to The 2025 State of NHIs and Secrets in Cybersecurity.
A question worth separating out:
Q: Should IAM teams govern secrets in place before retiring old vaults?
A: Yes. Governing secrets in place gives teams a stable way to standardise policy, logging, and access review before any irreversible consolidation. It also exposes shadow vaults and duplicate dependencies early, which makes retirement decisions safer and more defensible.
👉 Read our full editorial: Secrets migration and multi-vault governance in hybrid cloud
