HashiCorp Vault.

At a glance

What Vault does (in NHI terms)

Vault's core value to NHI governance is its ability to issue short-lived credentials on demand. Instead of handing a workload a long-lived API key, the condition implicated in most breaches in the breach library, Vault issues a narrowly scoped, short-TTL credential at the moment of use. Done well, this collapses the attack surface for credential theft dramatically.

The NHI-relevant capability surface includes:

• Dynamic secrets. Database credentials, cloud IAM credentials, SSH credentials issued on demand with short TTLs and automatic revocation.
• Static secrets storage. KV store for secrets that can't yet be made dynamic.
• PKI engine. Internal certificate authority issuing short-lived X.509 certs for service-to-service authentication.
• Transit encryption. Encryption as a service for workloads that need it without handling key material directly.
• Auth methods. Kubernetes, AWS IAM, JWT/OIDC, AppRole, workloads present their identity and receive a Vault token, then retrieve secrets.

What Vault is not

• Vault is not an NHI discovery tool. It stores and governs the secrets your programme already knows about.
• Vault is not a posture-analysis platform. It enforces policy at retrieval time, not posture across an estate.
• Vault is not a SaaS OAuth-token inventory. That's a different surface.
• Vault is not a CMDB. Ownership and accountability for NHIs live in your IAM and governance layer.

The IBM transaction and what it signals

HashiCorp's acquisition by IBM was not a secrets-management play specifically, IBM was buying the full HashiCorp portfolio, Terraform foremost among them. For Vault users, the practical consequences to date have been modest: roadmap continuity, enterprise pricing that moved within normal bounds, and no meaningful product-line disruption. Whether IBM's longer-term direction pulls Vault deeper into a Red Hat / IBM Cloud integration story is the open question.

The BSL licence change (2023) remains the most consequential commercial change, it prompted the OpenBao fork, which is now a CNCF-adjacent alternative for organisations with licensing constraints.

Differentiators

• Cloud-native fluency. Vault is the default choice in most Kubernetes-heavy and multi-cloud environments, and the integration ecosystem reflects it.
• Dynamic secrets depth. The breadth of dynamic secrets backends is the capability least matched by any alternative.
• PKI as infrastructure. Internal CA functionality is first-class, not an afterthought.

Practical notes

• Operational complexity is real. A production-grade Vault deployment (HA, unsealing, audit logging, secret engines) is a project. This is not a weekend install.
• Vault + an NHI governance platform is a common pattern: Vault provides the vault, the NHI platform provides ownership, posture, and lifecycle around what Vault holds.
• For small environments, cloud-native secrets managers (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) are often simpler to start with; Vault's value grows with scale and cross-cloud complexity.

When Vault makes sense

Vault is the right default when:

• You're in a cloud-native, Kubernetes-heavy environment and want short-TTL credentials everywhere.
• You have cross-cloud or hybrid workloads and need a single secrets primitive.
• You need internal PKI and dynamic secrets under one roof.

Not the right choice as the only tool when:

• You need NHI discovery, posture, and lifecycle workflow, that's a different category.
• You need simplicity at a single-cloud, small-team scale and won't exercise Vault's depth.

What we don't know

• The long-term shape of Vault inside IBM's portfolio. To date, continuity. Beyond 2027, open.