Security Features Inside the Virtual Machine

(Day 18 of 22 in our Cybersecurity Awareness Month series. Today: VM security features)

Most of this series so far has focused on the infrastructure itself: hardware, hosts, management, and the networks in between. The virtual machines running on that infrastructure have security features of their own, though. Many of them sit unused simply because a VM was built from an old template, migrated from an older platform, or created in a hurry.

VMware Cloud Foundation (VCF) gives every virtual machine the same kinds of protections that modern physical servers have: UEFI firmware, Secure Boot, a TPM, virtualization-based security, and encryption. Let’s go through them and take a look.

Build VM Security on UEFI and Secure Boot

Everything else in this post builds on UEFI firmware. Legacy BIOS firmware can’t do Secure Boot, can’t host a virtual TPM, and can’t run virtualization-based security, so the first step is making sure VMs use EFI firmware.

Secure Boot checks the signatures on the boot loader, kernel, and drivers before they load, which helps keep out malware that tries to hide underneath the operating system. It needs EFI firmware, virtual hardware version 13 or later, and a guest operating system that supports it. The VM has to be powered off to turn it on. The VCF Security Configuration Guide treats it as a top VM security priority.

A few things to know:

• Converting from BIOS to UEFI takes work. Broadcom’s guidance for VMs that use virtualization-based security is to reinstall the guest (VBS best practices). Microsoft’s MBR2GPT tool can convert Windows 10 and 11 system disks in place (Microsoft), but test it, and take a snapshot first.
• Secure Boot depends on updates. Secure Boot relies on lists of trusted and revoked signatures. The BlackLotus bootkit got around Secure Boot by loading older, vulnerable boot managers that were still validly signed, and the NSA’s guidance for mitigating it notes that virtual machines are affected, too (NSA). Keeping guests patched keeps those lists current.
• Microsoft’s 2011 Secure Boot certificates are being replaced. Several Microsoft certificates that Secure Boot relies on expire in 2026. VMs keep booting, but VMs created on older versions of ESX, and the templates they came from, may not accept future Secure Boot updates until their certificates are refreshed. VCF raises a vCenter alarm for VMs that need the update and can update many of them automatically, and Broadcom’s guidance walks through the rest (KB 423893). You need to be running VCF 9.1.1 or a future vSphere 8.0 update, as well as VMware Tools 13.1.5 or newer, for these alarms and helpers to be present.

Give Windows a Virtual TPM

A virtual TPM (vTPM) is a software TPM 2.0 device that gives a VM the same kind of protected key storage that a physical TPM gives a physical server. Windows 11 requires a TPM 2.0 (Microsoft), and Windows uses it for BitLocker, Windows Hello, measured boot, and more.

A vTPM needs EFI firmware, virtual hardware version 14 or later, and a key provider, because its secrets are stored in the VM’s NVRAM file, which VM encryption protects. The Native Key Provider is enough, and with a vTPM, the standard resilience features, like vMotion, HA, and DRS, continue to work (vTPM overview). Our post on key provider design covers the keys.

Three details trip people up:

• A vTPM doesn’t encrypt the virtual disks. Adding one encrypts the VM’s home files, like NVRAM and swap, and vCenter shows the VM as encrypted. The disks stay as they were, though, unless you also apply VM encryption, run atop an encrypted vSAN datastore, or use BitLocker inside the guest (vTPM overview). All of these things are compatible with vTPM-enabled VMs, too.
• Clones copy the vTPM by default. Cloning a VM with a vTPM offers the choice of duplicating its TPM identity and secrets (the default, to match historical behavior) or replacing the vTPM with a blank copy. Replacing it destroys anything sealed to the old one, such as BitLocker keys, so suspend BitLocker first (KB 452119). Templates deserve special attention here, where you probably want to replace the vTPM.
• Encrypted VMs can’t be exported as OVF or OVA files. That includes VMs with a vTPM, so keep their templates in a content library as VM templates. You can also use an OVF template with a vTPM placeholder, which gives each VM deployed from it a new vTPM with its own secrets (tech docs).

Turn On Virtualization-Based Security

