Secure Boot and vTPM

Introduction to Secure Boot and vTPM

Secure Boot and the virtual Trusted Platform Module (vTPM) are firmware-level security features you can enable on zCompute images and VM instances.

UEFI Secure Boot

UEFI Secure Boot is a firmware feature that only allows a boot loader, kernel, or driver to execute if it is digitally signed with a signature that the firmware already trusts.

Anything unsigned, or appears as blocked is refused. Only explicitly signed and approved software (boot loader, kernel, drivers) is allowed to run. Any of these components is first checked against a blacklist (DBX). If it’s not in the blacklist, it’s checked against a whitelist (DB).

This closes off bootkit and rootkit classes of attack that install themselves before either the operating system or any in-guest security tooling have a chance to run.

vTPM

A vTPM is a virtualized Trusted Platform Module 2.0 device. It is presented to the guest operating system as though it were physical hardware.

The vTPM provides a hardware root of trust equivalent for the guest operating system. This allows the system to perform three main tasks:

• Record boot measurements: It logs exactly what software loads during the boot process.

• Seal encryption keys: It locks cryptographic keys so they only open if the boot configuration remains safe and unmodified.

• Support attestation: It helps prove the integrity and identity of the system.

In zCompute, Secure Boot and vTPM capabilities are exposed together as a single control, rather than as independent settings. Selecting one always selects the other.

Prerequisites for Secure Boot and vTPM

• zCompute version 25.06.1 or later

  Secure Boot + TPM is not available on earlier versions.

• A UEFI-installed guest

  The guest operating system must already be installed in UEFI mode. Secure Boot cannot be retrofitted onto a BIOS-installed disk by changing the firmware setting alone.

  See Firmware and Secure Boot Change Compatibility for what happens if the two are mismatched, and Image Creation for preparing a UEFI-based image.

• A guest operating system that supports Secure Boot

  Standard Linux cloud images (Ubuntu, RHEL, AlmaLinux, Rocky, Debian, Oracle Linux, SLES) ship a bootloader already signed with a key that the firmware trusts, and need no extra preparation.

  Windows 11 will not install at all without UEFI, Secure Boot, and TPM 2.0. Windows Server 2025 increasingly expects them as well.

  Earlier Windows versions support Secure Boot, but do not require it.

• Signed drivers

  On Windows, use the signed VirtIO driver build. An unsigned build is refused once Secure Boot is enforcing.

  On Linux, any out-of-tree or self-built kernel module must have its signing key enrolled with the distribution’s Machine Owner Key (MOK) tooling before Secure Boot is enabled on a system that depends on it.

Windows Instances and Secure Boot + vTPM

Windows 11 will not install at all without UEFI, Secure Boot, and TPM 2.0. Windows Server 2025 increasingly expects them as well. Selecting Secure Boot + TPM when creating the VM instance satisfies all three requirements at once.

Before You Start

• Use a UEFI Windows image. A Windows disk installed the legacy BIOS way will not boot with Secure Boot turned on. See Firmware and Secure Boot Change Compatibility.

• The VirtIO storage and network drivers must be the signed builds. Unsigned drivers are refused once Secure Boot is configured.

Checking Secure Boot on Windows

Connect to the instance with RDP or the console, open PowerShell as Administrator, and run:

Confirm-SecureBootUEFI
Get-Tpm

• Confirm-SecureBootUEFI should return True.

• Get-Tpm should report TpmPresent: True and TpmReady: True.

For a graphical check, run tpm.msc and look for The TPM is ready for use with Specification Version 2.0, or run msinfo32 and confirm that BIOS Mode reads UEFI and Secure Boot State reads On.

BitLocker

Before Capturing a Windows Image

Run:

sysprep /generalize /oobe /shutdown

and suspend or turn off BitLocker first. Skipping this means that every VM instance later created from the captured image inherits the same machine identity and the same TPM binding, which that new instance cannot use.

Linux Instances and Secure Boot + vTPM

The standard Linux cloud images (Ubuntu, RHEL, AlmaLinux, Rocky, Debian, Oracle Linux, and SLES) all work with Secure Boot immediately. They ship a bootloader that is already signed with a key that the firmware trusts, so there is nothing to configure.

Checking Secure Boot on Linux

SSH into the instance and run:

