Static vaults assume access is persistent enough to store, retrieve, and review later. Cloud-native workloads often do not behave that way. Containers, pipelines, and serverless jobs need access for minutes, not days, so a stored secret becomes a standing liability. Governance breaks when the control model is slower than the workload lifecycle.
Why Static Vaults Become a Governance Bottleneck
Static vaults were built around a persistence model: store a secret, retrieve it later, and review its use after the fact. That model is poorly matched to cloud-native systems where containers, CI/CD jobs, and serverless functions may exist for only minutes. When access outlives the task, the secret becomes standing privilege, which is exactly what governance is meant to avoid.
NHIMG research shows the scale of the problem in practice. In the Ultimate Guide to NHIs, 96% of organisations were found to store secrets outside secrets managers in vulnerable locations, and 73% of vaults were misconfigured. That means the vault is often treated as a control boundary even when the real leakage points are code, pipelines, and deployment tooling. NIST’s Cybersecurity Framework 2.0 reinforces the need for governance to align with operational reality, not just policy intent.
In practice, many security teams discover the mismatch only after a CI job, token, or service account has already been reused outside its intended window.
How Cloud-Native Identity Control Needs to Work Instead
Cloud-native governance works better when identity is treated as workload-bound and time-bound rather than as a durable secret in a central vault. For short-lived workloads, the preferred pattern is to issue credentials just in time, scope them to a single task, and revoke them automatically when the workload completes. Best practice is evolving toward ephemeral access, workload identity, and runtime policy evaluation rather than static retrieval from a vault.
That usually means three design choices:
- Use workload identity as the primary primitive, so the platform can prove what the workload is before issuing access.
- Prefer short-lived tokens and dynamically minted secrets over long-lived shared credentials.
- Evaluate access at request time with context, such as workload state, destination resource, environment, and change window.
This approach is consistent with the identity-first direction described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. It also aligns with the Zero Trust expectation that access should be continuously assessed, not presumed because a secret exists in a vault. For implementation planning, the NIST Cybersecurity Framework 2.0 is useful as a governance scaffold, while current guidance suggests pairing it with policy-as-code and automated revocation for cloud workloads.
This guidance tends to break down in legacy environments where applications cannot authenticate natively and still depend on shared credentials embedded in configuration or runtime files.
Common Failure Modes and When Vaults Still Matter
Tighter secret controls often increase operational overhead, so organisations have to balance rapid deployment against stronger revocation and traceability. That tradeoff is especially visible in hybrid estates, where some workloads can use workload identity while others still require a vault as a temporary bridge.
There is no universal standard for this yet, but current guidance suggests vaults should be treated as a transitional control, not the end state, for cloud-native identity governance. Vaults still matter for high-risk break-glass access, bootstrap credentials, and legacy integrations, provided they are paired with rotation, expiry, and offboarding controls. NHIMG data underscores why this matters: only 20% of organisations have formal processes for offboarding and revoking API keys, and 71% of NHIs are not rotated within recommended time frames.
Edge cases also include multi-account automation, ephemeral build runners, and third-party pipelines. Those environments often fail because access is granted to the pipeline identity rather than to the specific task, creating broad reuse potential. For deeper operational context, NHIMG’s Guide to the Secret Sprawl Challenge is a useful reference, especially when secret distribution has outgrown central governance. In practice, static vaults become brittle when the environment scales faster than the lifecycle controls around the secret store.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret rotation and lifecycle control for non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Access control must fit ephemeral cloud workloads and least privilege. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires runtime verification instead of trusting stored secrets. |
Replace durable secrets with short-lived credentials and enforce automated rotation and revocation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