Virtualization-based security (VBS) is a Windows feature that uses the hypervisor built into Windows to wall off a region of memory from the rest of the operating system. Windows uses it for Credential Guard, which protects credentials like NTLM hashes and Kerberos tickets from theft (Microsoft), and for memory integrity, also called HVCI, which makes it much harder to load malicious code into the kernel (Microsoft). Newer versions of Windows turn Credential Guard on by default when the hardware supports it, so turning on VBS in the VM may be most of the work.

In VCF, VBS is a checkbox in the VM’s settings, and you then turn on the features you want inside Windows (VBS best practices). You don’t need to install the Hyper-V role in the guest, because Windows handles that itself. It needs EFI firmware and Secure Boot, along with virtual hardware version 14 or later on Intel hosts, or 19 or later on AMD hosts. Plan for the trade-offs:

• Some features don’t mix with VBS. Fault Tolerance, PCI passthrough (which also impacts how GPUs might be consumed), and hot-adding CPU or memory aren’t supported on VBS-enabled VMs.
• Performance depends on the CPU. Memory integrity runs best on newer processors with hardware support for it, where the overhead tends not to be noticeable and is worth the trade-off even when it is, but test with your own workloads.
• Drivers matter. Memory integrity can block incompatible drivers, so test before rolling it out widely.

VBS walls are built by the guest’s own hypervisor, which runs on top of ESX, so VBS doesn’t protect a guest from someone who controls the host; Microsoft says as much about memory integrity. Protecting a VM’s memory from the host is a job for confidential computing.

Choose Where to Encrypt

Physical servers usually get disk encryption from the operating system, like BitLocker on Windows or LUKS on Linux, with keys protected by the server’s TPM. VMs with a vTPM can work the same way. In VCF, though, encrypting inside every guest usually isn’t necessary. vSAN data-at-rest encryption encrypts every VM’s disks without any changes to the guests and keeps vSAN’s compression and deduplication savings. Our post on storage encryption covers this, along with VM encryption for other storage.

vSAN encryption protects the data on the drives, but it’s transparent to anything that reads through the hypervisor, so someone who can clone a VM or download its files through vCenter gets readable data. Encrypting inside the guest adds a layer against that for the VMs that hold the keys to everything else, like domain controllers, certificate authorities, and secrets vaults. For those:

• Give them a vTPM. BitLocker protects its keys with a TPM, and LUKS can, too, so give guests that encrypt their disks a vTPM, just as you’d give a physical server a TPM.
• Add a BitLocker pre-boot PIN for the most critical VMs. Someone with enough privileges in vCenter can clone a VM and start the copy, and because the clone gets a copy of the vTPM, BitLocker unlocks it, too, unless it needs a PIN at startup. The PIN has to be entered after every restart, so save it for systems like domain controllers, where that operational trade-off is worth it.
• Control who can decrypt, and who can copy. Encryption only helps if the people who shouldn’t see the data also don’t hold the cryptographic privileges. So give most administrators the built-in No Cryptography Administrator role and keep cryptographic privileges with a small group (docs). Privileges that copy a VM, like cloning, exporting, and downloading files from a datastore, deserve the same care.
• Weigh the costs. Data encrypted inside the guest doesn’t compress or deduplicate, on vSAN or in your backup system. Every guest also needs its own recovery keys, stored somewhere you can reach when that VM is down, and for domain controllers, that shouldn’t be only the Active Directory they serve. The encryption also uses some guest CPU, so double-encrypting data on disk needs to be tested and thought through.

VM Security Settings: What’s Already Done and What to Change

Older hardening guides were full of VM settings to change. Many of those are now the defaults, and the VCF Security Configuration Guide lists them so you can audit them instead of setting them again. Copy, paste, and drag-and-drop between the console and the guest are off, as are disk shrinking, disk wiping, and connecting or disconnecting devices from inside the guest, and guests can’t read details about the host they run on. If you find any of them turned back on, find out why.

A handful of VM security settings still need changing:

