Start a project
Menu
ServicesAll servicesCybersecurityCloud EngineeringApplication ServicesEnterprise PlatformsData & AnalyticsAI & Machine LearningInternet of ThingsMobilize Talent
PlatformsAll platformsIdentity and accessPrivileged access and secretsERP, HCM and financeCRM, ITSM and automationHealthcareInsurance and bankingData and integrationCloud and AIIndustrial, utilities and mainframeSkills matrix
Case studiesAll case studiesIdentity and accessPrivileged accessSecurity operationsCloud and infrastructureApplicationsERP and HCMCRM, ITSM and automationIndustry platformsData and analyticsAI and agents
IndustriesAll industriesEnergy, oil & gasHealthcare payersBanking & financial servicesInsurancePublic sectorManufacturingLocations
InsightsField notesLearning tracks
CompanyAbout CohashPortfolioSkills matrixCareersTrust and securityContact
Start a project
secrets management

Vault is on 2.x now, under IBM. Most upgrade plans written for 1.x need redoing.

We design, run and upgrade HashiCorp Vault clusters, Community or Enterprise. Vault jumped from 1.21 to 2.0 on IBM's support model, then October brought 2.2, four security bulletins and a root-policy fix. Most upgrade plans written before that need a fresh look.

Talk to a HashiCorp Vault engineerWhat changed recently
platform dossierHashiCorp VaultSecrets management
Vendor
IBM (HashiCorp)
Current release
Vault 2.2.1, 22 Oct 2026
Major version
Vault 2.0 GA 14 Apr 2026, following 1.21
Support horizon
Enterprise 2.x on IBM Support Cycle-2 (2 + 1 + 3 model)
release watch
  • Vault Enterprise 1.19 LTS: extended maintenance endsApr 2027
  • Vault 2.2.1, Enterprise 1.21.13 and 1.19.2422 Oct 2026
connects with
in short·15-second read

Cohash designs, runs and upgrades HashiCorp Vault, now an IBM product.

We build auth methods, dynamic secrets, PKI and secrets sync, and keep the configuration in Terraform. The newest release is Vault 2.2.1, out on 22 October 2026 with a root-policy alias fix. Any 2.x cluster below 2.1.2 is also missing the security fixes from 7 October (three for Community, four for Enterprise).

you probably need this if
  • Vault still runs 1.x and nobody has planned the move to 2.x under IBM's support cycle.
  • Policy rules, deny rules included, reference mixed-case resource names, and nobody has checked them against the October security fixes.
  • Applications read the same static database password from Vault that they've used for years.
terms on this page SYNCdefinitionA Databricks SQL command that registers your external Hive tables in Unity Catalog. It doesn't copy data, so it's quick, but it won't take DBFS root tables.explained in a field note →workload identitydefinitionAn identity for software rather than a person. The Entra provisioning service uses one to prove who it is with a short-lived token, so nobody has to store a password for it.explained in a field note →OpenBaodefinitionVault's open-source twin, kept by the Linux Foundation's OpenSSF on MPL 2.0. Namespaces come free, where Vault charges Enterprise prices for them.explained in a field note →
Ask an engineer facts checked 2026-10-26
how it runs
  1. 01Cluster review
  2. 02Upgrade path to 2.x
  3. 03Auth and secrets redesign
  4. 04PKI and automation
  5. 05Handover
you keep
  • Upgrade plan for each hop to 2.x. It shows what breaks at each step and what happened when we tested your plugins.
  • Auth methods and policies kept in Terraform, so changes go through a pull request like any other code
  • Static-token inventory. Each workload gets a named auth method to replace its token.
