Topic starter
25/06/2026 5:09 pm
TL;DR: Vaults store secrets, but they do not provide end-to-end visibility, usage intelligence, or automatic containment when secrets are exposed, according to Entro Security. That gap leaves organisations managing secrets sprawl, overprovisioned access, and blind spots that a storage-only model cannot close.
Editorial analysis by NHI Mgmt Group, based on content published by Entro Security: “The Secret Life of Secrets: Why Vaults Aren’t Enough”.
Key questions
Q: What breaks when secrets are still stored outside managed vaults?
A: Secrets become easy to reuse across humans, scripts, and agents without a consistent audit trail.
Q: Why do over-privileged cloud entitlements increase breach impact?
A: They increase breach impact because a stolen credential or compromised integration can inherit far more access than the underlying task requires.
Q: How can security teams tell whether secret management is actually working?
A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems.
Practitioner guidance
- Map every active secret across vaults and applications Build an inventory that shows where each API key, token, certificate, and connection string exists, who owns it, and which workload consumes it.
- Separate storage from lifecycle control Define approval, rotation, revocation, and recertification steps for secrets outside the vault so a stored credential is not mistaken for a governed one.
- Reduce permissions at secret creation Issue each secret with the narrowest verified scope for the workload that will use it, then revalidate that scope when the workload changes.
Bottom line: Vault adoption does not close the governance gap if organisations cannot inventory, monitor, and revoke secrets after they are issued.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
25/06/2026 5:40 pm
Vaults are storage controls, not governance controls: A secret can be stored safely and still remain operationally dangerous once it is issued to a workload or user. The governing question is not where the secret sits, but whether the organisation can see how it is used and revoke it when the context changes. This is the line that separates storage from lifecycle control, and practitioners should design for the lifecycle.
A few things that frame the scale:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should security teams respond when a secret is exposed in code or logs?
A: Start by identifying what the secret can access, not by rotating it immediately. Then isolate affected systems, revoke the credential, update dependent configurations, and verify the replacement works. A safe response sequence depends on blast radius, because the same secret may unlock multiple services or environments.
👉 Read our full editorial: Vaults alone do not solve secrets sprawl and exposure risk
This post was modified 1 day ago by NHI Mgmt Group