Adding a vTPM to a VMware VM: Key Provider Requirements and What Changes Afterwards

Direct answer: a virtual TPM (vTPM) is a small device to add but a lasting change to the virtual machine. vSphere protects the vTPM's data with virtual machine encryption, so it needs a working key provider first. Adding the vTPM encrypts the VM home files (including the .nvram file that holds the vTPM state), although not the virtual disks. From then on the VM depends on that key provider. Power-on, console access, cloning, migration to another vCenter and restore all need the right keys and the right cryptographic privileges. Before you add one, confirm the prerequisites: - a key provider that is Active and backed up; - EFI firmware; - hardware version 14 or later; - the VM powered off.

Then record how the change affects the VM's clone, template, migration and backup workflows, and decide the recovery position for the key provider.

Why it matters

Windows 11 requires a TPM 2.0. vCenter refuses to create a Windows 11 VM without a vTPM when no key provider is configured (Broadcom KB 396090 quotes the message "requires a Virtual TPM device, which cannot be added to this virtual machine because the vSphere environment is not configured with a key provider"). Windows Server is different. Microsoft's hardware requirements page for Windows Server lists a TPM as "required only for certain features", and as part of the Secured-core server requirements. So a Server 2025 VM does not automatically need a vTPM. It needs one if you intend to use a TPM-dependent feature such as BitLocker with TPM protectors, or to meet a Secured-core or internal security baseline. Decide that per workload rather than adding vTPMs everywhere because the newest client OS needs one.

The operational risk sits outside the guest. Once a VM has a vTPM, its configuration files are encrypted. If the key provider is lost, unavailable or different at the destination, the VM can show as invalid or refuse to power on (KB 395883). It can also fail to migrate to another vCenter (KB 424420). Operators without cryptographic privileges can no longer power it on or open its console (KB 326210). Each is avoidable if it is planned before the change.

How it works

The vSphere 8.0 vTPM overview explains the model.

• What a vTPM is: a vTPM is a software representation of a TPM 2.0 chip. It uses the VM's .nvram file, encrypted with virtual machine encryption, as its secure storage.
• What gets encrypted: only the VM home files are encrypted by default, not the disks. You can choose to encrypt the disks as well, as a separate decision.
• Identity: the vTPM's Endorsement Key certificate comes from the VMware Certificate Authority or a third-party CA. The documentation notes that after the vTPM uses a key, it is typically not changed, because doing so invalidates sensitive information stored in the vTPM.

Key providers. vSphere has three types: - Standard: vCenter fetches keys from an external key server. - Trusted: vSphere Trust Authority. - vSphere Native Key Provider (NKP): available from 7.0 Update 2. vCenter generates a Key Derivation Key and pushes it to the ESXi hosts in the cluster, which then generate data encryption keys "even when not connected to vCenter Server".

Licensing and host requirements: - vTPM with NKP is included in all vSphere editions. Using NKP for full VM encryption needs Enterprise Plus, according to the NKP overview. - NKP does not require a TPM in the ESXi host, but it can be restricted to TPM-protected hosts. - KB 369538 adds that NKP needs hosts in a cluster, and that a provider restricted to TPM-protected hosts fails on hosts without a TPM 2.0.

Prerequisites for adding a vTPM to an existing VM (vSphere 8.0 "Add Virtual Trusted Platform Module to an Existing Virtual Machine"): - a configured key provider; - the VM powered off; - EFI firmware; - hardware version 14 or later (from the overview page); - ESXi 6.7 or later for Windows guests, and 7.0 Update 2 or later for Linux guests; - privileges: Cryptographic operations (Clone, Encrypt, Encrypt new, Migrate, Register VM), plus Virtual machine > Change Configuration > Add or remove device.

After the vTPM is added, opening a console needs Cryptographic operations > Direct Access. KB 396090 adds that an NKP becomes Active only after it has been backed up. You download a .p12 backup file, which must be stored securely.

Converting firmware is a separate risk. A VM installed with BIOS firmware cannot simply be switched to EFI. The guest's boot configuration must match the firmware, and switching without converting the guest disk layout leaves it unbootable. Treat a BIOS-to-EFI change as its own planned change, with the guest vendor's conversion procedure. It is not a checkbox before adding the vTPM.

Read-only checks

None of these was run for this article. They read configuration only.

1. Key provider state. In the vSphere Client select the vCenter Server, then Configure > Security > Key Providers. Record each provider's name, type, status (Active, Warning, Unknown), whether it is the default, and whether an NKP is restricted to TPM-protected hosts. For an NKP, confirm with whoever holds it that a current .p12 backup exists and where it is stored. Do not copy the file or its password into tickets.

