What Is Key Vault? Definition & Examples

A key vault is a secure service for storing and controlling access to secrets such as API keys, passwords, certificates, and encryption keys. In identity and security programs, it enforces policy-based retrieval, rotation, auditing, and least-privilege access, reducing secret sprawl and limiting exposure across applications, cloud workloads, and automation.

What a key vault actually does

A key vault is not just a storage bucket for secrets. It is a control point that mediates who can retrieve, use, rotate, and audit sensitive material, so applications and automation do not need to embed long-lived secrets directly in code or configuration.

That mediation matters because the vault becomes part of the trust boundary. The value is not only confidentiality, but also policy enforcement, traceability, and consistent handling of credentials and encryption material across cloud services, workloads, and deployment pipelines.

Secrets, keys, and certificates in one governed place

Key vaults usually handle multiple secret types together, including passwords, API keys, tokens, certificates, and encryption keys. That consolidation reduces secret sprawl, but it also means the vault becomes a high-value target and must be treated as a critical security dependency rather than a convenience feature.

Practically, the vault is most useful when teams need one place to govern retrieval rules, expiry, renewal, and ownership across heterogeneous systems. The main design goal is to keep sensitive material out of source code, images, build logs, and deployment manifests while still letting workloads access what they need at runtime.

How access control changes the security model

The security benefit of a vault depends on access control being explicit and narrow. Policy-based retrieval means the vault decides which identity, workload, or automation path can read a secret, under what conditions, and sometimes for how long. That shifts control away from scattered local copies and into a centrally enforced policy layer.

This is why a vault is often paired with least privilege, short-lived access, and strong auditing. If the vault is over-permissive, it can become a single point from which many downstream systems inherit excessive access, especially when role assignment and secret distribution are loosely governed.

For teams comparing implementation approaches, Secrets Management Buyer’s Guide is useful when evaluating how different secret stores handle policy, rotation, and operational trade-offs.

Operational patterns that make vaults effective

Vaults work best when they support rotation, expiration, and discovery workflows instead of serving as static storage. Rotation only helps if dependent applications can refresh secrets without service disruption, and if ownership is clear enough that stale credentials are retired on schedule.

They also need integration discipline. If many teams duplicate secrets into local systems because access is inconvenient, the vault loses its value and secret exposure increases again. The governance challenge is therefore not only technical integration, but also maintaining a single source of truth for sensitive material lifecycle.

For teams managing lifecycle at scale, NHI Lifecycle Management Guide provides a broader view of provisioning, rotation, and offboarding patterns that apply to vault-backed credentials.

When the problem is specifically secret sprawl, Guide to the Secret Sprawl Challenge shows why scattered credentials become difficult to govern and why rotation alone is not enough.

Risk and Threat Considerations

Key vaults reduce exposure, but they also concentrate trust. If an attacker gains privileged access to the vault, misuses a highly privileged role, or abuses an overly broad access policy, they may be able to retrieve many secrets at once and move laterally across connected systems.

Failure mechanism: Weak role design, policy escalation, exposed management interfaces, or leaked vault access tokens can turn the vault into a mass secret-exfiltration point. In cloud environments, the risk is especially sharp when a single role can both alter access policy and read stored secrets.

Impact: Compromise can expose passwords, API keys, certificates, signing material, and encryption keys, which then enables persistence, service impersonation, data access, or further privilege escalation across workloads and applications.

A concrete example of this pattern is documented in Azure Key Vault Contributor escalation 2024, which illustrates how a control-plane role can become a secret-access path.

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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-57, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	Key vault access depends on controlled account assignment and revocation.
	IA-5 — Authenticator Management	Vaults store and rotate secret material used as authenticators and credentials.
	AU-2 — Audit Events	Vault operations require auditable retrieval, change, and admin events.
Recommendation — Restrict vault access to approved accounts and remove access promptly when roles change. Manage secret lifecycle in the vault and rotate authenticators before they age or leak. Log secret access and administrative actions so retrieval and policy changes are reviewable.
NIST SP 800-57	Key Management	A key vault materially supports cryptographic key lifecycle management.
Recommendation — Use defined key lifecycle rules for generation, protection, rotation, and destruction.
CIS Controls v8	5 — Account Management	Vaults reduce secret exposure by managing accounts and credentials centrally.
Recommendation — Centralize credential handling and remove stale accounts that can reach vault-stored secrets.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Key vaults are used to reduce leakage of secrets and credential material.
	NHI-05 — Overprivileged NHI	Vault access failures often come from excessive permissions on non-human identities.
	NHI-07 — Long-Lived Secrets	Vaults are commonly used to rotate and shorten secret lifetimes.
Recommendation — Store secret material in a vault and eliminate hardcoded or embedded copies. Minimize vault permissions for workloads and automation identities that retrieve secrets. Replace long-lived secrets with shorter-lived values and enforce rotation through the vault.
NIST CSF 2.0	PR.AA-05 — Authenticator Management	Vaults support secure management of authenticators and secret material.
	PR.DS-01 — Data-at-Rest is Protected	Vaults protect stored secret and key material at rest.
Recommendation — Apply secure authenticator handling and rotation for secrets managed through the vault. Protect stored keys and secrets with strong at-rest controls and controlled retrieval.

Practitioner Guidance

Governance implication: Treat the vault as privileged infrastructure, not merely a secrets repository. Ownership should cover who can administer it, who can retrieve from it, and who is accountable for rotation, revocation, and audit review.

What to watch for: Long-lived secrets, broad retrieval permissions, shared vaults with weak separation, and teams bypassing the vault by copying secrets into local environments are early signs that the design is drifting back toward secret sprawl.

Practitioner takeaway: A key vault only improves security when retrieval, rotation, and auditing are enforced consistently enough that applications do not quietly reintroduce unmanaged secret copies.

Key Vault