# 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](vm-common-operations.md#firmware-change-compatibility) for what happens if the two are mismatched, and [Image Creation](machine-images.md#newimage-ref) 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](vm-common-operations.md#firmware-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: ```powershell 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: ```console 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: ```console 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: ```console tpm2_pcrread sha256:0,4,7 ``` ## 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](vm-common-operations.md#firmware-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](machine-images.md#viewing-image-firmware-status) and [Viewing a VM Instance’s Firmware and Secure Boot Status](vm-operations.md#viewing-instance-firmware-status). * **Treat encryption keys as entirely your own responsibility** * **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](#windows-instances-secure-boot) and [Linux Instances and Secure Boot + vTPM](#linux-instances-secure-boot) 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](vm-common-operations.md#modify-vm-instance), [Viewing an Image’s Firmware and Secure Boot Status](machine-images.md#viewing-image-firmware-status), and [Viewing a VM Instance’s Firmware and Secure Boot Status](vm-operations.md#viewing-instance-firmware-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](vm-common-operations.md#firmware-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](#linux-instances-secure-boot) 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](#windows-instances-secure-boot). ### 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](#windows-instances-secure-boot) and the encryption-responsibility note in [Modify a VM Instance](vm-common-operations.md#modify-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](machine-images.md#viewing-image-firmware-status) and [Viewing a VM Instance’s Firmware and Secure Boot Status](vm-operations.md#viewing-instance-firmware-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.