Secrets vault selection exposes the gaps in NHI governance

At a glance

What this is: This is a practitioner guide on selecting a secrets vault, with the key finding that vault storage alone does not solve secrets discovery, rotation, or workload-level governance.

Why it matters: It matters because IAM teams need to govern secrets as identity assets across NHI, human, and autonomous workflows, not as static data objects hidden inside a vault.

👉 Read Entro Security's guide to choosing a secrets vault for your organisation

Context

Secrets vault selection is an identity governance decision, not just a storage decision. The real question is whether the organisation can see every secret, know which workload or service account is using it, and enforce rotation, revocation, and access controls without breaking operations.

That matters because secrets rarely stay inside one system or one lifecycle stage. They move through CI/CD pipelines, cloud services, partner integrations, and machine identities, which means a vault that only stores credentials leaves the governance problem largely untouched.

Key questions

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. A strong selection process starts with where secrets live, who or what uses them, and whether the platform can manage them without breaking CI/CD, partner integrations, or production services.

Q: Why do secrets vaults fail when multiple workloads share one credential?

A: Shared credentials create hidden coupling. If one workload triggers rotation or revocation, other workloads may fail unexpectedly because they rely on the same secret remaining stable. The result is a control that looks efficient on paper but increases outage risk and obscures which identity actually owns the credential.

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. If services break, stale credentials persist, or no one can trace which workload used the secret last, the programme is creating risk instead of reducing it.

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.

Technical breakdown

Secrets discovery versus secrets storage

A vault can store credentials, but storage is not discovery. Secrets sprawl appears when API keys, certificates, passwords, and tokens exist across code, pipelines, and cloud services without a complete inventory. In practice, governance fails when teams assume the vault is the system of record while other secrets remain embedded in applications, developer tools, or platform configurations. The article correctly points to the gap between central storage and ecosystem-wide visibility. Practical implication: assess whether the platform can discover secrets across environments, not just hold them once found.

Practical implication: verify that the platform can discover secrets across environments, not just store them after discovery.

Identity-based access for workloads and users

Modern secrets control depends on identity-based access, where the vault verifies the requesting identity before releasing credentials. That identity may be a human admin, a service account, a machine workload, or an application integration. The article’s emphasis on RBAC, trusted identities, and machine identity reflects a core NHI pattern: access should be based on who or what is requesting the secret, not on network location or tool ownership. The architecture only works if authentication is paired with clear entitlement boundaries. Practical implication: bind secrets access to specific identities and scopes instead of broad environment-level trust.

Practical implication: bind secrets access to specific identities and scopes instead of broad environment-level trust.

Rotation, dynamic secrets, and operational failure modes

Rotation and dynamic secrets reduce exposure, but they also introduce operational coupling. If multiple workloads depend on the same credential, a single rotation event can break downstream services or trigger downtime. That is why secrets lifecycle controls are inseparable from application dependency mapping. The article’s example of two workloads sharing one secret shows the failure mode clearly: the security model assumes secrets can change independently, while the system design may assume they remain stable. Practical implication: map every consumer before turning on automated rotation or ephemeral issuance.

Practical implication: map every consumer before turning on automated rotation or ephemeral issuance.

NHI Mgmt Group analysis

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.

Machine identity turns secrets management into an NHI discipline, not a storage discipline. Once workloads, services, and partner integrations consume credentials at runtime, the control plane must govern identities that are not human and do not behave like human users. RBAC, rotation, logging, and verification all matter, but they only work when the programme recognises that the subject is the workload identity itself. Teams should evaluate secrets tooling through an NHI lens.

Dynamic secrets expose an identity coupling problem that many teams underestimate. A secret that can change on demand is only safe if every consumer can tolerate that change without service interruption. The article’s workload A and workload B example shows the hidden dependency: one credential may actually represent multiple operational assumptions. Practitioners should use that failure mode to identify where shared secrets are masking architectural debt.

Static-versus-dynamic secrets is the practical concept this article surfaces. Static credentials create long-lived exposure and harder remediation, while dynamic issuance reduces standing exposure but demands stronger dependency control and tighter orchestration. The implication is that vault strategy must reflect the runtime shape of access, not a generic preference for centralisation. Security teams should align secret type to the actual workload pattern.

Secrets blast radius is often larger than the vault team thinks. If secrets are reused across apps, environments, and CI/CD paths, one compromise can affect multiple systems at once. That is the governance signal hidden in the article: the biggest risk is not just leakage, but shared credential topology. Practitioners should judge vault design by how much blast radius it can actually shrink.

From our research:

• 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.
• For deeper context on runtime credential exposure, see Guide to the Secret Sprawl Challenge and the control patterns that reduce secret reuse.

What this signals

Secrets vault programmes now need to be measured by exposure reduction, not by storage adoption alone. If leaked credentials remain valid long after discovery, the governance problem is lifecycle control rather than visibility. That is why the operational question is how quickly teams can revoke, reissue, and trace a secret across the services that consume it.

Static-versus-dynamic secrets will become a sharper decision point as machine identity grows. Workload-heavy environments cannot rely on the same assumptions that were built for human credential management. Security teams should expect more pressure to connect vault design with workload identity, access review, and environment segmentation.

For practitioners aligning this work with broader standards, the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both reinforce the same direction: reduce standing exposure, verify identity continuously, and govern secrets as part of a lifecycle, not as a static asset.

For practitioners

• 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.
• Bind secrets access to verified identity Require the vault to authorise requests using workload identity, service account identity, or user identity rather than relying on network location, static trust, or manual approval alone.

Key takeaways

• A secrets vault solves only part of the problem if discovery, lifecycle control, and workload visibility are missing.
• Shared credentials and weak dependency mapping turn rotation into an outage risk instead of a security control.
• IAM teams should evaluate vaults by how much they reduce standing exposure and blast radius across machine and human identities.

Key terms

• Secrets Vault: A secrets vault is a control system for storing and releasing credentials such as API keys, passwords, certificates, and tokens. In NHI governance, the vault matters less as a container and more as a policy point that determines who or what can use a secret, when it can be used, and how it is rotated or revoked.
• Dynamic Secret: A dynamic secret is a credential created on demand and expired after use or after a short time window. For non-human identities, this reduces standing exposure, but only if every dependent workload can tolerate frequent change and the organisation can trace each issuance back to a specific identity and purpose.
• Machine Identity: Machine identity is the identity assigned to a workload, service, application, or automated system so it can authenticate and access resources. It is not a human user account, and it should be governed through lifecycle, entitlement, and monitoring controls that reflect how systems actually operate at runtime.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, pipelines, chat tools, cloud services, and infrastructure. It creates hidden exposure because teams lose track of where secrets exist, who depends on them, and whether they are still valid or already compromised.

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

👉 Entro Security's full post covers the vault selection criteria, feature trade-offs, and operational limitations in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 programme maturity, it is worth exploring.