HashiCorp Vault Enterprise 1.21 is now generally available, introducing advanced capabilities for secure workflows and user experience enhancements, including several announced at HashiConf 2025.
- SPIFFE auth: Enable secure authentication of AI agents and other non-human identities to Vault and provide SPIFFE identities to existing Vault clients to enable these clients to participate in the SPIFFE ecosystem (such as hybrid and multi-cloud).
- VSO protected secrets: Provide secrets directly to Kubernetes pods without persistent storage in native Kubernetes secrets.
- Static role rotation for Azure credentials: Secure, on-demand rotation of long-lived Azure credentials to enable zero-trust security practices.
- Self-service TOTP setup: Automatic time-based one-time password (TOTP) registration is now supported during login, allowing users to securely set up multi-factor authentication (MFA) to streamline onboarding and reduce operational overhead.
- Granular secret recovery: enables individual secrets and configuration items to be restored without needing a full cluster rollback, thereby improving efficiency, minimizing disruption, and reducing administrative overhead by delegation.
- FIPS 140-3 Level 1 (coming soon): Vault cryptography is undergoing FIPS-3 Level 1 attestation with an independent CMVP auditor. Upon attestation, customers can deploy Vault in environments where higher-level assurance (FIPS 140-3) is needed. Support for seal-wrap or auto unseal scenarios that require FIPS 140-3 Level 2+ with HSMs.
»SPIFFE auth support
SPIFFE (Secure production identity framework for everyone) is an open identity standard. SPIFFE helps tackle identity validation and trust for non-human workloads such as AI agents in dynamic, heterogeneous environments, including Kubernetes, hybrid, and multi-cloud architectures. It enables each workload to be assigned a cryptographically verifiable identity, allowing secure, automated authentication between services without manual configuration.
With native SPIFFE auth support, Vault Enterprise simplifies and extends authentication of non-human-identity workloads such as AI agents and issues X509-SVIDs for Vault-authenticated non-human workloads, so they can interact natively in the SPIFFE ecosystem and enable zero-trust practices. Vault SPIFFE support enables:
- Automated authentication and SPIFFFE X-509-SVID issuance: Vault can automatically assign X-509-SVIDs and issue the corresponding certificates for authenticated workloads — no manual steps required.
- Enhanced traceability: Vault generates detailed logs of authentication and SVID issuance events, enabling complete visibility and traceability for security and audit teams.
With built-in support for SPIFFE, Vault further extends capabilities to issue, rotate, and validate workload identities and credentials, enabling customers to implement zero-trust practices in an automated, simplified manner.
»VSO protected secrets
Traditionally, the Vault Secrets Operator (VSO) bridges Vault and Kubernetes by syncing secrets from Vault and storing them as native Kubernetes Secrets. These secrets are stored in the cluster’s underlying datastore (etcd), allowing applications to access them using familiar Kubernetes patterns. VSO continuously monitors changes to custom resources and ensures that when the secrets are updated in Vault, they get automatically reflected in the Kubernetes secrets store — providing a seamless, automated workflow.
In Vault Enterprise 1.21, VSO offers an additional flow — instead of persisting secrets in the Kubernetes secrets store, VSO deliver secrets at pod startup directly to your pods, eliminating the need to store these secrets in the Kubernetes cluster. VSO enables both flows — selectable on a per-secret basis — to offer the right blend of access and isolation for each secret and workload.
How it works:
- You define a custom resource that specifies which secrets to retrieve from Vault and outlines the access controls determining which pods can use them.
- When an authorized pod references that resource as a volume, the VSO CSI driver fetches the secrets from Vault and mounts them directly into the pod.
- All containers in the pod that reference the volume get secure, just-in-time access to the secrets.
This approach eliminates the need to store secrets in the cluster, reducing the risk of sensitive data exposure while maintaining a dynamic and tightly controlled access model. For customers seeking to improve security posture, the new CSI driver capability in VSO offers a powerful yet simplified option to reduce risks related to persisted secrets.
»Static role rotation for Azure credentials
Vault supports dynamic Azure credentials that are automatically revoked when their lease expires, or the client's session ends. While this approach is ideal for short-lived access, it can be limiting for teams that need persistent credentials — especially in automation workflows or integrations that rely on stable, long-term access. With the latest release, Vault Enterprise now supports Azure static roles with rotation — a major enhancement to the Azure secrets engine that brings greater flexibility and control to managing Azure credentials.
With static roles and credential rotation, Vault Enterprise allows organizations to create, store, and manage Azure credentials that persist beyond individual client sessions. These credentials can be rotated on demand using the Vault API or UI, providing a secure and predictable access model for long-running services.
Key features include:
- On-demand credential rotation: Refresh static Azure credentials whenever needed without manual intervention.
- Secure credential storage: Static credentials are safely managed within the Azure secrets engine mount and governed by Vault access policies.
- Management of existing credentials: Vault can now import and manage client secrets on existing Azure service principles, enabling a unified and consistent credential management workflow.
This new capability empowers security and platform teams to standardize access controls across cloud environments, using Vault as the single source of truth for Azure credentials — whether short-lived or persistent.
»MFA TOTP self-enrollment
Previously, when end users attempted to log into a tenant with MFA TOTP enforcement enabled but had not yet set up their TOTP, they were unable to proceed without administrator intervention. This often meant admins had to manually generate and securely distribute QR codes — an inefficient and potentially insecure process.
With this update, Vault Enterprise now supports the option for TOTP registration during the login flow. If a user logs in with a valid username and password, but has not yet configured TOTP, a QR code will now be generated and presented as part of the authentication process. This allows users to quickly and securely complete their TOTP setup without needing to contact an administrator.
»Fine-grained secret recovery
Accidental deletion or modification of a secret or configuration item can be disruptive. Historically, administrators had to restore the full cluster from a snapshot to recover a secret. This is a time-consuming process that not only impacts all namespaces but also consumes significant system resources for what is often a small-scale fix. This created unnecessary operational complexity and risk for broader service degradation.
Vault Enterprise 1.20 added support for granular recovery of individual secrets and configuration items, enabling targeted restoration without affecting the entire cluster. This streamlined approach conserves resources, reduces the blast radius of recovery operations, and improves overall system reliability. 1.20 also added the ability to delegate recovery to appropriate users.
Key benefits include:
- Minimized impact: Recover exactly what’s needed without rolling back the entire cluster.
- Operational efficiency: Significantly lower resource usage for recovery operations.
- Increased agility: Delegate recovery tasks to those closest to the work, thereby reducing administrative bottlenecks.
In Vault Enterprise 1.21, we have expanded secret recovery to include:
- A new UI component
- Database static roles
- SSH config CA/managed keys
- “Recover as a copy” without overwriting the current secret value
- Administrators can configure snapshots to automatically make them available for recovery operations
With these improvements, Vault Enterprise continues to evolve into a more resilient, user-friendly platform, empowering teams to manage secrets securely and efficiently at scale.
»FIPS 140-3 Level 1 compliance
Vault Enterprise natively supports ZTS security practices, and its cryptographic modules are validated for FIPS 140-2 Level 1. While this meets the needs of most customers, Vault's cryptographic modules are now in the attestation process for FIPS 140-3 Level 1. This will help address the compliance needs of customers in regulated industries (such as government, finance, or healthcare).
Key benefits include:
- FIPS 140-3 Level 1 validation for core cryptographic operations
- Improved compliance posture for regulated industries
- No compromise on performance or usability.
»Seal wrap for FIPS 140-3 Level 2+
We will continue to support seal wrap for applicable scenarios that require FIPS 140-3 Level 2+ configurations using an HSM or for auto unseal. This will enable customers to deploy Vault in high security/air-gap environments.
»Key-value pair (v2) attribution
When a KV v2 secret is changed, it generates a new version. This change includes in the version metadata the human-readable name of the identity who made the change that generated the version (for example, if Engineer 1 edited the secret, Engineer 1's name would show up in the metadata API response). This gives application developers who may not have access to the audit log the ability to tell who made the change without having to contact their Vault operators. It also allows operators to avoid the manual overload of going through the audit log and figuring out the human-readable name of the identity that made the change.
»Vault Enterprise 1.21 upgrade details
This release also delivers a variety of additional new features, workflow enhancements, general improvements, and bug fixes. You can explore the full list of updates, including those that are available in Vault Community Edition, by reviewing the Vault 1.21 changelog.
As always, we recommend testing new releases in a staging or isolated environment before deploying them to production. If you encounter any issues, please report them via the Vault GitHub issue tracker or start a discussion in the Vault community forum. If you believe you’ve discovered a security vulnerability, please report it responsibly by emailing security@hashicorp.com. Avoid using public channels for security issues. For details, refer to our security policy and PGP key.
To learn more about HCP Vault or Vault Enterprise, visit the Vault product page.
