Notifications
Clear all
Topic starter
25/06/2026 5:03 pm
TL;DR: Secrets storage and encryption reduce exposure, but they do not solve the governance problem of where secrets live, how they are rotated, and who can access them across cloud and DevOps workflows, according to Entro Security. The decisive issue is visibility and lifecycle control, not just stronger encryption.
NHIMG editorial — based on content published by Entro Security: Secrets storage and encryption: everything you need to know
Questions worth separating out
Q: How should security teams govern secrets across vaults and applications?
A: Security teams should govern secrets as lifecycle-managed non-human identities, not as static configuration values.
Q: Why do encrypted secrets still create risk in cloud environments?
A: Encrypted secrets still create risk when they are hardcoded, copied widely, reused across services, or accessible through weak identity boundaries.
Q: What do organisations get wrong about vaultless secrets management?
A: The common mistake is assuming that distributing secrets closer to applications makes them easier to govern.
Practitioner guidance
- Inventory every secret location Build a complete map of secrets in repositories, CI/CD pipelines, collaboration tools, vaults, and runtime systems so you can see where NHI exposure actually exists.
- Separate storage from access policy Keep encryption, access control, and rotation decisions under governance control rather than leaving them embedded in application code or ad hoc developer workflows.
- Standardise rotation and revocation triggers Tie secret rotation to lifecycle events such as service changes, pipeline changes, and access exceptions so credentials do not persist beyond their operational need.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- A side-by-side look at vault and vaultless secrets management models, including where each tends to fit in practice.
- Detailed comparisons of Azure Key Vault, HashiCorp Vault, and AWS Secrets Manager for cloud-specific deployments.
- Discussion of encryption at rest, encryption in transit, and key management choices such as BYOK and KMS.
- Operational pros and cons around access control, auditing, latency, and maintenance overhead.
👉 Read Entro Security's guide to secrets storage and encryption for NHI governance →
Secrets storage and encryption: is your NHI governance keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:31 pm
Secrets storage is a governance problem before it is an encryption problem. Encrypting a secret does nothing if the secret is scattered across repositories, build systems, collaboration tools, and runtime environments. The control failure is usually discoverability and lifecycle drift, not the absence of cryptography. Practitioners should treat exposure paths as the primary risk surface, because that is where secrets governance actually breaks.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a behaviour gap that technology alone will not close.
A question worth separating out:
Q: How do teams know if a secrets programme is actually working?
A: A secrets programme is working when teams can find every secret, rotate or revoke it quickly, and prove that access is scoped and auditable. If credentials linger after service changes, or if developers bypass policy to keep delivery moving, the programme is only partially effective.
👉 Read our full editorial: Secrets storage and encryption expose the real NHI governance gap