mokutil --sb-state
ls /sys/class/tpm/

• mokutil --sb-state should output SecureBoot enabled

• ls /sys/class/tpm/ should list a tpm0 device

To read the measured-boot values, install tpm2-tools and run:

tpm2_pcrread sha256:0,4,7

Key was rejected by service

Best Practices for Secure Boot and vTPM

• Decide at build time, not retrofit time

  Set Firmware Type to UEFI and select Secure Boot + TPM when the image or VM instance is created, rather than after the guest operating system is already installed.

  Retrofitting a BIOS-installed guest means rebuilding it, and not flipping a switch. See Firmware and Secure Boot Change Compatibility.

• Snapshot before changing firmware on a live guest

  A firmware or Secure Boot change on an existing VM instance is not validated against the actual disk layout. The console will let you make a change that leaves the guest unable to boot. Take a snapshot first so you have a way to recover.

• Verify the actual state

  An image or instance’s Firmware Type value alone can look identical whether or not Secure Boot + TPM is enabled. Confirm the real state using the dedicated column or panel. See Viewing an Image’s Firmware and Secure Boot Status and Viewing a VM Instance’s Firmware and Secure Boot Status.

• Treat encryption keys as entirely your own responsibility

  Caution

  Disk Encryption Responsibility

  If the virtual TPM is used for disk or volume encryption, for example Windows BitLocker, the user/customer has sole and absolute responsibility for keeping the encryption key and recovery key. Zadara does not have access to these keys and cannot be responsible for them or recover the encrypted data if they are lost.

• Follow the OS-specific guidance before you enable Secure Boot on an existing system, or capture an image for reuse

  See Windows Instances and Secure Boot + vTPM and Linux Instances and Secure Boot + vTPM for the exact verification commands and the pitfalls specific to each guest OS.

• Test on a disposable instance first

  Before enabling Secure Boot + TPM on a production workload, validate the change on a snapshot or a throwaway instance, particularly if the guest uses any driver or bootloader that you did not verify is signed.

Troubleshooting Secure Boot and vTPM

For the UI steps to check or change a setting, see Modify a VM Instance, Viewing an Image’s Firmware and Secure Boot Status, and Viewing a VM Instance’s Firmware and Secure Boot Status.

The Secure Boot + TPM checkbox does not appear

Set Firmware Type to UEFI first. The checkbox is hidden when Firmware Type is BIOS or is left blank.

The guest does not boot after Secure Boot is enabled

The firmware refused to execute a bootloader or kernel that is not signed by a trusted key.

Most often this occurs because the guest was installed under BIOS rather than UEFI, or because the bootloader itself is unsigned or self-signed.

See the compatibility outcomes in Firmware and Secure Boot Change Compatibility.

A driver fails to load after Secure Boot is enabled (Linux)

The kernel refuses to load a module whose signature is not in its trusted key database.

This is common with out-of-tree modules such as DKMS-built drivers.

See Linux Instances and Secure Boot + vTPM for the exact symptom.

Windows setup refuses to continue, citing unmet requirements

Windows 11 and Windows Server 2025 check for UEFI, Secure Boot, and TPM 2.0 before the installer will proceed, and this check cannot be satisfied mid-installation.

The VM instance must have Secure Boot + TPM selected before the installer is run, and not afterwards.

See Windows Instances and Secure Boot + vTPM.

Disk encryption asks for a recovery key

A vTPM seals its encryption key to a specific, expected boot configuration made up of the firmware type, Secure Boot state, and the measured boot chain. Any change to that configuration, including disabling Secure Boot, invalidates the seal, and the encrypted volume falls back to requiring the recovery key. This is the expected behavior. See Windows Instances and Secure Boot + vTPM and the encryption-responsibility note in Modify a VM Instance.

Two images or instances look identical, but only one has Secure Boot

The Firmware Type value alone does not distinguish a Secure Boot image or instance from a plain UEFI one. Both display as UEFI. Use the dedicated Secure Boot indicator described in Viewing an Image’s Firmware and Secure Boot Status and Viewing a VM Instance’s Firmware and Secure Boot Status instead.

A Firmware Type or Secure Boot change does not seem to take effect

The new setting is applied only at the next full stop and start of the VM instance. A reboot initiated from inside the guest operating system does not apply it.