Notifications
Clear all
Topic starter
25/06/2026 5:08 pm
TL;DR: Choosing a secrets vault is really a decision about how well an organisation can control secrets sprawl, rotation, identity-based access, and workload visibility across cloud, CI/CD, and machine use cases, according to Entro Security. The governance problem is not vault storage alone, but whether the programme can keep pace with how non-human identities fetch, share, and outlive their credentials.
NHIMG editorial — based on content published by Entro Security: How to choose a secret Vault for your organization
Questions worth separating out
Q: How should security teams choose a secrets vault for multi-cloud workloads?
A: Choose a vault based on discovery coverage, identity-based access, rotation support, and operational fit across the full workload estate.
Q: Why do secrets vaults fail when multiple workloads share one credential?
A: Shared credentials create hidden coupling.
Q: How do teams know if secrets rotation is actually working?
A: Rotation is working only when every consumer can still authenticate after the change and the organisation can see the credential move through its lifecycle.
Practitioner guidance
- Map every secret consumer before selecting a vault Inventory which applications, workloads, partner services, and CI/CD jobs depend on each secret, then record where those dependencies live across production, test, and development environments.
- Separate environments before centralising credentials Use distinct vault boundaries or equivalent policy boundaries for production, development, and test so a lower-trust environment cannot become an access path into higher-value secrets.
- Test rotation against real workload dependencies Simulate secret rotation for shared credentials and check whether downstream workloads fail, retry, or silently degrade before enabling automated change at scale.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- Feature-by-feature evaluation points for vault selection across cloud, on-prem, and hybrid environments
- Practical discussion of dynamic secrets, database rotation, PKI issuance, and identity-based access controls
- Operational trade-offs for integrating vaults into CI/CD, Git, and DevOps workflows
- Considerations for open-source versus managed options, including setup effort and ongoing maintenance
👉 Read Entro Security's guide to choosing a secrets vault for your organisation →
Secrets vaults and NHI governance: what do teams miss most?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:38 pm
Secrets vault choice is really a governance model choice. A vault that stores secrets but cannot discover, classify, and monitor them across the ecosystem leaves the underlying identity problem intact. That is why vault selection should be judged by lifecycle coverage, not by storage capacity alone. Practitioners need to treat the vault as one control in a wider secrets governance fabric.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and they are 13% more likely to be categorised as critical than code-based leaks.
A question worth separating out:
Q: Should organisations centralise all secrets into one vault?
A: Not automatically. Centralisation improves visibility only if access boundaries, environment separation, and lifecycle controls are strong enough to prevent one compromise from spreading. In some environments, a single control plane is useful, but the real question is whether it reduces blast radius without creating a single point of failure.
👉 Read our full editorial: Secrets vault selection exposes the gaps in NHI governance
