Vaulting protects the secret itself, while runtime access control decides whether a request should be allowed at the moment of use. A vault can store credentials securely, but it does not automatically enforce context, task scope, or session conditions. Mature programs need both controls working together.
Why This Matters for Security Teams
Vaulting and runtime access control solve different problems, and confusing them leaves a gap that attackers and misconfigurations can exploit. Vaulting reduces exposure of secret sprawl by storing credentials centrally, but it does not decide whether a request is legitimate at the moment of use. Runtime control is what enforces task scope, session context, and policy. That distinction matters most for NHIs because secrets are often duplicated, overused, and left active far longer than intended.
NHIMG research shows that 62% of secrets are duplicated and stored in multiple locations, which is exactly the kind of condition vaulting alone cannot clean up. A vaulted secret can still be over-permissioned, reused by multiple applications, or retrieved outside its intended context. That is why security teams need both storage protection and request-time policy. The Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both reflect the same operational reality: protecting the credential is necessary, but it is not sufficient for controlling usage.
In practice, many security teams discover the difference only after a vaulted credential has already been used in the wrong session, by the wrong workload, or for the wrong task.
How It Works in Practice
Vaulting is a storage control. It keeps secrets encrypted, reduces hard-coded credentials, and provides a managed place to retrieve tokens, API keys, and certificates. Runtime access control is an authorization control. It evaluates the request itself, then decides whether to allow access based on identity, purpose, environment, time, network posture, or task context. In mature environments, the two controls should be chained: the vault issues or serves the secret only when the runtime policy permits the request.
A practical pattern is to pair a vault with short-lived issuance and policy-as-code. For example, a workload presents its identity, requests a credential for one task, and receives a JIT secret that expires quickly. The access decision can then be evaluated against role, workload identity, and context, rather than simply checking whether the caller knows a static password. This aligns well with current guidance in PCI DSS v4.0, which emphasises limiting credential exposure and access, and with NHIMG’s broader guidance on Static vs Dynamic Secrets.
- Use vaulting to reduce secret leakage, hard-coding, and uncontrolled distribution.
- Use runtime authorization to validate intent, scope, and session conditions before use.
- Prefer ephemeral secrets for workloads that change tasks frequently or operate autonomously.
- Bind access to workload identity, not just to a stored credential.
This model is strongest when requests are discrete and policy can be evaluated in real time, but these controls tend to break down when legacy apps cache secrets locally and bypass the authorization path entirely.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance stronger enforcement against latency, developer friction, and incident response speed. That tradeoff is real, especially in older environments where applications assume long-lived credentials or where multiple services share one NHI. Best practice is evolving, and there is no universal standard for every vault-and-policy combination yet.
One common edge case is a vault that rotates secrets well but still hands them out to any authenticated caller without checking task intent. Another is a strong policy engine that cannot help because the credential itself is static, copied into CI/CD logs, or reused across services. NHIMG research notes that 44% of NHI tokens are exposed in the wild and 60% of NHIs are overused, which shows why vaulting and runtime access control must be designed as complementary controls, not substitutes. For a deeper treatment of the identity side of that problem, see Ultimate Guide to NHIs — What are Non-Human Identities and the 52 NHI Breaches Analysis.
Where teams work with agents, ephemeral tool use, or highly dynamic workloads, the gap gets wider because static vault access does not express intent-based authorisation. The practical answer is to keep vaulting for secret protection, then add runtime checks for every meaningful request so a retrieved secret is still subject to policy before it is used.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret sprawl and overused credentials tied to vaulting limits. |
| NIST CSF 2.0 | PR.AC-4 | Runtime access control maps to least-privilege authorization decisions. |
| NIST AI RMF | Helpful where autonomous systems need context-aware authorization. |
Reduce shared secrets and enforce rotation, isolation, and usage controls for each NHI.
Related resources from NHI Mgmt Group
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between JIT access and Zero Trust for NHIs?
- What is the difference between compliance evidence and runtime access control?
- What is the difference between code review and access review in AI-generated software?
