HashiCorp Vault 2.2 explained: TPM login, post-quantum PKI and the October fixes

HashiCorp shipped Vault 2.2.0 on October 15, 2026, eight days after a security release that closed four Vault bulletins. If you pay for Enterprise, you get machine login tied to a TPMdefinitionShort for Trusted Platform Module: a chip in a server, or a virtual one in a VM, that creates keys you can't copy off it. Vault 2.2 can tie a machine's login to that chip. chip and a much wider Secrets Sync, and everyone gets post-quantum ML-DSAdefinitionA post-quantum digital signature algorithm. Vault 2.2's PKI engine can sign certificates with it, but those CAs can't use ACME or OCSP yet. certificates in PKI. You also get seven breaking changes. Six only matter if you use SCIMdefinitionSCIM is the protocol an identity provider uses to create, change and delete users and groups in other systems. Vault Enterprise can be on the receiving end.; the seventh, an AWS credential change, hits Community Edition too. Any node below 2.1.2, or below 1.21.12, 1.20.17 or 1.19.23 on Enterprise 1.x? Read the security chapter before the feature list.

Vault sits in front of database passwords, cloud keys and certificates. When an upgrade goes badly, apps can't fetch their secrets and stop working, so a Vault outage usually turns into an outage for everything behind it. When a policy quietly stops working, someone gets keys they were never meant to have, and an auditor will want to know why.

The October fixes raise the stakes on upgrade day. Three of the four holes need someone who already has a Vault login, and the ACME one only needs a certificate client. Patching closes them, but one fix makes old mixed-case deny rules stop matching anything. If nobody rewrites those rules first, the upgrade itself opens the gap it was meant to close.

Most of what's new is for Enterprise customers, so the budget conversation matters too. These are the teams that get the most out of 2.2:

• Platform teams running Linux fleets on TPM 2.0 hardware or virtual TPMs, who can stop delivering a bootstrap secret to each new machine.
• Teams that put Azure static roles in Vault. Access tokens keep the client secret away from developers, and staged rotation reduces availability problems after a rotation.
• Identity teams that provision Vault from an identity provider or IGA tool. SCIM is now generally available, but connectors need updating first.
• PKI owners starting post-quantum work, who can issue ML-DSA test certificates as long as they don't need ACME or OCSP.
• Application teams that read secrets from AWS Secrets Manager or Google Cloud Secret Manager and now want database credentials synced there as well.
• Anyone delegating Vault administration with deny rules. The October fixes close the case-variant bypass, but only after the rules are rewritten in lowercase.

TPM auth is the change we'd look at first. Every Vault rollout has to get a first credential onto a new machine, usually an AppRole secret ID or a certificate, and whatever gets delivered can be copied off the host. With the TPM method an operator enrolls the machine's TPM once. From then on the machine runs a two-step enrollment, receives a certificate whose key was generated inside the chip, and logs in with it. You need Enterprise and a TPM 2.0 chip, physical or virtual.

ML-DSA in PKI gives you somewhere to start testing post-quantum certificates, with limits. HashiCorp's PKI guidance says ML-DSA CAs don't support ACME or OCSP yet. So revocation has to go through CRLs, and the clients reading those certificates have to be able to validate ML-DSA signatures before any of this is useful in production.

The Azure changes fix two practical problems. A static role can now return an OAuth2 access token in place of the client secret, so a platform team can let developers call Azure without handing them a credential they could reuse elsewhere. Separately, two-credential rotation stages the next secret ahead of expiry, because Azure needs time to replicate a new secret and an application that switches too early gets rejected. Mounts you already have don't change until you set seamless_rotation to true.

Secrets Sync copies secrets out of Vault into cloud secret stores for applications that can only read from those. Until 2.2 the source was KV v2. Now database static-role credentials can sync too, and Vault pushes the new value whenever one rotates. Destinations in AWS Secrets Manager and Google Cloud Secret Manager can span several regions and can be encrypted with the cloud provider's own keys.

There's a long tail of smaller changes. You can read and recover KV v2 secrets from a loaded snapshot, give AD and LDAP roles their own password policy, and rotate the Terraform secrets engine's root token. Vault Secrets Operator 1.6 delivers rotated secrets straight away. The GUI gets an upgrade analyzer, a Terraform code generator and a YAML view for KV secrets that hides values until you ask.

Then there are the security fixes. They came out a week before 2.2, and the table below shows the release that closes them for each line. Anyone on 2.2.0 already has them.

Whatever line you're on, review your templated policies, then set deny_slash_in_templated_paths = true on every server and restart. It's off by default, even in 2.2.0.

Then came 2.2.1 on October 22. It closes a cache-key collision where a policy alias such as ./root or a/../root could resolve to Vault's root policy, the one that can do everything. Vault now refuses those aliases wherever a policy gets assigned: entities, groups, tokens, auth responses and the agent registry. HashiCorp hasn't put out a bulletin or a CVE for it yet, so a scanner that only matches CVEs won't flag it.

