Vault 2.x under IBM: new version numbers, new support rules.
We design, run and upgrade HashiCorp Vault clusters, Community or Enterprise. In April 2026 Vault went from 1.21 to 2.0 on IBM's support model, so most upgrade plans need a fresh look.
At least two years of standard support per major release
release watch
Vault 2.0 generally available14 Apr 2026
Vault 2.1.001 Sep 2026
connects with
in short·15-second read
Cohash designs, operates and upgrades HashiCorp Vault, now an IBM product.
We build auth methods, dynamic secrets, PKI and secrets sync, and we automate the configuration with Terraform. Vault 2.0 reached general availability on 14 April 2026 and follows IBM's support cycle, with at least two years of standard support per major release. Vault 2.2.0 shipped on 15 October 2026.
you probably need this if
Vault still runs 1.x and nobody has planned the move to 2.x under IBM's support cycle.
Applications read the same static database password from Vault that they've used for years.
Pipelines authenticate to Vault with long-lived tokens that somebody pasted into CI variables.
14 Apr 2026Vault 2.0 generally available Version jumped from 1.21 to follow IBM's model. IBM Support Cycle-2 gives at least two years of standard support per major release. Adds SCIM 2.0 provisioning and workload identity federation for secret sync. source ↗
01 Sep 2026Vault 2.1.0 Agentic IAM is generally available with no activation flag. source ↗
15 Oct 2026Vault 2.2.0 New here: a TPM auth method, ML-DSA PKI certificates, Secrets Sync for database secrets and a public beta of Vault Client. Separately, security-only 2.1.2 came out on 7 October. source ↗
today · Oct 22, 2026
the story · hashicorp vault estate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your HashiCorp Vault estate, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · hashicorp vault estate3 open
openVault still runs 1.x and nobody has planned the move to 2.x under IBM's support cycle.
recurringApplications read the same static database password from Vault that they've used for years.
blockedPipelines authenticate to Vault with long-lived tokens that somebody pasted into CI variables.
exposure
Cluster design and buildUpgrades to Vault 2.xAuth methods and policiesDynamic secrets and PKIAgents and workload identityCommunity, Enterprise or OpenBao
startrehearsehandover
Cluster review
Upgrade path to 2.x
Auth and secrets redesign
PKI and automation
Handover
we are here
ready to hand over
The cluster runs a supported 2.x release on integrated storage, and CI holds no…
Certificates renew on their own, and short lifetimes are the default.
Upgrade plan for each hop to 2.x, with breaking changes and plugin test results
Auth methods and policies in Terraform, reviewed through pull requests
chapter 01 · where it hurts
Why teams reach out
Vault still runs 1.x and nobody has planned the move to 2.x under IBM's support cycle.
Applications read the same static database password from Vault that they've used for years.
Pipelines authenticate to Vault with long-lived tokens that somebody pasted into CI variables.
chapter 02 · what we change
How we solve it
Cluster design and build
Upgrades to Vault 2.x
Auth methods and policies
Dynamic secrets and PKI
Agents and workload identity
Community, Enterprise or OpenBao
chapter 03 · how it runs
Our approach
Cluster review
Upgrade path to 2.x
Auth and secrets redesign
PKI and automation
Handover
chapter 04 · where you end up
What changes
The cluster runs a supported 2.x release on integrated storage, and CI holds no long-lived tokens.
Certificates renew on their own, and short lifetimes are the default.
Upgrade plan for each hop to 2.x, with breaking changes and plugin test results
Auth methods and policies in Terraform, reviewed through pull requests
what we do
Our HashiCorp Vault work
6 kinds of HashiCorp Vault work, each run by engineers who have done it on live tenants.
Integrated storage clusters, auto-unseal with a cloud KMS or HSM, performance and DR replication where licensed, and audit devices on from the first day.
Release notes and breaking changes reviewed for each hop, plugins tested, and the upgrade rehearsed against a snapshot of production.
Kubernetes, cloud IAM, JWT/OIDC and AppRole auth set up so workloads stop using static tokens. Policies kept in Terraform and reviewed like code.
Database, cloud and LDAP secrets engines issuing short-lived credentials, and PKI issuing certificates with short lifetimes and automated renewal.
Vault's agentic IAM features and SPIFFE JWT-SVIDs set up for AI agents and workloads that need short-lived, narrowly scoped credentials.
A review of the features you actually use, what the Business Source License means for you, and whether Enterprise, HCP Vault Dedicated or the OpenBao fork fits.
capability 01 / 06in production
Cluster design and build
Integrated storage clusters, auto-unseal with a cloud KMS or HSM, performance and DR replication where licensed, and audit devices on from the first day.
A review of the features you actually use, what the Business Source License means for you, and whether Enterprise, HCP Vault Dedicated or the OpenBao fork fits.
We pieced these together from HashiCorp Vault situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Vault 1.15 on Consul storage with root-derived tokens in CI
composite · not a client story
Beforethe situation
A self-managed cluster runs Vault 1.15 on Consul storage. CI pipelines authenticate with long-lived tokens, a few created from root, and the team needs to reach 2.x without losing a weekend.
What we dothe work
We migrate storage to integrated Raft storage on a rehearsal cluster first, then plan each upgrade hop with its breaking changes read and plugins tested. CI moves to JWT/OIDC auth from the pipeline provider so tokens are issued per job. The old tokens are revoked from a dated list.
Afterwhere you end up
The cluster runs a supported 2.x release on integrated storage, and CI holds no long-lived tokens. Next time round, the upgrade steps are already written down.
case file 02
Internal certificates issued by ticket from a Windows CA
composite · not a client story
Beforethe situation
Internal TLS certificates come from a Windows CA through tickets and last thirteen months. Expired certificates cause outages a few times a year, and security wants shorter lifetimes without more tickets.
What we dothe work
We stand up a PKI secrets engine as an intermediate under the existing root and set roles per service domain. Renewal runs through Vault Agent, or cert-manager in Kubernetes. Lifetimes come down in steps once renewal is proven on a pilot group.
Afterwhere you end up
Certificates renew on their own, and short lifetimes are the default. Nobody's calendar reminder decides whether there's an expiry outage.
We don't start a step until the last one has produced something you can check.
step 01
Cluster review
We check version, storage backend, unseal method, replication, audit devices, auth methods and policies, and how much of the configuration lives in Terraform.
step 02
Upgrade path to 2.x
Release notes and breaking changes read for each hop, plugins tested, and the upgrade rehearsed against a snapshot of production, with standby nodes upgraded before the active node.
step 03
Auth and secrets redesign
Static tokens give way to Kubernetes, cloud IAM, JWT/OIDC or AppRole auth. Then we move static secrets to dynamic database or cloud credentials, one application at a time.
step 04
PKI and automation
A PKI secrets engine under an intermediate CA, issuing certificates with short lifetimes. Vault Agent or cert-manager handles renewal so nobody has to, and the policies are managed in Terraform.
step 05
Handover
Runbooks for unseal, snapshots, DR promotion and upgrades, plus alerts on lease counts and audit device health.
ai on hashicorp vault
Where AI fits on HashiCorp Vault, and where it needs guardrails.
Vault 2.1.0 made Agentic IAM GA in September 2026 as an Enterprise feature. Agents can get short-lived credentials scoped to one task in place of static secrets. There's also a Vault MCP server in beta from HashiCorp. For us that one needs tight policies and trusted clients, since it can expose secrets to the model.
AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
HashiCorp Vaultdoes the work
HashiCorp publishes an official Vault MCP server in beta. We'd run it only with trusted MCP clients and models, under a Vault token or auth role with a narrow policy and a short TTL. Enable audit devices. Secret writes and PKI issuance stay behind human approval.
Agentic IAM in Vault 2.1
It went GA in 2.1.0, Enterprise only, and there's no activation flag to set. We design auth roles and policies so an agent's credentials cover one task. TTLs stay short. Each agent's owner is recorded in metadata.
Workload identity for agents
With SPIFFE JWT-SVIDs and workload identity federation, agents and services prove who they are without holding a stored token. For us the work is setting that up on each platform where your agents run.
Vault MCP server (beta)
With the beta server you can create and list KV mounts and read and write secrets. You can issue PKI certificates too. HashiCorp discourages beta use in production and warns it may expose secrets to clients and models. For us that means dev namespaces with read policies, if we used it at all.
AI help with policy reviews
Point an AI assistant at your HCL policies and it'll look for wildcard paths and capabilities broader than they need to be. An engineer confirms each finding. Policy changes go through Terraform.
Each workload proves who it is through an auth method. Vault's policies then decide which secrets engines it can use. Those engines issue database credentials, certificates and cloud credentials that expire by themselves, so nothing long-lived sits in code or CI variables.
These are working documents, written against your configuration, so your team can run them without us.
tests01
Upgrade plan for each hop to 2.x, with breaking changes and plugin test results
yours to keep
code02
Auth methods and policies in Terraform, reviewed through pull requests
yours to keep
inventory03
Static-token inventory with a replacement auth method per workload
yours to keep
design04
PKI hierarchy design with certificate lifetimes and renewal automation
yours to keep
tests05
DR replication and snapshot restore test, timed and written up
yours to keep
document06
Comparison of the editions you could run: Community, Enterprise, HCP Vault Dedicated or OpenBao
yours to keep
talent and delivery · hashicorp vault
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your HashiCorp Vault work. The ones who've done it answer differently from the ones who've read about it.
Q1
What breaks in our configuration on the way from 1.x to 2.x?
Vault 2.0 dropped some legacy behavior, such as Azure auth now needing explicit configuration. Check each hop's breaking changes against your auth methods, secrets engines and plugins before a date goes in the calendar.
Q2
How many static tokens do our workloads use today, and what replaces each one?
Static tokens are the usual Vault weakness. Kubernetes, cloud IAM or JWT auth can replace each one, once someone has found every workload that reads it.
Q3
Which Enterprise-only features do we use, and do we need them?
Namespaces, replication and Agentic IAM are Enterprise features. Use none of them and Community or OpenBao may be plenty. Use any, and the choice is Enterprise or HCP Vault Dedicated.
Q4
What does the Business Source License mean for the way we use Vault?
Vault moved to BSL 1.1 in 2023. Internal use is generally fine, but embedding Vault in a product you sell needs legal review, which is usually when OpenBao comes up.
Q5
Will you actually run a DR failover and a snapshot restore for us, or only configure them?
A snapshot nobody has restored is a file you hope works. Time a failover and a restore once, and you know how long recovery takes.
01Why did Vault jump from 1.21 to 2.0?
After the acquisition, HashiCorp put Vault on IBM's versioning and support model. Vault 2.0 went GA on 14 April 2026. IBM Support Cycle-2 gives major releases at least two years of standard support. Some legacy behavior was removed, so read the breaking changes before you upgrade.
02Is Vault still open source?
No. In 2023 Vault switched from the Mozilla Public License to the Business Source License. Community Edition stays free to use under it. After the change, the community forked it as OpenBao, and some teams went that way.
03What does an upgrade to Vault 2.x involve?
It depends where you're starting from, meaning version, storage backend and plugins. We read every release's breaking changes (Azure auth now needing explicit configuration, for example). Then we test plugins, take a snapshot and upgrade the standby nodes before the active one.
04Can Vault sit alongside CyberArk or Delinea?
Yes. A lot of companies keep Vault for application and pipeline secrets and use a PAM tool for human admin access. We help set the boundary, and connect the two where that helps.
05Should we use HCP Vault Dedicated instead of running our own clusters?
It depends on your hosting rules, which features you need and who's going to run the clusters. HCP Vault Dedicated takes server upkeep off your hands. Self-managed clusters suit strict network or data residency requirements. We compare the options against what you use and spend today.
services
Related services
Projects on HashiCorp Vault usually end up touching one of these, so they're worth a look.
