Something usually prompts this question, and in our experience it is rarely that Vault stopped working. It is a renewal that came back higher than expected, a licence clause someone in legal flagged, or a product tier that went away underneath a team that was happily using it.
We deploy privileged access and secrets platforms for a living. Applied IAM is a Keeper partner and a CyberArk partner, so read the Keeper section knowing where we sit. We are not a HashiCorp partner, not an OpenBao contributor, and we have nothing to sell you if the answer is that your current setup is fine.
The short version: most of what is driving teams to look has more to do with ownership and licensing than with the software itself — and a good share of the teams asking do not need a secrets management platform at all.
Why people are looking in 2026
Four things changed, and only one of them is technical.
The licence changed. In August 2023 HashiCorp moved Vault from the Mozilla Public License 2.0 to the Business Source License 1.1 (HashiCorp's announcement). The code stays readable, but BSL restricts competitive use — which in practice means you cannot embed Vault inside a product you sell. If you are a software vendor or a managed service provider, that single clause is the whole conversation.
IBM bought it. IBM closed its acquisition of HashiCorp on 27 February 2025 for $6.4 billion (IBM's announcement). HashiCorp's business operations formally moved across in September 2025 and the products were renamed into IBM's automation portfolio. IBM has been clear that nothing in the software changed at the rename. What changed is whose roadmap Vault now sits on.
A product went away. HCP Vault Secrets, the SaaS-only tier, was sunset — end of sale in mid-2025 and end of life in 2026 — and the HCP Vault Dedicated Starter tier was discontinued. Teams on those are being pushed toward Dedicated, Enterprise, or self-hosting Community Edition. Every one of those options is more expensive or more work than what they had.
There is now a credible fork. The Linux Foundation announced OpenBao in December 2023, forked from Vault 1.14 — the last release under the permissive licence. It is no longer a protest project. More on it below.
Notice that none of those are "Vault stopped working." If you are running Community Edition on your own hardware and nobody has sent you a renewal, your day has not changed.
First, check you have the problem Vault solves
This is the part the vendor comparisons skip, and it is where we disagree with most of what is written on this subject.
Vault is built for machine secrets: an application, a pipeline or a container asking for a credential at runtime. Its best feature is dynamic secrets — instead of storing a database password, Vault creates a fresh one when the app asks, with a short lease, and revokes it when the lease ends. Add the PKI engine for issuing certificates, and encryption as a service through the transit engine. That is a genuinely deep toolkit for engineering teams.
What Vault does not do is human privileged access. No session recording when an administrator logs into a domain controller. No approval workflow an auditor recognises. No discovery of the privileged accounts already scattered across your estate.
So before you shortlist a replacement, work out which problem you actually have:
- "Our API keys are in a Git repository and our pipeline has a hard-coded database password." That is the secrets problem. Vault or one of its alternatives is the right category.
- "Four people share the domain admin password and we cannot prove who used it." That is privileged access management, a different category, and no amount of Vault will close it.
- "Nobody knows what our service accounts do or who owns them." That is non-human identity management, which starts with discovery, not with a vault.
We see the second and third cases arrive holding a Vault evaluation surprisingly often, because Vault is the famous name. Picking the wrong category is far more expensive than picking the wrong product inside the right one.
OpenBao: the like-for-like move
If you want what you already have, minus the licensing question, this is the answer.
OpenBao is a community fork of Vault under Linux Foundation stewardship, with an API and CLI compatible with the codebase it forked from. The operational experience is close to identical — same seal and unseal model, same policy engine, same dynamic secrets and PKI concepts. It carries an OSI-approved open-source licence with no restriction on commercial use.
It has also stopped being only a maintenance fork. Namespaces, which Vault keeps behind Enterprise, ship free in OpenBao. IBM engineers are among the project's contributors, which is a genuinely strange detail given IBM now owns the thing it was forked from.
Where it fits: teams on Vault Community Edition self-hosted. You are doing the operational work already; OpenBao is the same work under clean licence terms.
The honest limit: at the top end, Vault Enterprise still has capabilities the fork has not matched, disaster-recovery replication among them. If you are a large Vault Enterprise customer, the gap is real and the migration is a project. Negotiating your renewal is a legitimate strategy, and evaluating OpenBao in parallel is what gives that negotiation any leverage.
Keeper Secrets Manager
Disclosure again: we license and deliver Keeper, so weigh this accordingly.
Keeper Secrets Manager is a fully managed, cloud-hosted secrets manager on the same zero-knowledge vault as the rest of the Keeper platform. Secrets are encrypted on your device before they reach Keeper, and Keeper holds no key that can decrypt them. It covers storage, role-based access, sharing, audit logging and automated rotation for SSH keys, service accounts, API tokens and database passwords, with no vault infrastructure to stand up.
Where it genuinely fits: teams whose secrets problem sits next to a human credential problem. If you need somewhere for pipeline secrets to live and you need privileged session control and service account management for people, Keeper covers both on one vault and one console. That is a materially different shape from running Vault for machines and something else for humans. It also suits organisations where the compliance posture matters more than the feature depth — Keeper holds FedRAMP and GovRAMP authorisation, which for federal and defence-adjacent work is often the shortlist filter.
The honest limits, briefly: Keeper has no dynamic secrets engine, no PKI engine and no transit encryption service. It is SaaS, so self-hosting is not an option. If your architecture depends on short-lived generated credentials or on issuing your own certificates, Keeper does not replace Vault and we would not pretend otherwise.
Teleport and StrongDM
Both come at this from infrastructure access rather than from vaulting. Certificate-based, short-lived, protocol-aware, and genuinely pleasant for engineers to use. Neither is a secrets manager, and both get compared to one because they solve the adjacent problem of engineers reaching Kubernetes clusters, databases and Linux hosts without a stored credential.
If that is the whole of your problem, either will be adopted more willingly than a traditional vault. What they do not cover is everything else: Windows administrative access, application credentials, the Oracle estate, network devices, and the third parties who need occasional access. Most organisations have a privileged access problem considerably wider than their cloud infrastructure.
Worth being direct: Teleport and StrongDM sit alongside a secrets platform more often than they replace one. Treating them as a Vault replacement usually means the machine-secrets problem quietly stays unsolved.
The cloud services you may already own
AWS Secrets Manager, Azure Key Vault and Google Secret Manager are the alternatives most teams overlook because they are boring and already on the bill.
If your workloads live in one cloud, the native service is the lowest-effort option in this list by a wide margin: no infrastructure, IAM integration that already works, rotation built in. The trade is lock-in and a thin experience outside that cloud's boundary. If you are genuinely multi-cloud, you end up with three consoles and three audit trails, which is the sprawl you were trying to fix.
Our rule of thumb: one cloud and no on-premises estate, start with the native service and only move when you can name the thing it cannot do. Two or more clouds, or a real on-premises footprint, and a platform-agnostic tool earns its cost.
CyberArk Conjur, and the wider PAM options
If you already run an enterprise privileged access platform, check what you are entitled to before buying anything. Conjur occupies broadly the same machine-secrets territory as Vault, and organisations running CyberArk sometimes already have the licence. The same logic applies across the wider PAM market — the cheapest secrets platform is frequently a module of something you are already paying for and running at a fraction of its scope.
How the options compare
| Option | Best fit | Dynamic secrets | Human privileged access | Self-host | Operational effort |
|---|---|---|---|---|---|
| HashiCorp Vault | Engineering-led orgs, complex estates | Deep | No | Yes | High |
| OpenBao | Vault Community users wanting clean licensing | Deep | No | Yes | High |
| Keeper Secrets Manager | Secrets plus a human credential problem | No | Yes, on the same vault | No | Low |
| AWS / Azure / GCP native | Single-cloud workloads | Partial | No | No | Low |
| Teleport / StrongDM | Engineers reaching infrastructure | Not applicable | Infrastructure only | Yes | Low to moderate |
| CyberArk Conjur | Estates already running CyberArk | Yes | Via the wider platform | Yes | Moderate to high |
The column that decides most of these evaluations is the last one, and it is the column vendors discuss least.
What a migration actually costs
Nobody publishes this, so here is the shape of it from the delivery side.
The secrets themselves are the easy part. Exporting key-value data and importing it elsewhere is a scripting job. What takes the time is everything wrapped around them:
- Every consumer has to be repointed. Each application, pipeline and container that reads a secret has to be changed and tested. This is the bulk of the work and it is spread across teams that do not report to you.
- Auth methods have to be rebuilt. Kubernetes service account binding, cloud IAM roles, AppRole — these are configuration, not data, and they do not export.
- Dynamic secrets do not port to a platform that lacks them. If you are moving somewhere without a dynamic secrets engine, every dynamic credential becomes a static one on a rotation schedule. That is a security posture change, not a migration task, and it needs a decision rather than a default.
- You run both for a while. Plan for a period with two platforms live, which means two sets of policy to keep in step.
The teams that get hurt are the ones that treat this as a data move. Budget it as an application change programme with a secrets export attached, and it goes fine.
How to decide
Four questions, in order.
Do you need dynamic secrets, PKI or encryption as a service? If yes, your realistic list is Vault, OpenBao, or Conjur if you already own CyberArk. Everything else in this article is a downgrade on that axis, and you should not let a lower price talk you out of a control you genuinely rely on.
Is licensing or ownership the actual driver? If the product is fine and the concern is BSL or IBM, OpenBao is the shortest path and the migration is the least disruptive one available.
Is your problem partly about people? If humans sharing privileged credentials is in scope, a converged platform is worth more to a small team than a best-in-class machine-secrets tool plus a separate one for humans. Two platforms means two policy models and two audits.
Who runs it in eighteen months? Vault and OpenBao both need someone who understands seals, policies, auth methods and upgrades. If that person does not exist and is not being hired, a managed platform is the honest answer regardless of which one wins on features. We have seen more secrets platforms fail on operating capacity than on capability — the same pattern that decides whether a rollout lands at all.
If those four do not point clearly one way, the difference will be settled by your implementation rather than your licence, and you should choose on commercial terms and spend the energy on the rollout.
Where we come into it
We implement and operate privileged access and secrets platforms, including Keeper deployments and broader PAM programmes, and we place engineers into client teams where the gap is capacity rather than expertise.
If you are mid-evaluation and want a read from someone who is not selling you the migration, a scoping conversation is free. If you are earlier than that and still working out whether your problem is machines or people, start here instead.