+ 3 more documents
who does it
Vault platform engineerVault auth method and secrets engine developerVault PKI engineer Vault Associate (003) Vault Authoring and Operations Advanced
platforms
proof
12 case studies on this
background
VAULT 2.1 Bootstrap secret perhost Azure client secrets Sync from KV v2 RSA and ECDSA CAs VAULT 2.2 TPM-bound machinelogin Azure access tokens Database secretssync ML-DSA certificates
field note · 21 minHashiCorp Vault 2.2 explained: TPM login, post-quantum PKI and the October fixes
hashicorp-vault · release timeline
  1. 14 Apr 2026 Vault 2.0 generally available The version jumped from 1.21 to follow IBM's model, and Vault Enterprise 2.x now sits on IBM Support Cycle-2. The release added SCIM 2.0 provisioning as a beta and workload identity federation for secret sync.
  2. 24 Aug 2026 HCSEC-2026-32: slash injection in templated policy paths Fixed in 2.0.4, and on Enterprise in 1.21.9, 1.20.14 and 1.19.20. The upgrade alone doesn't close it. Someone still has to set deny_slash_in_templated_paths = true on every server and restart each one, because the option defaults to false.
  3. 01 Sep 2026 Vault 2.1.0 Agentic IAM came out of beta as an Enterprise feature. You no longer need an activation flag to turn it on.
  4. 07 Oct 2026 Vault 2.1.2 and four security bulletins HCSEC-2026-40 to -43 are fixed in 2.1.2, and on Enterprise 1.x in 1.21.12, 1.20.17 and 1.19.23. After the HCSEC-2026-43 fix, mixed-case rules stop matching, deny rules included, so rewrite them in lowercase before you upgrade. HCSEC-2026-41 is about plugin entries restored from a Raft snapshot, and catalog entries pointing outside plugin_directory get refused once you've patched.
  5. 15 Oct 2026 Vault 2.2.0 New here: a TPM auth method, ML-DSA PKI certificates, Secrets Sync for database secrets, SCIM out of beta and a public beta of Vault Client. Six of the seven breaking changes only touch SCIM, and the seventh changes AWS credential precedence. Vault Service Broker is listed as removed, with removal expected in October 2026.
  6. 22 Oct 2026 Vault 2.2.1, Enterprise 1.21.13 and 1.19.24 These fix a cache-key collision that could let a policy-name alias resolve to the root policy, and Vault now refuses those aliases wherever a policy gets assigned. HashiCorp doesn't backport fixes across 2.x minor releases, so a cluster on 2.1 picks this one up by moving to 2.2.1.
  7. today · Nov 09, 2026
  8. Apr 2027ahead Vault Enterprise 1.19 LTS: extended maintenance ends Extended maintenance for Enterprise 1.19 ends in April 2027, so 1.19 shops need a 2.x date in next year's plan. The PKI role parameter allow_token_displayname is expected to be removed that month. If a role still sets it to true, switch to allowed-domain settings first.
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.

  1. 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.
    • Policy rules, deny rules included, reference mixed-case resource names, and nobody has checked them against the October security fixes.
    • Applications read the same static database password from Vault that they've used for years.
  2. 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
  3. chapter 03 · how it runs

    Our approach

    • Cluster review
    • Upgrade path to 2.x
    • Auth and secrets redesign
    • PKI and automation
    • Handover
  4. 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. It shows what breaks at each step and what happened when we tested your plugins.
    • Auth methods and policies kept in Terraform, so changes go through a pull request like any other code
what we do

Our HashiCorp Vault work

6 kinds of HashiCorp Vault work, each run by engineers who have done it on live tenants.

  1. 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.

  2. Release notes and breaking changes reviewed for each hop, plugins tested, and the upgrade rehearsed against a snapshot of production.

  3. Kubernetes, cloud IAM, JWT/OIDC and AppRole auth set up so workloads stop using static tokens. Policies kept in Terraform and reviewed like code.

  4. Database, cloud and LDAP secrets engines issuing short-lived credentials, and PKI issuing certificates with short lifetimes and automated renewal.

  5. Vault's agentic IAM features and SPIFFE JWT-SVIDs set up for AI agents and workloads that need short-lived, narrowly scoped credentials.

  6. 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.

talk to an engineer about this →
capability 02 / 06in production

Upgrades to Vault 2.x

Release notes and breaking changes reviewed for each hop, plugins tested, and the upgrade rehearsed against a snapshot of production.

talk to an engineer about this →
capability 03 / 06in production

Auth methods and policies

Kubernetes, cloud IAM, JWT/OIDC and AppRole auth set up so workloads stop using static tokens. Policies kept in Terraform and reviewed like code.

talk to an engineer about this →
capability 04 / 06in production

Dynamic secrets and PKI

Database, cloud and LDAP secrets engines issuing short-lived credentials, and PKI issuing certificates with short lifetimes and automated renewal.

talk to an engineer about this →
capability 05 / 06in production

Agents and workload identity

Vault's agentic IAM features and SPIFFE JWT-SVIDs set up for AI agents and workloads that need short-lived, narrowly scoped credentials.

