6.6 VM Firmware, Secure Boot, vTPM & Virtualization-Based Security

6.6 VM Firmware, Secure Boot, vTPM & Virtualization-Based Security

Section 6.3 covered VM Encryption. This section covers the other in-guest security building blocks from objective 1.9.

BIOS vs. UEFI Firmware (1.9.2)

Every VM boots from virtual firmware, chosen under Edit Settings > VM Options > Boot Options > Firmware:

Choose the firmware before installing the guest OS. Switching an installed guest from BIOS to EFI, or back, usually makes it unbootable because the boot loader and partition layout don't match. The New Virtual Machine wizard picks a default firmware based on the guest OS you select.

VM Secure Boot

With EFI firmware, Secure Boot (in Boot Options) makes the virtual firmware accept only signed boot loaders, kernels, and drivers. It needs a guest OS that supports Secure Boot. Unsigned guest drivers stop the guest from booting until they are removed.

Virtual TPM (1.9.1)

A virtual Trusted Platform Module (vTPM) 2.0 gives the guest a TPM device, implemented in software.

Requirements:

• Virtual hardware version 14 or later.
• EFI firmware.
• A configured key provider: the vSphere Native Key Provider or a standard KMIP key provider (Section 6.3).
• A guest OS that supports TPM 2.0.

What happens when you add one: the vTPM's secrets are stored in the VM's files, so vSphere encrypts the VM home files (such as .nvram) with the key provider. The virtual disks are not encrypted by adding a vTPM. The ESXi host does not need a physical TPM for this; a host TPM is used for host attestation, not for guest vTPMs.

Use cases:

• Windows 11, which requires TPM 2.0 (plus UEFI Secure Boot).
• BitLocker or other disk encryption that seals keys to a TPM.
• Credential Guard and other VBS features, which use the TPM to protect secrets.
• In-guest measured boot and attestation.

Operations to know:

• vMotion, cloning, and restores need access to the same key provider.
• In vSphere 8, the vTPM provisioning policy controls whether a clone copies the source vTPM or gets a new one. Replacing it avoids duplicate TPM secrets across clones.
• Back up the key provider along with the VM (the NKP backup, or your KMS backup), or the vTPM contents cannot be recovered.

Virtualization-Based Security (1.9.3)

Microsoft virtualization-based security (VBS) uses the Windows hypervisor inside the guest to isolate secrets and code integrity from the rest of the OS. It powers Credential Guard (protecting credential hashes against pass-the-hash attacks), Device Guard, and hypervisor-enforced code integrity (HVCI).

Requirements on vSphere:

• Intel hosts: vSphere 6.7 or later, virtual hardware version 14 or later, and Windows 10 or Windows Server 2016 or later.
• AMD hosts: vSphere 7.0 Update 2 or later, virtual hardware version 19 or later, and Windows 10 version 1809 or Windows Server 2019 or later.
• EFI firmware with Secure Boot.
• Hardware virtualization and the IOMMU exposed to the guest. Selecting Enable Virtualization Based Security in VM Options sets these for you.
• Host CPUs that support hardware-assisted virtualization (Intel VT-x with EPT or AMD-V with RVI).
• A vTPM is recommended so Windows can protect VBS secrets with it.

Limitations: VBS VMs do not support vSphere Fault Tolerance, PCI passthrough, or hot add of CPU or memory. The nested virtualization adds some CPU overhead; Broadcom recommends Intel Skylake-EP or later CPUs (or AMD Zen 2 or later) for best VBS performance. After enabling VBS on the VM, you still turn on the features inside Windows, for example through Group Policy.

Putting It Together: a Windows 11 or Hardened Windows Server VM

1. Create the VM with EFI firmware and hardware version 14 or later (hardware version 20 on vSphere 8).
2. Enable Secure Boot.
3. Make sure a key provider exists; the Native Key Provider is the simplest option (back it up first).
4. Add a vTPM device.
5. Optionally, enable VBS in VM Options, then turn on Credential Guard inside Windows.
6. Consider VM Encryption (Section 6.3) if the disks themselves must be encrypted at the hypervisor level.

Other Ways to Harden a VM

• Remove unused virtual devices, such as floppy drives, serial and parallel ports, and disconnected CD-ROM drives.
• Leave the default restrictions on console copy and paste in place.
• Limit VM log size and rotation (the defaults are sensible).
• Keep VMware Tools current, and use the Tools isolation settings only when policy requires them.

Exam Traps

• No physical TPM needed for vTPM. Questions that suggest buying host TPM chips (or passing them through) so VMs get a TPM are wrong. A key provider is what vTPM needs.
• vTPM is not disk encryption. Adding a vTPM encrypts the VM home files that hold its secrets. Encrypting the virtual disks requires VM Encryption or in-guest BitLocker.
• Firmware is a day-zero choice. Plan EFI for any VM that might later need Secure Boot, vTPM, or VBS.
• VBS excludes FT, passthrough, and hot add. If a VM must be fault tolerant, use PCI passthrough, or hot-add CPU and memory, it cannot also run VBS.