2. Host placement. Confirm the hosts that will run the VM are in a cluster (NKP requirement, KB 369538). If the provider is TPM-restricted, confirm that every host in the cluster has a TPM 2.0.

3. VM firmware and hardware version. In the VM's Summary and Edit Settings > VM Options > Boot Options, record the firmware (EFI or BIOS), whether Secure Boot is enabled, and the compatibility (hardware version). With PowerCLI, a read-only view of several VMs:

Get-VM -Name app01,app02 | Select-Object Name, PowerState, HardwareVersion, @{N='Firmware';E={$_.ExtensionData.Config.Firmware}}

4. Existing vTPM VMs. vSphere has an "Identify Virtual Trusted Platform Module Enabled Virtual Machines" procedure (vSphere Security guide). Check how many VMs already depend on the provider before you change anything about it.

5. Operator roles. List the roles used by operators, automation and backup service accounts that power on, open consoles, migrate, clone or restore VMs. Compare each with the cryptographic privileges above and in KB 326210: Direct Access, Read KMS information, and Migrate when DRS is enabled.

6. Workflows that touch the VM. List the clone, template, cross-vCenter migration, replication and backup jobs that include this VM. Those are what change.

Interpreting the results

Decision guidance

Whether to add one. - Windows 11 guests need a vTPM. - For Windows Server 2025 and other guests, add one when a guest feature or security baseline requires a TPM, and record which. - For a guest with no TPM consumer, a vTPM adds key-provider dependency without benefit.

Making the change. The documented steps: 1. Power off the VM. 2. Choose Edit Settings > Add New Device > Trusted Platform Module. 3. Click OK.

The VM Details pane then shows that encryption has been applied. Do this in a maintenance window, because the VM must be off.

Before: - take a backup that includes the VM home files; - confirm the key provider is Active and backed up.

After: - power on; - confirm the guest sees a TPM 2.0 (in Windows, Get-Tpm in an elevated PowerShell is read-only); - check that an operator with the intended role can power on and open the console; - run the VM's backup job once and confirm it completed.

Rollback: vSphere documents "Remove Virtual Trusted Platform Module from a Virtual Machine". Removing it destroys whatever the guest stored in the vTPM. If BitLocker or another feature already sealed keys to it, make sure recovery keys or alternative protectors exist first, or the guest may demand its recovery key or lose access. Remove a vTPM only after the guest's TPM consumers are cleared.

Cloning and templates. The vSphere 8.0 overview states that when cloning a VM with a vTPM, the Replace option starts the clone with a new, blank vTPM that has its own secrets and identity. Replacing secrets replaces all keys, including workload-related keys, so workloads in the clone that relied on the vTPM may not work. Copying duplicates the vTPM, including properties software uses to identify the system. For templates of Windows machines that will be generalised and joined individually, Replace avoids duplicated TPM identity. For a clone intended as a recovery copy of a workload that seals data to the TPM, Copy keeps that data usable. Record the policy in the template procedure rather than leaving it to whoever clones next.

Cross-vCenter moves and replication. KB 424420 shows that a cross-vCenter vMotion of a vTPM VM fails with "Key provider … not found" when the vCenters have different Native Key Providers. The fix is to restore the source NKP backup on the destination and compare Key IDs. Do this deliberately and in advance for any planned migration or DR target, and treat the .p12 backup as part of the DR design.

Backup and restore. The vTPM overview states that a backup must include all VM data, including the .nvram file. Without it a vTPM VM cannot be restored, and the encryption keys must be available at restore time. Confirm with your backup product's documentation that it captures the VM home files of encrypted VMs, and which cryptographic privileges its service account needs. That is product-specific and not covered here. Test one restore of a vTPM VM, to an isolated network, before relying on the policy.

Key provider recovery. If the key provider is lost or unreachable, VMs may show invalid or fail to power on with "A key with identifier … is required to unlock this virtual machine" (KB 395883). Resolve the provider's connectivity or restore it first, as that KB says; rebuilding the VM will not fix a key problem. Recovering an NKP itself is covered by the vSphere documentation "Recovering a vSphere Native Key Provider" and by the hardening article listed below. It is not repeated here.

What not to do

• Do not add a vTPM while the only NKP has never been backed up, or while the backup file sits on the vCenter it protects.
• Do not switch a BIOS VM to EFI in the same step without the guest's conversion procedure.
• Do not grant broad Cryptographic operations privileges to everyone to avoid permission errors; grant the specific privileges each role needs.
• Do not remove a vTPM to "fix" a migration or backup problem before you know what the guest sealed to it.
• Do not assume a backup or replication product handles vTPM VMs because it handles ordinary ones; verify with its documentation and a test restore.
• Do not create a second, different NKP on a DR or destination vCenter and expect existing vTPM VMs to move there.

