Windows 11 TPM 2.0 as the Hardware Root of Trust for VBS and BitLocker

Problem

Windows 11 refuses to install or run on systems that lack a TPM 2.0 chip and UEFI Secure Boot. Administrators trying to deploy the OS on older hardware need to understand what these requirements actually protect, where the trust boundary lies, and what operational checks confirm that the protection is active.

Requirements

The core security goals that drive the TPM 2.0 mandate are:

• Establish a hardware‑rooted measurement of the early boot firmware (UEFI, bootloader, OS kernel).
• Provide sealed storage that releases secrets only when the measured state matches a known‑good baseline.
• Enable a hypervisor that can isolate critical code (HVCI) and protect credentials (Windows Hello for Business) from kernel‑level attacks.

These goals cannot be met with software‑only attestation because an attacker who controls the OS could falsify measurements. A discrete TPM 2.0 chip, isolated from the main CPU, provides the needed tamper‑evident root of trust.

Smallest Suitable Design

The minimal set of components that satisfies the requirements is:

1. TPM 2.0 – implements PCRs (Platform Configuration Registers) that accumulate hash measurements during boot, and offers sealed storage for BitLocker keys and VBS secrets.
2. UEFI Secure Boot – ensures that only signed UEFI firmware, bootloaders, and early OS components execute, preventing unsigned code from injecting false measurements into the TPM.
3. Virtualization‑based Security (VBS) – a hypervisor layer (Hyper‑visor) that runs in a protected mode, using the TPM‑sealed keys to launch HVCI and Credential Guard.
4. BitLocker – uses the TPM to seal the volume master key; decryption proceeds only if PCR values match the baseline.

No additional software components are required for the root of trust; the OS relies exclusively on the hardware measurements provided by the TPM and the integrity guarantees of Secure Boot.

Trust and Data Boundaries

The trust boundary is drawn at the interface between the CPU/OS and the TPM:

• Inside the boundary: TPM firmware, PCRs, sealed storage, and the endorsement key (EK) that is unique to the chip.
• Outside the boundary: UEFI firmware, bootloaders, Windows kernel, user applications, and any peripheral devices.

Data that crosses the boundary includes:

• Boot measurements (hashes of firmware, bootloader, OS extensions) extended into PCRs.
• Sealed secrets (BitLocker keys, VBS protection keys) released only when PCR values match the expected policy.
• Attestation quotes (signed PCR digests) that can be presented to external services (e.g., Device Health Attestation) to prove platform integrity.

Operational Checks

Administrators can verify that the trust chain is intact using built‑in tools. All commands should be run from an elevated PowerShell prompt (Run as Administrator).

1. Confirm TPM Presence and Version

Get-TPM

Expected output includes SpecVersion : 2.0. If the command returns TpmPresent : False or a SpecVersion of 1.2, the hardware does not meet the Windows 11 requirement.

2. Verify Secure Boot State

Open msinfo32 or run:

Confirm-SecureBootUEFI

A return value of True indicates Secure Boot is enabled. In msinfo32 look for Secure Boot State = On.

3. Check that VBS is Running

systeminfo | findstr /B /C:"Virtualization-based security"

Expected output: Virtualization-based security: Running. If it shows Not enabled, VBS may be disabled by policy or hardware limitations.

4. Examine PCR Values (Optional)

To see the current measurements:

tpmtool getpcrinfo

This requires the TPM 2.0 Tools package. Compare the displayed PCR values with the baseline known from a clean install; any unexpected change warrants investigation.

Failure Modes

When any part of the trust chain breaks, the security guarantees degrade:

• TPM malfunction – If the TPM cannot extend PCRs or release sealed storage, BitLocker will enter recovery mode and VBS features (HVCI, Credential Guard) will fail to start. The system may boot but with reduced protection.
• Secure Boot bypass** – Firmware attacks that replace or disable signature validation allow unsigned bootloaders to inject false measurements, causing the TPM to seal secrets to a compromised state. An attacker could then extract BitLocker keys or disable VBS.
• Misconfiguration** – Group Policy that turns off LsaCfgFlags (Credential Guard) or HVCI settings, or enabling AllowUnsignedBoot in UEFI, will cause VBS to report Not running even though the TPM is healthy.
• Side‑channel or physical tampering** – Advanced attacks that probe the TPM chip (e.g., voltage glitching) could extract the endorsement key, undermining the sealing mechanism.

In each failure mode, the OS will typically log an event in the Microsoft-Windows-TPM/Operational channel or show a warning in the Windows Security app.

Conditions That Would Change the Design

The current design assumes that a discrete TPM 2.0 chip is the only viable hardware root of trust. The design would be revisited if:

• Microsoft releases a Windows 11 SKU that accepts a firmware‑based TPM (fTPM) with equivalent security properties and updates the attestation policies accordingly.
• A new industry standard (e.g., ISO/IEC 11889‑4) defines a different hardware root of trust that can provide sealed storage and PCR‑like measurements, and Microsoft adopts it as a replacement for TPM 2.0.
• Software‑only attestation advances to a point where measurable properties (such as CPU‑based enclave attestation) can be trusted without a discrete TPM, prompting a policy shift for certain low‑risk devices.

Until such changes occur, administrators should treat the TPM 2.0 + Secure Boot pair as a non‑negotiable foundation for VBS and BitLocker on Windows 11.

Practical Verification Checklist

1. Run Get-TPM – verify SpecVersion : 2.0 and TpmPresent : True.
2. Run Confirm-SecureBootUEFI – expect True or check msinfo32 for Secure Boot State = On.
3. Run the VBS check command – expect Virtualization-based security: Running.
4. If BitLocker is enabled, open the BitLocker management UI and confirm that TPM is listed as the key protector.
5. Review the TPM Operational event log for any errors or warnings.

If any step fails, remediate the underlying issue (e.g., update firmware to enable TPM 2.0, re‑enable Secure Boot in UEFI, or adjust Group Policy) before relying on VBS or BitLocker for protection.