Credentials Vault

Expanded Definition

A credentials vault is the control layer for sensitive machine credentials, not merely a repository. It governs issuance, retrieval, rotation, recovery, and revocation for secrets used by NHIs, Agents, and service accounts, with policy deciding when access is allowed and when it must be denied.

In practice, a vault differs from a password manager because it supports automated workflows, short-lived access, and machine-to-machine trust decisions. The modern NHI model increasingly pairs vaulting with OWASP Non-Human Identity Top 10 guidance and the assurance concepts found in NIST SP 800-63 Digital Identity Guidelines, but usage in the industry is still evolving and no single standard governs vault architecture yet.

That matters because a vault can be secure while still being operationally weak if it cannot enforce JIT issuance, record retrieval events, or support recovery without creating standing privilege. The most common misapplication is treating the vault as a passive secret store, which occurs when teams sync long-lived credentials into applications without policy, rotation, or recovery controls.

Examples and Use Cases

Implementing a credentials vault rigorously often introduces access-friction and dependency on automation, requiring organisations to weigh faster delivery against tighter secret governance.

• CI/CD pipelines retrieve build tokens on demand instead of embedding them in repository variables, reducing the chance of leakage during the release process. This pattern is central to the risks explored in NHIMG coverage of the CI/CD pipeline exploitation case study.
• Production database accounts are issued as time-bound credentials and rotated after use, which aligns with guidance from the OWASP Non-Human Identity Top 10 and limits lateral movement if one workload is compromised.
• Cloud service principals are recovered through controlled break-glass workflows when an incident disables automated access, then immediately reissued with narrowed scope. NHIMG analysis of the Guide to the Secret Sprawl Challenge shows why duplicated credentials make this step harder than it should be.
• Agentic systems fetch API keys just before tool execution, then discard them after the task completes, which supports ZSP-style operations and reduces exposure if the Agent is compromised.

In mature environments, the vault becomes the enforcement point for secret lifecycle policy across development, staging, and production.

Why It Matters in NHI Security

A vault becomes strategically important when secret sprawl, stale access, or misconfigured onboarding starts to outpace human review. NHIMG research from The 2025 State of NHIs and Secrets in Cybersecurity found that 62% of all secrets are duplicated and stored in multiple locations, a sign that many vault programmes are trying to clean up after exposure rather than prevent it.

That duplication raises the odds of shadow copies, inconsistent rotation, and recovery gaps. It also undermines incident response, because a compromised token in one system may still be active in another. The problem is visible in attack patterns documented by NHIMG reporting on the Guide to the Secret Sprawl Challenge and in breach narratives such as the MongoBleed breach, where exposed secrets quickly become operational access. After exposure, the vault is often the only place capable of proving what was issued, what was rotated, and what still needs revocation. Organisations typically encounter the true importance of a credentials vault only after a secret leak or service compromise, at which point controlled recovery becomes operationally unavoidable.

Related resources from NHI Mgmt Group

• How should security teams evaluate a credentials vault for recovery use cases?
• What breaks when a credentials vault is treated as a commodity?
• What is the difference between static and dynamic credentials?
• Why is hardcoding credentials into source code so dangerous?