HashiCorp has released Vault 1.21. This version introduces native SPIFFE authentication for non-human workloads, expands the granular secret recovery model introduced in Vault 1.20, and adds KV v2 secret attribution, MFA TOTP self-enrollment, a Vault Secrets Operator CSI driver that mounts secrets directly into pods without persisting them in etcd, and more.
Vault Enterprise 1.21 adds native support for SPIFFE (Secure Production Identity Framework For Everyone), an open standard for assigning cryptographically verifiable identities to workloads in dynamic environments. With SPIFFE, non-human identities like microservices, containers, and serverless functions can authenticate to Vault using X509 or JWT-based SVIDs (SPIFFE Verifiable Identity Documents) without relying on static credentials or manual configuration.
Beyond authentication, Vault can now issue X509-SVIDs to workloads that already authenticate through methods like AppRole or AWS auth, enabling them to participate in SPIFFE-based service-to-service communication without additional tooling. This makes Vault both a consumer and issuer of SPIFFE identities, useful for organizations building zero-trust architectures across Kubernetes, hybrid, and multi-cloud environments.
Vault 1.21 expands the secret recovery model introduced in Vault Enterprise 1.20. Before the version 1.20, recovering an accidentally deleted or modified secret required restoring the entire cluster from a snapshot, a resource-intensive operation that affected all namespaces. Vault Enterprise 1.20 added targeted recovery from loaded snapshots, allowing operators to inspect snapshot contents and restore only the affected path through the CLI:
$ vault list -snapshot-id <snapshot_id> <mount_path>/<secret_path>
$ vault recover -snapshot-id <snapshot_id> <mount_path>/<secret_path>
Vault 1.21 expands the supported recovery paths to include database static roles, SSH config CA and managed keys, and adds the option to recover a secret as a copy rather than overwriting the current value:
$ vault recover -snapshot-id=<snapshot_id> -from=secret/my-secret secret/my-secret-recoveredA new UI component was added to make recovery accessible to non-technical users, and administrators can configure automatic snapshots to keep recovery points available. Recovery permissions are controlled through a dedicated `recover` capability in Vault policies, allowing operators to delegate recovery to the teams closest to the affected secrets.
Vault 1.21 has added KV v2 secret attribution, exposing a `created_by` field to version metadata, providing the human-readable identity behind each secret version. Querying the metadata endpoint now returns attribution details for every version:
$ curl https://127.0.0.1:8200/v1/secret/metadata/my-secret
"versions": {
"1": {
"created_time": "2025-10-22T02:24:06.945Z",
"created_by": {
"actor": "userpass-engineer1",
"operation": "create",
"entity_id": "12345678-1234-..."
}
}
}
This means developers can now identify who modified a secret directly from the API without needing access to the audit log or contacting Vault operators - a practical improvement for teams debugging configuration changes in shared environments.
Vault Enterprise 1.21 also adds self-service TOTP enrollment during login, streamlining MFA onboarding by allowing users to enroll a time-based one-time password (TOTP) factor as part of the authentication flow. Previously, users logging into a namespace with MFA TOTP enforcement who had not yet configured it were blocked until an administrator manually generated and distributed a QR code. Now, Vault generates the QR code as part of the authentication process itself, removing the back-and-forth between users and administrators and letting teams complete MFA onboarding without operator intervention.
The Vault Secrets Operator (VSO) traditionally syncs secrets from Vault into native Kubernetes Secrets stored in etcd. Vault Enterprise 1.21 introduces a CSI driver that bypasses etcd entirely - when a pod starts and references a `CSISecrets` resource as a volume, the driver fetches secrets from Vault and mounts them directly into the pod at a configured path (e.g., `/var/run/csi-secrets`) as individual files. The secrets live only for the lifecycle of the pod and are never persisted in the cluster. Teams can select either delivery mode on a per-secret basis, choosing the right balance between convenience and isolation for each workload. The CSI provider has also been certified by Red Hat for use on OpenShift.
SCEP (Simple Certificate Enrollment Protocol), added in Vault 1.20, is an IETF-standardized protocol widely used to provision certificates to devices that lack the interfaces for manual enrollment, including routers, switches, firewalls, mobile devices managed through MDM platforms, and IoT hardware. By adding SCEP to Vault's PKI secrets engine, organizations can consolidate certificate management for these workloads alongside their existing Vault infrastructure rather than maintaining a separate PKI solution.
Vault 1.20 introduced utilization reporting for Enterprise customers, providing visibility into which secrets engines, authentication methods, and features are actively used across clusters. These insights help platform teams monitor adoption patterns, optimize configurations, and identify underutilized capabilities. Furthermore, this version added beta support for automatically downloading official HashiCorp auth and secrets plugins from releases.hashicorp.com, simplifying plugin registration and reducing the manual work required to keep plugins up to date.
More details about Vault 1.21 can be found in the release notes and the changelog.