TPM 2.0 explained: secure boot and sealed disk keys

A Trusted Platform Module (TPM) is a small cryptographic processor that ships in almost every business laptop, desktop and server. Windows 11 requires TPM 2.0, Linux distributions can use it to unlock encrypted disks, and cloud providers expose virtual TPMs in their VMs. Yet the TPM is widely misunderstood: it is not a general-purpose vault, it does not stop malware, and "we have a TPM" says little about what is actually protected.

This guide explains what the TPM does, how measured boot ties it to the state of the machine, and how to use it well.

What a TPM is and is not

A TPM 2.0 provides a small set of primitives, defined by the Trusted Computing Group (TCG):

• Protected key storage. Keys are generated inside the TPM or imported and wrapped under a storage root key. Private parts of non-migratable keys never leave the chip in the clear.
• Platform Configuration Registers (PCRs). Registers that can only be extended, never written directly: PCR_new = Hash(PCR_old || measurement). They record what booted.
• Sealing. Encrypting data so the TPM releases it only when PCRs (and optionally a PIN) match a policy.
• Attestation. Signing a quote of PCR values with an attestation key so a remote verifier can check what booted.
• Hardware random number generator and monotonic counters.
• Dictionary-attack protection. Lockout after repeated wrong authorization values, which is what makes a short PIN acceptable.

A TPM is slow and small. It is not designed to perform bulk encryption or to hold thousands of keys, and it has no idea what your operating system does after boot. It is a root of trust for storage and reporting, not an endpoint protection product.

Secure boot versus measured boot

These two mechanisms are complementary and often confused.

Secure Boot stops unsigned code; measured boot creates evidence. Sealing a disk key to PCR values turns that evidence into enforcement: if the boot chain changes, the key is not released.

The PCRs that matter

The PC Client platform firmware profile assigns meanings to the first PCRs. The ones you will meet most often:

Binding to PCR 7 alone means "any boot component signed under the same Secure Boot policy". Binding to PCR 0 and 4 means "exactly this firmware and bootloader binary", which is stricter but breaks on every update. Most deployments bind to PCR 7 (and, with UKIs, to signed PCR 11 policies) and add a PIN.

Read the current values on Linux with the tpm2-tools package:

tpm2_pcrread sha256:0,1,2,3,4,5,7
# Firmware event log, useful to see what produced each measurement
tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | less

On Windows, Get-Tpm in PowerShell reports presence, readiness and ownership, and tpm.msc shows the specification version and manufacturer.

Sealing a disk key

Linux with systemd-cryptenroll

For a LUKS2 volume on a system using systemd:

# Enrol the TPM, bound to Secure Boot state, and require a PIN at boot
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 --tpm2-with-pin=yes /dev/nvme0n1p3

# Keep a recovery key in a separate keyslot and store it offline
sudo systemd-cryptenroll --recovery-key /dev/nvme0n1p3

Then reference the TPM in /etc/crypttab (for example tpm2-device=auto in the options column) and rebuild the initramfs. Test a reboot before closing your session, and keep the passphrase keyslot until the TPM path has been proven.

Windows with BitLocker

BitLocker uses the TPM by default. To add a pre-boot PIN on a device where Group Policy allows it:

manage-bde -status C:
manage-bde -protectors -add C: -TPMAndPIN
manage-bde -protectors -get C:     # confirm the recovery password protector exists

Escrow recovery passwords to your directory (Active Directory or Entra ID) before you need them.

Discrete, firmware and virtual TPMs

The practical conclusion is the same for all of them: TPM-only unlocking is a convenience mode. A pre-boot PIN defeats bus sniffing (the unsealed secret depends on something the attacker does not have) and removes the "boot a stolen laptop to the login screen" scenario. TPM 2.0 also supports encrypted sessions (parameter encryption), which modern bootloaders increasingly use to protect data on the bus.

Secure enclaves and secure elements

Phones and many laptops also contain a dedicated secure subsystem:

• Apple Secure Enclave holds keys for Touch ID, Face ID, passkeys and Data Protection. Keys created there are not exportable.
• Android StrongBox backs the Keystore with a separate secure element on supported devices (Google's Titan M family on Pixel phones, for example); the regular Keystore uses the TrustZone-based TEE.
• Arm TrustZone TEEs run a small trusted OS alongside the main one on many SoCs.

For application developers the rule is the same everywhere: ask the platform keystore to generate a non-exportable key, require user authentication for sensitive operations and check key attestation on the server when it matters.

Attestation in practice

Remote attestation lets a server verify a device before trusting it. The TPM carries an Endorsement Key (EK), usually with a certificate from the TPM manufacturer, which anchors trust in the chip's origin. An Attestation Key (AK) created under it signs PCR quotes. Device health attestation and zero-trust device compliance checks are built on this.

Hardening checklist

1. Confirm the device has TPM 2.0 enabled in firmware and that the OS sees it (Get-Tpm, ls /dev/tpm*).
2. Enable Secure Boot, keep the dbx revocation list updated and use firmware passwords.
3. Use TPM plus PIN for disk encryption on laptops and anything that leaves a secure room.
4. Escrow recovery keys centrally and test recovery once a year.
5. Before BIOS or bootloader updates, suspend protection or plan to re-seal, and document the procedure.
6. Keep TPM firmware updated: vendors have shipped fixes for flaws such as the 2017 ROCA key-generation bug in some TPMs.
7. For fleets, use attestation-based compliance rather than trusting self-reported device state.