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.

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.

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.

Some history explains the version numbers. IBM finished buying HashiCorp in February 2025, Vault has been under the Business Source License since August 2023, and in April 2026 Vault went from 1.21 straight to 2.0 when 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..

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 upgrades in place: you stop the service, install the new binary, start it and unseal. 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.

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

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.