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.
Editorial analysis by NHI Mgmt Group, based on content published by Entro Security: “Secrets storage and encryption: everything you need to know”.
By the numbers:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
Key questions
Q: What breaks when secrets are encrypted but not governed end to end?
A: Encryption can hide a secret without limiting its operational reach.
Q: Why do long-lived secrets increase identity risk in cloud and SaaS environments?
A: Long-lived secrets remain reusable until someone revokes them, which gives attackers a durable target.
Q: How do organisations know if secrets management is actually working?
A: Secrets management is working only when credentials are absent from endpoints, build logs, environment variables, and source-controlled configuration.
Practitioner guidance
- Define a complete secret inventory Map every place secrets can exist, including repositories, CI/CD variables, configuration files, collaboration tools, and secret stores.
- Separate storage control from lifecycle control Use encryption and vaulting to reduce exposure, but manage rotation, expiry, and revocation as distinct governance controls with explicit ownership and audit evidence.
- Assign clear ownership for each secret class Tie every application secret, API key, certificate, and token to a named owner and an offboarding path so credential loss does not become organisational ambiguity.
Bottom line: Secrets encryption reduces exposure, but it does not by itself resolve where secrets are stored, who can use them, or when they should be revoked.
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:31 pm
Encrypted storage does not remove the NHI governance gap: the core failure is not whether a secret is protected by AES-256 or stored in a vault, but whether the organisation can prove where the secret exists and when it stops being valid. Encryption reduces exposure, yet it leaves ownership, discoverability, and revocation unanswered. Practitioners should treat the secret as an identity object with a lifecycle, not as a file to be hidden.
A few things that frame the scale:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: What is the difference between vault-based and vaultless secrets management?
A: Vault-based secrets management centralises storage, access, and auditing in one control point. Vaultless approaches spread encrypted secrets closer to the application, which can simplify delivery but often weakens organisation-wide visibility, standardisation, and revocation confidence across the estate.
👉 Read our full editorial: Secrets storage and encryption expose the real NHI governance gap
This post was modified 1 day ago by NHI Mgmt Group