What is a secrets vault and which tools are available?

Why This Matters for Security Teams

A secrets vault is not just a storage bucket for passwords. It is the control point for how machine identities receive, use, and rotate secrets across cloud, CI/CD, SaaS, and internal workloads. When teams leave secrets in code, tickets, or chat tools, they create long-lived exposure that vaults are meant to reduce. NHIMG research shows Guide to the Secret Sprawl Challenge is still highly relevant because secret sprawl usually starts with convenience, then becomes a systemic risk.

This matters because secrets are often the practical proof behind NHI access. If the secret is duplicated, over-shared, or never rotated, the identity behind it is effectively over-privileged. Current guidance from the OWASP Non-Human Identity Top 10 treats secret hygiene as a core NHI control problem, not a side task for operations. NHIMG’s 2025 research found that 62% of all secrets are duplicated and stored in multiple locations, which is a clear sign that centralisation alone is not enough without governance, approval, and lifecycle discipline.

In practice, many security teams encounter vault risk only after a leaked token has already been reused in automation and lateral movement has begun.

How It Works in Practice

A secrets vault centralises credential storage, but its real value comes from how it issues access. The better tools do three things well: they restrict who or what can read a secret, they generate short-lived credentials on demand, and they log every retrieval, renewal, and rotation event. In mature setups, applications do not hardcode database passwords or API keys. Instead, they authenticate to the vault using workload identity, then receive an ephemeral secret with a narrow scope and a short time-to-live.

This is where the distinction between static and dynamic secrets matters. Static secrets can be easier to integrate, but they raise blast radius and operational overhead. Dynamic secrets, described further in Ultimate Guide to NHIs — Static vs Dynamic Secrets, are preferable when a system can mint credentials per task or per session. That approach aligns with the least-privilege direction in OWASP Non-Human Identity Top 10 and reduces the impact of token theft, which is a recurring theme in NHIMG breach analysis such as the Reviewdog GitHub Action supply chain attack.

• Use centralised encrypted storage for API keys, certificates, database credentials, and signing material.
• Prefer dynamic secrets and automatic rotation where systems support it.
• Bind access to workload identity and RBAC, then add tighter policy where supported.
• Enable full audit trails so every retrieval can be investigated.
• Integrate with CI/CD, cloud services, and automation platforms rather than copying secrets into scripts.

Leading products in this category include HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager, and Akeyless, but the control design matters more than the brand. These controls tend to break down when legacy applications cannot renew secrets safely because static credentials are still embedded in long-running jobs and shared service accounts.

Common Variations and Edge Cases

Tighter secret controls often increase integration effort, requiring organisations to balance operational simplicity against shorter credential lifetimes and more frequent renewal logic. That tradeoff is especially visible in hybrid estates, where some platforms can support dynamic issuance and others still depend on static configuration files or environment variables.

There is no universal standard for vault design across all environments. Some teams use a vault as the single source of truth for every secret, while others reserve it for high-value credentials and use cloud-native secret managers for platform-specific workloads. The important question is whether the tool enforces ownership, rotation, and auditability, not whether it fits a particular product category. NHIMG’s findings on duplicate storage and unused approvals in secret handling show why governance matters as much as storage, and the broader risk pattern is echoed in the 52 NHI Breaches Analysis.

Edge cases also include certificates, signing keys, and machine-to-machine tokens that expire too slowly to be useful or too quickly to support reliable automation. Best practice is evolving here: some environments now pair vaults with policy engines and just-in-time issuance, while others still rely on periodic rotation and human review. The right model depends on whether the workload is batch, interactive, multi-cloud, or highly autonomous, because highly distributed pipelines are where secret vault assumptions fail fastest.

Related resources from NHI Mgmt Group

• What is secrets sprawl and why does it create security risk?
• How do I find hardcoded secrets in my codebase?
• How do I implement secrets scanning in a CI/CD pipeline?