What Is a Trusted Platform Module (TPM)

Introduction

When Microsoft announced that Windows 11 would require a Trusted Platform Module (TPM) 2.0, millions of users discovered their hardware was incompatible — and many had no idea what a TPM was or why it mattered. The backlash was significant: people resented being forced to buy new computers for a feature they didn’t understand. But the requirement was not arbitrary. A TPM fundamentally changes what security guarantees are possible on a PC. Without it, encryption keys for BitLocker live in software where sophisticated malware can extract them. Without it, there is no way for a remote server to verify that a laptop has not been tampered with before you connect it to a corporate VPN. Without it, Credential Guard — which protects Windows login credentials against pass-the-hash attacks — cannot function. Understanding what a TPM actually does, what it protects against, and what it cannot do gives you the technical foundation to make informed decisions about hardware security in enterprise environments.

What Is a Trusted Platform Module?

A Trusted Platform Module (TPM) is a dedicated cryptographic microcontroller that provides a hardware-isolated environment for generating, storing, and using cryptographic keys, certificates, and random numbers. It also measures the integrity of the platform’s boot process and stores those measurements in Platform Configuration Registers (PCRs) — tamper-evident logs of what software ran during startup.

TPMs are defined by the Trusted Computing Group (TCG) specification and standardized as ISO/IEC 11889. They come in three physical forms: a discrete TPM (a separate chip on the motherboard), a firmware TPM (fTPM) (implemented in firmware running on the CPU’s management engine, such as AMD PSP or Intel ME), or an integrated TPM (built directly into the CPU silicon). All three present the same software interface but have different security properties.

The essential property is hardware isolation: private keys generated inside the TPM cannot be extracted by software, even by code running at ring 0 (the OS kernel) or in the hypervisor. The TPM performs cryptographic operations internally and returns only the result — the private key material never traverses the system bus in plaintext.

How a Trusted Platform Module Works

The TPM’s security model is built around three key capabilities:

1. Sealed storage: The TPM can seal (encrypt) data — such as a disk encryption key or an application credential — against a specific set of PCR values. The data can only be unsealed (decrypted) when the platform is in exactly the same measured state as when sealing occurred. If the boot chain changes — a different bootloader, a different OS, a modified firmware — the PCR values change and the sealed data becomes inaccessible.

2. Key generation and binding: The TPM contains a hardware random number generator and can generate RSA or ECC key pairs internally. Key binding ties a key to the TPM itself — the private key never leaves the chip. Applications send data to the TPM for signing or decryption; the TPM performs the operation and returns the result.

3. Remote attestation: The TPM can generate a cryptographically signed quote of its current PCR values, signed by an Attestation Key (AK) that is itself certified by the TPM’s Endorsement Key (EK). The EK has a manufacturer-signed certificate proving it belongs to a genuine TCG-certified TPM. A remote server can verify the quote, the AK certificate, and the EK certificate to confirm: “This is a real TPM, and the software state measured in these PCRs is what was actually running.”

The PCR measurement process works as follows during boot:

• The CPU firmware (UEFI) starts and extends PCR[0] with a measurement (hash) of the firmware itself.
• The bootloader is measured and extends PCR[4].
• The OS kernel is measured and extends PCR[8]–PCR[9].
• Each extension is irreversible: PCR[n] = SHA-256(PCR[n] || new_measurement). By the time the OS is running, PCRs contain a chain of hashes representing the entire boot path.

VIDEO · READY 16:9

PLAY

Trusted Platform Module (TPM) — Computerphile

Discrete TPM vs Firmware TPM vs Software TPM

Real-World Use Cases

BitLocker full disk encryption: Windows BitLocker uses the TPM to seal the Volume Master Key (VMK) to specific PCR values representing a trusted boot state. When the PC boots, the TPM measures the firmware and bootloader. If they match the expected state, the TPM unseals the VMK and BitLocker decrypts the drive transparently. If someone removes the hard drive and puts it in another machine — or modifies the bootloader to run malware — the PCR values change, the TPM refuses to unseal the VMK, and the drive remains encrypted. This is the core defence against evil maid attacks. For more on how full disk encryption works, see Full Disk Encryption: BitLocker and FileVault Explained.