Limitations

• This article describes vSphere behaviour from the 7.0 U2 and 8.0 documentation. The Replace clone option is stated for 8.0 and later. Interfaces in 9.x may differ.
• Standard and trusted key providers have their own key server or Trust Authority requirements that are not covered in detail.
• Guest-side TPM use (BitLocker protectors, Windows Hello, attestation) is only summarised; follow the guest vendor's procedures.
• Backup product behaviour and privilege lists are product-specific. A Broadcom KB on vTPM backup privileges found during research (378811) returned "page not found" on 2 November 2026 and is not relied on.
• No claim is made that any particular hosting service offers vTPM VMs or a given key provider type.

Acceptance checklist

• [ ] Reason for the vTPM recorded (guest requirement or named feature/baseline)
• [ ] Key provider Active; NKP .p12 backup exists, stored securely away from the vCenter
• [ ] Hosts in a cluster; TPM restriction matches the host hardware
• [ ] VM uses EFI firmware and hardware version 14 or later
• [ ] Operator, automation and backup roles reviewed for cryptographic privileges
• [ ] Clone Copy/Replace policy recorded for templates and clones
• [ ] Cross-vCenter and DR destinations hold the same provider (Key IDs compared)
• [ ] Backup includes VM home files; one isolated test restore done
• [ ] Change done with VM powered off; guest sees TPM 2.0; console and power-on tested with operator role
• [ ] Rollback path (vTPM removal and guest recovery keys) documented

References

All accessed 2 November 2026. Broadcom knowledge base articles do not display a last-updated date; TechDocs pages show "Last Updated October 28, 2026".

• Broadcom TechDocs, vSphere 8.0, What Is a Virtual Trusted Platform Module: https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-security/securing-virtual-machines-with-virtual-trusted-platform-module/vtpm-overview.html
• Broadcom TechDocs, vSphere 8.0, Add Virtual Trusted Platform Module to an Existing Virtual Machine: https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-security/securing-virtual-machines-with-virtual-trusted-platform-module/enable-vtpm-for-an-existing-virtual-machine.html
• Broadcom TechDocs, vSphere 8.0, vSphere Native Key Provider Overview: https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-security/configuring-and-managing-vsphere-native-key-provider/vsphere-native-key-provider-overview.html
• Broadcom KB 396090, Creating a Windows 11 VM fails: requires a Virtual TPM device / no key provider: https://knowledge.broadcom.com/external/article/396090/creating-a-windows-11-vm-in-vcenter-fail.html
• Broadcom KB 369538, Cannot add vTPM or enable host encryption: default provider, cluster and TPM enforcement: https://knowledge.broadcom.com/external/article/369538/cannot-add-vtpm-on-virtual-machine-or-en.html
• Broadcom KB 424420, Cross-vCenter vMotion of a VM with vTPM fails: https://knowledge.broadcom.com/external/article/424420/crossvcenter-vmotion-of-a-vm-with-vtpm-f.html
• Broadcom KB 395883, "Failed to power on virtual machine. An encryption key is required": https://knowledge.broadcom.com/external/article/395883/failed-to-power-on-virtual-machine-an-en.html
• Broadcom KB 326210, Powering on an encrypted VM or VM with vTPM fails for a non-Administrator user: https://knowledge.broadcom.com/external/article/326210/powering-on-an-encrypted-virtual-machine.html
• Microsoft Learn, Windows Server hardware requirements: https://learn.microsoft.com/en-us/windows-server/get-started/hardware-requirements

Related articles

• How to harden VMware without breaking operations or recovery
• How to build and validate Windows Server templates for VMware

• How to back up and rehearse recovery of the vCenter appliance

• Planning a VM Hardware Version Upgrade in vSphere: When, How and What to Check

• Planning a vSphere Major Upgrade: Order, Interoperability and a Go/No-Go Record

Learning notes

1. A vTPM is protected by VM encryption, so the key provider becomes a dependency of the VM's power-on, console, migration and restore.
2. Only the VM home files, including .nvram, are encrypted by default; the disks are not, unless you add disk encryption separately.
3. A Native Key Provider is not Active until backed up, and its .p12 backup is what makes cross-vCenter moves and recovery possible.
4. Clone with Replace for independent machines and Copy only when the clone must keep TPM-sealed data; decide in the template procedure.
5. Windows 11 requires a TPM; Windows Server lists it as required only for certain features, so decide per workload.