Secrets storage and encryption expose the real NHI governance gap

At a glance

What this is: This is an NHI governance guide on secrets storage and encryption, with a clear argument that centralisation, rotation, and access control matter more than encryption alone.

Why it matters: It matters because IAM, PAM, and NHI teams must govern secrets as living identities across pipelines, vaults, and applications, not treat them as static configuration.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Entro Security's guide to secrets storage and encryption for NHI governance

Context

Secrets storage and encryption are the control layer that keeps machine credentials, API keys, tokens, and certificates from becoming easy entry points into cloud and application environments. The governance problem is not simply whether secrets are encrypted, but whether they are discoverable, rotated, revoked, and tied to accountable identity lifecycle processes.

In NHI programmes, secrets are not static artefacts. They sit inside build systems, repositories, vaults, and runtime services, which means the effective attack surface is defined by access paths and lifecycle drift, not by encryption strength alone. That is why teams need a governance model that spans storage, access control, and operational hygiene.

The article’s starting position is typical for enterprise environments: developers often trade control for convenience, then security teams try to recover that lost control with tooling after the fact.

Key questions

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. That means inventorying where secrets are stored, enforcing access policy, rotating credentials on schedule and on change events, and removing stale secrets through offboarding and revocation workflows.

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. Encryption protects the data format, but it does not stop overprivileged access, poor lifecycle control, or drift between policy and actual use.

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. In reality, vaultless designs shift responsibility to developers and pipelines, which can reduce visibility, weaken consistency, and make rotation harder to enforce at scale.

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.

Technical breakdown

Why encryption alone does not secure NHI secrets

Encryption protects secrets at rest and in transit, but it does not solve exposure caused by poor placement, weak access boundaries, or uncontrolled distribution. If a secret is hardcoded in source code, stored in multiple repositories, or shared across teams without lifecycle controls, encryption only protects the container, not the governance model. Secrets still need authenticated access, auditability, revocation, and rotation. In practice, that means the risk is often identity sprawl rather than cryptographic weakness.

Practical implication: treat encryption as a baseline control and map where secrets are created, copied, and consumed before assuming they are protected.

Vaults, vaultless designs, and the control tradeoff

A vault centralises secrets so teams can enforce access policy, audit use, and rotate credentials from one place. Vaultless designs distribute secrets closer to applications, which can reduce latency and infrastructure overhead, but they shift responsibility to developers and make governance harder to standardise. The key architectural question is whether the environment can tolerate decentralised control without losing visibility. For NHI programmes, that tradeoff matters because every additional storage location increases the likelihood of drift between policy and practice.

Practical implication: choose the storage model that matches your operating maturity, then verify that visibility and rotation are still enforceable everywhere secrets exist.

How lifecycle management changes secrets security

Secrets management only becomes defensible when lifecycle controls are built in. That includes expiry, revocation, rotation, and access review, all of which turn a credential from a permanent asset into a governed entitlement. This is where IAM, PAM, and NHI discipline meet: the same identity that can read a secret should be traceable, reviewable, and removable. Without that linkage, secrets become durable privileges that outlast the workload, the developer, or the integration that created them.

Practical implication: align secrets lifecycle events with identity governance workflows so old credentials are removed as reliably as new ones are issued.

NHI Mgmt Group analysis

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.

Vault centralisation improves control, but only if the organisation can sustain it. A single secrets repository gives IAM and security teams auditability, rotation leverage, and access policy consistency. But centralisation also creates operational dependency, so resilience, high availability, and clean role boundaries matter as much as the vault itself. The practitioner takeaway is that control consolidation without operational discipline simply moves the weak point.

Vaultless models reduce friction, but they also distribute accountability to the application layer. That shift can work in mature engineering environments, but it widens the gap between policy intent and developer behaviour. When teams manage secrets directly in application contexts, the governance burden moves into code review, deployment pipelines, and secure configuration practices. The discipline required is not optional, because decentralisation without oversight becomes unmanaged NHI sprawl.

Lifecycle management is the real differentiator between secrets storage and secrets security. Rotation, revocation, expiry, and access review are the controls that stop secrets from becoming permanent standing access. This post is really about the lifecycle of non-human privilege: a secret that is stored securely but never retired is still an identity risk. Practitioners should judge any secrets programme by how well it removes stale access, not just by how well it encrypts data.

Static secrets create an identity blast radius that is larger than most teams admit. Once a credential is reused across services or embedded in automation, compromise of one location can cascade into multiple systems. That is why secrets governance must be integrated with workload identity, least privilege, and offboarding processes. The practical conclusion is simple: the smaller the reusable secret footprint, the smaller the blast radius when a secret leaks.

From our research:

• 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.
• For a broader control view, read Top 10 NHI Issues for the lifecycle and governance failures that let secrets persist after they should be retired.

What this signals

Static secret thinking is the wrong model for modern identity programmes. Once credentials move through CI/CD, collaboration tools, and multiple secret stores, the real control problem becomes lifecycle coordination. Organisations that cannot trace where a secret exists will struggle to enforce revocation consistently, which is why secrets governance now sits alongside IAM and PAM rather than beneath them.

With an average of 6 distinct secrets manager instances reported in our research, fragmentation is already a governance issue rather than a tooling issue. The practical signal is whether your programme can enforce one access policy and one retirement process across all secret repositories, not whether each repository has its own controls.

The deeper pattern is that secrets management is converging with workload identity governance. As applications, pipelines, and services become more distributed, teams need to align secrets controls with broader identity lifecycle management and the NIST Cybersecurity Framework 2.0, especially around access control, monitoring, and response.

For practitioners

• 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.
• Reduce reusable secret sprawl Limit shared credentials across teams and services, and prefer narrower scopes where possible so one leaked secret cannot unlock multiple systems.

Key takeaways

• Secrets encryption is necessary, but it does not solve the core NHI governance problem of discovery, access, and lifecycle control.
• Vault centralisation and vaultless distribution each create different governance risks, so the architecture choice must match the organisation's operating maturity.
• Teams that cannot rotate, revoke, and audit secrets quickly are managing storage, not security.

Key terms

• Secret Lifecycle Management: Secret lifecycle management is the process of creating, storing, rotating, revoking, and retiring credentials over time. In NHI governance, it matters because a secret that is technically protected but never removed still represents standing access and long-lived privilege.
• Vaultless Secrets Management: Vaultless secrets management stores credentials closer to the applications that use them instead of placing everything in a central vault. It can reduce operational friction, but it also pushes more security responsibility into application teams and makes consistent governance harder to sustain.
• Identity Blast Radius: Identity blast radius is the amount of access or system exposure that becomes available when one credential is compromised. For NHI programmes, it is shaped by privilege scope, reuse, distribution, and how quickly secrets can be rotated or revoked.

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.

👉 The full Entro Security post covers vault options, encryption models, and implementation tradeoffs in more detail.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance, it is worth exploring.