Windows Credential Guard: Windows Credential Guard uses the TPM in combination with virtualization-based security (VBS) to store NTLM password hashes and Kerberos tickets in an isolated enclave. Even if an attacker achieves kernel-level access, they cannot extract credentials because the credential store lives in a separate hardware-isolated execution environment. This directly defeats pass-the-hash attacks, which were previously devastating in Active Directory environments.

Device identity in enterprise MDM: Modern endpoint management platforms — Microsoft Intune, Jamf, VMware Workspace ONE — use TPM-backed device attestation to verify that connecting devices are genuine, uncompromised corporate hardware. The MDM platform requests a TPM quote during device enrollment, verifies the EK certificate against the manufacturer’s CA, and stores the AK for ongoing health attestation checks. Devices that fail attestation are quarantined before they can access sensitive resources.

Common Mistakes to Avoid

Assuming the TPM protects against post-boot attacks: The TPM measures the boot chain and seals secrets to it. Once the OS is running and the sealed keys are unsealed, the TPM’s job is largely done. A piece of malware running after boot cannot easily steal BitLocker keys from the TPM — but it can read the decrypted filesystem directly. The TPM protects against cold-boot attacks and physical drive theft, not against OS-level compromise.

Ignoring discrete TPM bus-sniffing attacks: Researchers from Dolos Group demonstrated in 2021 that a BitLocker-encrypted laptop with a discrete TPM could be defeated by soldering probe leads onto the LPC bus and reading the Volume Master Key in plaintext as it transits from the TPM to the CPU during boot. This attack requires physical access and specialized equipment but is well within the reach of a sophisticated attacker with a stolen device. Mitigations include using a TPM PIN (so the key is only released after PIN input, not automatically on boot) and preferring fTPMs which eliminate the external bus.

Not setting a TPM PIN for high-value data: BitLocker’s default configuration in many environments is “TPM-only” — the disk decrypts automatically on boot with no user interaction. This is convenient but means a stolen laptop can be booted and accessed. Adding a BitLocker PIN (which must be entered before the TPM unseals the VMK) protects against this scenario at the cost of requiring user interaction at every boot.

Skipping TPM provisioning in enterprise deployments: A factory-reset or newly deployed PC may have the TPM in an uninitialized state. Enterprise imaging processes must include TPM initialization (taking ownership, clearing old keys, and establishing the Storage Root Key hierarchy) as part of the deployment workflow. Unprovisioned TPMs may prevent BitLocker or Credential Guard from working correctly.

Getting Started

To put your TPM to work:

First, verify TPM presence and version. On Windows, run tpm.msc (TPM Management Console) or check Device Manager → Security Devices. On Linux, check for /dev/tpm0 and use the tpm2-tools package to inspect the TPM. Confirm it is TPM 2.0 — TPM 1.2 devices lack the algorithm agility and architecture needed for modern workloads.

Second, enable Secure Boot alongside the TPM. Secure Boot and the TPM work together to establish a hardware root of trust — Secure Boot prevents unsigned bootloaders from running, while the TPM measures what actually ran. Enable both in UEFI firmware settings. Without Secure Boot, an attacker can substitute a malicious bootloader that passes the TPM measurement stage by pre-computing modified PCR values.

Third, for BitLocker, configure a PIN or startup key. In Group Policy, navigate to Computer Configuration → Administrative Templates → Windows Components → BitLocker Drive Encryption and configure “Require additional authentication at startup.” Choose TPM + PIN for the best balance of security and usability. This prevents automatic decryption of stolen devices.

Fourth, use TPM attestation for conditional access. If you use an MDM platform, enable Device Health Attestation — in Intune this is the “Require the device to be reported as healthy” compliance policy setting. This ensures only devices with a healthy, measured boot state can access corporate resources. For the hardware isolation concepts that complement TPM, see Hardware Security Modules: HSM vs KMS Explained and Encryption Key Rotation: When and How to Rotate Securely.