talk to an engineer about this →
capability 06 / 06in production

Community, Enterprise or OpenBao

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.

talk to an engineer about this →
typical situations

HashiCorp Vault situations we walk into

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 sitting in CI

composite · not a client story
  1. 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.

  2. 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.

  3. 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 still requested by ticket from a Windows CA

composite · not a client story
  1. 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.

  2. 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.

  3. 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.

case studies

HashiCorp Vault case studies

All case studies
modernization Privileged access

Secrets in code, pipelines and config files to HashiCorp Vault

We track down passwords, API keys and tokens in repositories, CI variables and config files and move them into HashiCorp Vault, with short-lived credentials.

read the case study
modernization Cloud and infrastructure

Hand-built cloud to Terraform or OpenTofu

Bringing console-built AWS, Azure and Google Cloud resources under Terraform or OpenTofu with import blocks, clean state and pipelines, without rebuilding.

read the case study
implementation Cloud and infrastructure

Cloud landing zone and account vending

AWS Control Tower with Account Factory for Terraform, or Azure landing zones on Azure Verified Modules, built as code with guardrails, logging and vending.

read the case study
migration Cloud and infrastructure

Data center exit to AWS or Azure

Leaving a colocation or owned data center for AWS or Azure in planned waves, with dependencies mapped, licences checked and every server given an owner.

read the case study
modernization Applications

.NET Framework and .NET 8 to .NET 10

Both .NET 8 and .NET 9 hit end of support on 10 November 2026. Moving them, and older .NET Framework apps, to .NET 10 LTS one project at a time.

read the case study
upgrade Cloud and infrastructure

Kubernetes, EKS and OpenShift version upgrades

Keeping EKS, AKS and OpenShift clusters on supported Kubernetes minors, and dealing with deprecated APIs, add-ons and node pools before each upgrade.

read the case study
approach

How a HashiCorp Vault engagement runs

We don't start a step until the last one has produced something you can check.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

architecture

How workloads get short-lived secrets from Vault

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.

How workloads get short-lived secrets from Vault 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. 01 · AUTH METHODS 02 · VAULT CLUSTER 03 · SECRETS ENGINES 04 · WORKLOADS login login login role ID login generate issue generate DB credentials TLS certificates cloud credentials Kubernetes auth service account JWT Cloud IAM auth AWS · Azure · GCP JWT/OIDC auth CI pipelines · people AppRole older apps and scripts HashiCorp Vault2.x policies · leases ·audit devices Database secrets engine dynamic DB credentials PKI secrets engine short-lived certificates Cloud secrets engines dynamic IAM credentials Kubernetes workloads Vault Agent · CSI provider CI/CD pipelines Terraform · GitHubActions © Cohash · cohash.com
01 · AUTH METHODS02 · VAULT CLUSTER03 · SECRETS ENGINES04 · WORKLOADS Kubernetes auth: service account JWT Kubernetes auth service accountJWT Cloud IAM auth: AWS · Azure · GCP Cloud IAM auth AWS · Azure · GCP JWT/OIDC auth: CI pipelines · people JWT/OIDC auth CI pipelines ·people AppRole: older apps and scripts AppRole older apps andscripts HashiCorp Vault 2.x: policies · leases · audit devices HashiCorp Vault 2.x policies · leases · audit devices Database secrets engine: dynamic DB credentials Databasesecretsengine dynamic DBcredentials PKI secrets engine: short-lived certificates PKI secretsengine short-livedcertificates Cloud secrets engines: dynamic IAM credentials Cloudsecretsengines dynamic IAMcredentials Kubernetes workloads: Vault Agent · CSI provider Kubernetesworkloads Vault Agent · CSIprovider CI/CD pipelines: Terraform · GitHub Actions CI/CD pipelines Terraform · GitHubActions login login login role ID login generate issue generate DB credentials TLS certificates cloud credentials © Cohash · cohash.com
use cases

Typical HashiCorp Vault projects

The work teams usually bring us, and the platforms HashiCorp Vault has to talk to while we do it.

  1. HAS-01 Vault is still on 1.x and the jump to 2.x looks risky common request
  2. HAS-02 Applications still read static secrets from Vault. Dynamic ones would expire on their own. common request
  3. HAS-03 Certificates get issued by hand and nobody notices they're expiring until something breaks common request
  4. HAS-04 Renewal pricing changed and you're weighing Enterprise, HCP or OpenBao. You want the costs side by side before anyone signs. common request
  5. HAS-05 AI agents need short-lived credentials scoped to one task. Otherwise they end up with long-lived tokens. common request