• Limit console connections. Set RemoteDisplay.maxConnections to 1, so nobody can watch an administrator’s session through a second console connection. Keep in mind, though, that if your session is disconnected via network instability you might have to wait until it times out to reconnect.
• Lock the console on disconnect. For Windows guests, set tools.guest.desktop.autolock to TRUE, so closing the console doesn’t leave a logged-in session for the next person.
• Boot only from disk. Set bios.bootDeviceClasses to allow:hd, and allow the CD drive only while you’re installing an operating system.
• Remove hardware you don’t use. Every virtual device is code that a guest can talk to. When a critical vulnerability turned up in virtual USB controllers, the workaround was removing USB controllers from VMs (VMSA-2024-0006). Test first, because some devices are less optional than they look; removing the USB controller can affect console input in some guests, for example.
• Keep virtual hardware current. The guide recommends hardware version 17 or later. Newer virtual hardware versions have performance and security improvements, as well as better compatibility with new physical hardware.
• Set encrypted vMotion to Required for sensitive VMs. The default, Opportunistic, already encrypts migrations whenever both hosts support it, which current hosts do, and Required makes sure a migration is never sent in the clear (docs). Adding a vTPM or VM encryption switches a VM to Required automatically. Set encrypted Fault Tolerance to Required, too, for VMs that use it.

Lock Down VMware Tools

VMware Tools matters for VM security, too, and it has security settings of its own in each guest’s tools.conf file. The VCF Security Configuration Guide covers them, and you can change each one with the VMwareToolboxCmd utility that comes with Tools, as in “VMwareToolboxCmd config set guestoperations disabled true”, or by editing tools.conf. These are the ones to change:

• Turn off guest operations where you don’t need them. Guest operations let vCenter run commands, move files, and list processes inside a guest. This makes them handy for automation and just as handy for an attacker who gets into vCenter. Many backup, disaster recovery, and automation tools depend on them, so check first, and leave them on in templates, because guest customization needs them.
• Prevent re-customization of deployed VMs. Guest customization can run scripts as root or Administrator, so someone with access to vCenter could use it on a deployed VM to reset the Administrator password or add an account of their own. Set deployPkg enable-customization to false once a VM is deployed, unless something like a disaster recovery plan uses customization to change its IP address. Leave it on in templates, or the VMs you deploy from them won’t customize.
• Turn off inventory features you don’t use. Application, service, and container discovery (appinfo, servicediscovery, and containerinfo) report what’s running in a guest to vCenter, where tools like VCF Operations use the data for application monitoring and dependency mapping. Leave them on where you use that data, and turn them off everywhere else.
• Keep upgrades from changing features. Set autoupgrade allow-add-feature and allow-remove-feature to false, so automatic upgrades patch the Tools features you have without adding or removing any. Set gueststoreupgrade policy to off unless you deliver Tools upgrades through GuestStore.
• Send Tools logs to the guest’s system log. Set the Tools logging handlers to syslog, which routes Tools activity to syslog on Linux and the event log on Windows, so whatever already ships the guest’s logs picks it up, too.
• Keep VMware Tools current. It’s software like any other, and our post on patching applies to it, too. Linux distributions ship open-vm-tools, which updates with the rest of the guest’s packages, and for Windows, leave automatic Tools upgrades on unless you update Tools another way.

A few Tools settings are already where the guide wants them, like GlobalConf, which can push tools.conf changes to guests from a central source and is off by default, so audit those. The guide’s PowerCLI scripts audit and remediate the VM settings in the previous section and check whether Tools is current (tools). But tools.conf lives inside each guest, so set these with the configuration management you already use for the guest operating system.

Make VM Security Features the Default

The easiest VM security is the kind nobody has to remember. Build these features into your templates and content libraries: EFI firmware, Secure Boot, a current hardware version, a vTPM for Windows, VBS where the workload supports it, unneeded devices removed, and the recommended Tools settings in place. Leave guest operations and customization on, though, because templates need them. New VMs then start out with these protections in place, and the work shifts to the VMs that already exist.

For those, start your VM security work with the VMs that matter most, like domain controllers, certificate authorities, secrets vaults, and anything else an attacker would love to copy, and work outward from there. Every VM you bring up to date is one less easy target.