Your application starts on a virtual machine. Its database password is safely stored in Vault. Access policies are in place. Everything is ready—except the application needs a credential before Vault will let it retrieve anything. Someone has to get that first credential to the right machine. Then protect it, limit its use, and replace it when necessary. Repeat that across a fleet, and the first connection becomes a security risk of its own. This is the Secret Zero problem. And for teams running applications on on-premise VMs, it can stand between adopting centralized secrets management and relying on yet another system to distribute secrets.
Vault 2.2 introduces TPM Support for Vault Enterprise. Linux VMs can authenticate using keys bound to an enrolled virtual Trusted Platform Module (vTPM), removing the need to deliver a reusable bootstrap secret to each VM for this authentication flow. For platform teams, that means a new way to establish trust in the applications running on infrastructure they already operate. For security teams, it means stronger protection against credentials being copied from one machine and reused on another.
»Bring infrastructure-based authentication to on-prem VMs
Cloud identity services give workloads a way to authenticate without teams distributing their own bootstrap secrets. Where those services are configured, Vault can use the platform's identity as a basis for trust. On-prem VM environments often lack an equivalent identity service that Vault can consume directly. Teams fill the gap with AppRole SecretIDs, client certificates and private keys, or tokens delivered through provisioning systems. These approaches can be secured, but the delivery process remains part of the trust chain.
TPM Support gives teams another path. A vTPM provides cryptographic operations using protected keys inside a virtual machine. Once the vTPM is enrolled with Vault, the VM can prove possession of a key bound to it. Vault can verify that proof before granting access. The operator decides which VM to trust and what it can access. The VM supplies the cryptographic proof when it authenticates. There is no reusable bootstrap secret to hand over to the VM. The initial release focuses on Linux VMs with vTPMs in Vault Enterprise. Windows and physical TPMs on bare-metal servers are outside this release's scope.
This illustrates the workflow for vTPM authorization in Vault that solves the Secret Zero challenge with strengthened machine identity.
»Enroll, attest, authenticate
TPM Support brings the attestation and authentication workflow into Vault:
Enroll the VM. An authorized operator or provisioning system registers the vTPM's public Endorsement Key with Vault and configures the roles and policies it may use. Enrollment establishes which machine is trusted and the access it is eligible to receive.
Attest the key. The VM completes an attestation exchange with Vault. Vault verifies that the application key is bound to the enrolled vTPM and issues a client certificate for that key.
Authenticate to Vault. The VM uses the certificate and its vTPM-protected key to authenticate. Vault issues a token with the configured policies, which the application uses to retrieve its secrets.
The application still gets a Vault token and accesses secrets through Vault's policy controls. What changes is how it earns that token in the first place. A public certificate and protected key blobs can remain on disk. Copying those files alone does not provide the usable private key needed to authenticate from another machine with a different vTPM. That binding is the core security benefit: access depends on using the enrolled vTPM's key, rather than possessing a bootstrap secret copied from the VM.
»Replace secret delivery with managed enrolment
For platform teams, TPM Support changes the work involved in bringing a VM into service. Instead of delivering a reusable bootstrap secret, the provisioning process registers the VM's public vTPM identity and associates it with the right access in Vault. That creates an opportunity to make enrollment part of VM provisioning. A new VM is enrolled as it comes into service, receives access appropriate to its role, and can subsequently authenticate using its vTPM-bound key.
Enrollment remains a trust decision. The provisioning system needs permission to register machines, and teams need procedures for vTPM replacement, VM retirement, and failed attestation. Certificates and Vault tokens also retain their own lifecycles. The operational benefit is removing bootstrap secret delivery from that process, while keeping authorization in Vault.
The same benefit applies whether the VM runs an established application, a new service, or an AI agent. Each needs to authenticate before it can retrieve secrets. TPM Support addresses that shared foundation without requiring the application to move to a cloud platform first.
»Connect on-prem authentication to SPIFFE identity
Vault already provides capabilities for minting SPIFFE identities. TPM Support strengthens the first step for on-prem VMs: authenticating to Vault before requesting an identity. An application can use its enrolled vTPM to authenticate to Vault, then request a SPIFFE identity through Vault's existing issuance capabilities, subject to the configured access policies. This connects authentication rooted in the VM's vTPM with a standard identity that can be used beyond Vault.
For platform teams, the two capabilities address complementary needs: TPM Support establishes the basis for the initial authentication, while SPIFFE gives the workload an identity that other systems can verify. Those systems must support the relevant SPIFFE identity format and be configured to trust its issuer. Together, these capabilities give teams a path from on-prem VM authentication to broader workload identity, with Vault at the center of issuance and access policy.
»Eliminate the Secret Zero problem with TPM Support in Vault
Start with a Linux VM workload that currently depends on a distributed bootstrap credential. Identify how its vTPM can be provisioned, who will enroll it, and which Vault policies it needs. Use that workflow to evaluate TPM Support before extending enrollment across a larger fleet.
With Vault 2.2, teams gain a new way to secure the first connection for on-prem workloads and remove one more secret from the provisioning process, eliminating the Secret Zero problem. Talk to your IBM representative about adopting TPM Support in Vault Enterprise 2.2 for your on-prem VM environment.