HashiCorp Vault · connected platforms
TerraformCyberArkDelineaBeyondTrustMicrosoft Entra IDOkta
you keep

What a HashiCorp Vault engagement leaves behind

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. It shows what breaks at each step and what happened when we tested your plugins.

    yours to keep
  • code02

    Auth methods and policies kept in Terraform, so changes go through a pull request like any other code

    yours to keep
  • inventory03

    Static-token inventory. Each workload gets a named auth method to replace its token.

    yours to keep
  • design04

    PKI hierarchy design that sets certificate lifetimes and automates renewal, so nobody files a ticket for a certificate

    yours to keep
  • tests05

    DR replication and snapshot restore test, timed and written up

    yours to keep
  • document06

    A side-by-side of Community, Enterprise, HCP Vault Dedicated and OpenBao for the features you actually use

    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.

Onsite

Engineers at your sites in the US

Nearshore

Overlapping hours with US teams

Offshore

Overnight progress on your backlog

All time zones

Coverage handed over across time zones

24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
certifications our engineers hold
  • Vault Associate (003)HashiCorp
  • Vault Authoring and Operations AdvancedHashiCorp
roles we staff
  • Vault platform engineer
  • Vault auth method and secrets engine developer
  • Vault PKI engineer
  • Vault Enterprise operations engineer (replication, DR)
  • Kubernetes secrets integration engineer
due diligence · hashicorp vault

Questions to ask any partner, including us.

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.

  1. Q1

    What breaks in our configuration on the way from 1.x to 2.x?

    Vault 2.0 changed some legacy behavior. Azure auth config, for one, now beats AZURE_* environment variables. Check each hop's breaking changes against your auth methods, secrets engines and plugins before a date goes in the calendar.

  2. 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.

  3. 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.

  4. Q4

    Can we keep using Vault the way we do now under the Business Source License?

    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.

  5. 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?

It's IBM's numbering. After the acquisition HashiCorp put Vault on IBM's versioning and support model, and 2.0 went GA on 14 April 2026. Enterprise 2.x now runs on IBM Support Cycle-2, with two years of base support, one of extended and three of sustained. Sustained support doesn't get new fixes, so don't plan to sit there. Some legacy behavior went away too, so read the breaking changes first.

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. In 2.0, for example, values in auth/azure/config started winning over AZURE_* environment variables. 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 comes down to your hosting rules, the features you use and who's going to run the clusters. HCP Vault Dedicated takes server upkeep off your team. Strict network or data residency rules usually point to self-managed clusters. We put the options next to what you use and spend today.

06Which Vault version fixes HCSEC-2026-41 and -43, and what do we have to change before we patch?

Community and Enterprise 2.1.2 fix both, and so do Enterprise 1.21.12, 1.20.17 and 1.19.23. Patch every node, standbys and DR or performance secondaries too. After HCSEC-2026-43, rules that reference mixed-case resource names stop matching, deny rules included, so rewrite them in lowercase first. The fix doesn't cover Okta, LDAP, RADIUS or Enterprise SCIM client names. Plugins registered outside plugin_directory have to be registered again.

07What is the latest Vault version, and do we need 2.2.1?

2.2.1, released 22 October 2026, with Enterprise 1.21.13 and 1.19.24 alongside it. They close a flaw where a policy alias could resolve to the root policy. On 2.2.0 it's a patch. On 2.1 there's no backport, so you get the fix by moving to 2.2.1, and that move brings every 2.2 breaking change with it. Rehearse it on a snapshot.

services

Related services

Projects on HashiCorp Vault usually end up touching one of these, so they're worth a look.

you are hereHashiCorp Vault
fact-checked Checked against vendor and official documentation last checked 2026-10-26 content fingerprint 330e777f
  1. 01Book a 30-minute working sessionsenior engineer
  2. 02Talk to an engineer about your setupreply within 24 hours
  3. 03See how similar projects wentcase studies
Reviewed by the Cohash team HashiCorp Vault is a trademark of its owner, used here to identify the platform. how we handle facts and data →
next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

Book a working session See the case studies
useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it