Two things catch people out here. There's no 2.1.3, so on 2.1 the fix only arrives with the move to 2.2.1 and every 2.2 change that comes with it. And the Enterprise 1.21.13 and 1.19.24 patches remove HCP Link, the same change 2.2.0 made. The hcp_link_status and hcp_link_resource_ID fields drop out of the sys/seal-status response too, so check any monitoring that reads them. If your 1.x servers still carry the cloud stanza, take it out before you patch. Anything that was set up with a name like ./root will also start failing, so look for it first.

On October 7 HashiCorp published four Vault bulletins and shipped fixes in Community 2.1.2 and Enterprise 2.1.2, 1.21.12, 1.20.17 and 1.19.23. The 2.2.0 changelog carries the same fixes. Three of them need authenticated or privileged Vault access, and the ACME one only needs an ACME client unless you require external account binding. Each one also changes how Vault behaves once you've patched, so they belong in the upgrade plan and not only in the patch queue.

HCSEC-2026-43 is the one most likely to hurt on upgrade day. After the fix, ACL and Sentinel rules for AppRole, AWS, Azure, GCP, Kubernetes and several other resource names are matched against the lowercase name. HashiCorp's changelog uses auth/approle/role/MyRole as its example and says plainly that existing deny rules with mixed-case names will fail open after the upgrade until they're rewritten in lowercase. Okta group names, LDAP and RADIUS names on mounts left case-insensitive (the default), and Enterprise SCIM client names aren't covered by the fix, so keep broad allow rules away from narrow denies on those.

Coming from 2.0.3 or earlier? The August bulletins apply as well: HCSEC-2026-27 and -32 up to 2.0.3, and HCSEC-2026-26 up to 2.0.2. HCSEC-2026-26 let a LIST request with a trailing slash skip a narrower wildcard deny and list the entry names beneath it, though not their values. HCSEC-2026-27 let an Enterprise caller delete entities belonging to another namespace. HCSEC-2026-32 is the odd one out. Patching to 2.0.4 or later isn't enough on its own: you also have to set deny_slash_in_templated_paths = true on every server and restart, because the option defaults to false.

Here's how 2.2 lines up against the two releases before it. If you're still on 2.0, the bottom row is the list of things that'll bite you on the way.

The version numbers have a story behind them. After IBM bought HashiCorp, Vault Enterprise moved to IBM's Support Cycle-2definitionIBM's support model for Vault 2.x. Two years of base support, one year of extended support, and then three years where you can still open cases but won't get new fixes., and the release after 1.21 was called 2.0. You won't find a 1.22, and support dates now follow IBM's rules.

Support for Vault Enterprise works differently on 2.x. Under IBM's Support Cycle-2, each major release gets two years of base support, a year of extended support with critical fixes and limited security patches, and then three years of sustained support where you can still open cases but get no new fixes. HashiCorp also says it doesn't backport fixes across minor releases within a major release. In practice, future 2.x fixes will show up on the newest minor line rather than on 2.1. Enterprise customers still on 1.19 LTS have extended maintenance until April 2027.

$ vault status | grep -E 'Version|Sealed|HA Mode'
Sealed          false
Version         2.1.1
HA Mode         active
# below 2.1.2: October fixes missing
$ for p in $(vault policy list); do vault policy read "$p" | grep -nE 'path "[^"]*[A-Z]' | sed "s/^/$p: /"; done
ops: 7:path "auth/approle/role/Prod-Admin"
# role name in mixed case: lowercase it before patching
# only role, user, cert and policy names; leave KV paths alone

Vault upgrades in place: you stop the service, install the new binary, start it and unsealdefinitionVault starts up locked and can't read its own data until it's unsealed, with key shares from several people or an automatic seal. Every node needs it after an upgrade restart.. What makes them risky is the list of behavior changes between your version and the target, so the order of work below puts the cleanup before the binary swap.

The diagrams below show what 2.2 changes in a typical estate. The habits after them are the ones that would have made October's cleanup a small job.

Rollback is the last resort because a snapshot restore throws away recent writes, like rotated credentials and new leases. The failures listed above all come from documented behaviour changes, and each of those has a forward fix. Rehearsing on a production snapshot is what finds them before the change window does.

We treat Vault upgrades as rehearsed changes. We read the breaking changes for every hop, restore a production snapshot into an isolated test cluster, test plugins and auth methods there, and only then touch production. If you're planning the move to 2.2, or weighing whether TPM auth and the Azure changes justify Enterprise, our HashiCorp Vault page explains how we work. You can also bring in Vault engineers for the upgrade, or start with an assessment of your current cluster.