What Is a Trusted Platform Module (TPM)?

What Is TPM 2.0?

A Trusted Platform Module (TPM) is a dedicated microcontroller designed to secure hardware through integrated cryptographic keys. Found on the motherboard of most modern laptops, desktops, and servers, the TPM provides a hardware root of trust — an isolated environment where secrets can be generated, stored, and used without ever being exposed to the operating system or application software.

The TPM specification is maintained by the Trusted Computing Group (TCG), an industry consortium that includes Intel, AMD, Microsoft, IBM, and other major technology companies. The current standard, TPM 2.0, was published in 2014 and ratified as an international standard under ISO/IEC 11889:2015. It replaced the earlier TPM 1.2 specification, which had been in use since 2003.

At its core, a TPM is a tamper-resistant chip that can generate and store cryptographic keys, perform hashing and signing operations, generate true random numbers, and measure the integrity of the platform it is attached to. The key distinction from software-based security is that the TPM's secrets are protected by physical hardware boundaries. Even if an attacker gains full control of the operating system, they cannot extract the private keys stored inside the TPM.

TPM 1.2 vs TPM 2.0

TPM 1.2 was limited in significant ways. It supported only SHA-1 for hashing and RSA for asymmetric cryptography, both of which are now considered insufficient for long-term security. TPM 2.0 introduced algorithm agility, meaning the specification is not tied to any single cryptographic algorithm. TPM 2.0 supports SHA-256, SHA-384, ECC (including NIST P-256 and P-384), and can accommodate new algorithms as standards evolve.

Beyond cryptographic improvements, TPM 2.0 introduced a more flexible authorization model with enhanced authorization (EA) policies. These allow complex, composable access conditions: you can require a password AND a specific external signature AND a set of PCR values before the TPM will perform an operation. TPM 1.2 only supported simple password-based authorization.

TPM 2.0 also reorganized the key hierarchy into distinct platform, storage, and endorsement hierarchies, providing cleaner separation of concerns for different use cases.

How TPM Works: Architecture and Key Concepts

Understanding TPM requires familiarity with a few core architectural elements. These components work together to provide the TPM's security guarantees.

Endorsement Key (EK)

The Endorsement Key is a unique RSA or ECC key pair burned into the TPM during manufacturing. The private portion of the EK never leaves the chip — it cannot be read, exported, or modified. The EK serves as the TPM's identity: by verifying the EK certificate against the manufacturer's root CA (Intel, Infineon, STMicro, Nuvoton, or AMD), you can confirm that the TPM is genuine hardware rather than a software emulator. This verification is the foundation of remote attestation.

Storage Root Key (SRK)

The Storage Root Key sits at the top of the TPM's key hierarchy. All other keys stored in the TPM are ultimately encrypted (wrapped) under the SRK. When you create a new signing key or encryption key, the TPM generates it internally and encrypts it under the SRK before storing the wrapped blob externally. Only the same TPM, with the same SRK, can unwrap and use that key. This means you can store millions of keys on disk, but none of them are usable without the specific TPM that created them.

Platform Configuration Registers (PCRs)

PCRs are a set of special registers inside the TPM that record measurements of the system's state. During the boot process, each component (UEFI firmware, bootloader, OS kernel) extends the relevant PCR by hashing its code and combining it with the existing PCR value. The key property of PCRs is that they can only be extended, never directly written. This creates a tamper-evident chain: if any component in the boot sequence changes, the resulting PCR values will be different.

PCRs enable two powerful capabilities. Sealed storage allows you to encrypt data so it can only be decrypted when the PCRs match specific values — meaning the system must be in a known-good state. Remote attestation allows a remote party to request a TPM quote (a signed statement of current PCR values) to verify the system's integrity before trusting it.

Platform Hierarchies

TPM 2.0 organizes its resources into three hierarchies, each with its own authorization and purpose:

• Endorsement Hierarchy — rooted at the EK. Used for attestation and identity. Controlled by the TPM manufacturer or platform owner.
• Storage Hierarchy — rooted at the SRK. Used for general-purpose key storage and sealing. This is where most application keys live.
• Platform Hierarchy — controlled by the platform firmware (UEFI/BIOS). Used for firmware-level measurements and early boot security. Typically not accessible to the operating system.

This separation ensures that, for example, a compromised operating system cannot tamper with firmware-level measurements, and application keys remain isolated from platform identity keys.

What Is TPM Used For?

Disk Encryption (BitLocker)

The most widely known use of TPM is Microsoft BitLocker full-disk encryption on Windows. BitLocker stores its volume master key sealed to specific PCR values in the TPM. When the system boots normally and the PCR values match (meaning no firmware or bootloader tampering has occurred), the TPM automatically releases the key and the drive decrypts transparently. If the boot chain is modified — for example, by booting from a USB drive or modifying the BIOS — the PCRs will not match, and the TPM will refuse to release the key. On Linux, similar functionality is available through systemd-cryptenroll with LUKS2 and TPM2 integration.

Secure Boot and Measured Boot

Secure Boot uses cryptographic signatures to verify each component in the boot chain before executing it. The TPM complements this by measuring each component into PCRs, creating a verifiable record of exactly what software ran during boot. Together, they ensure that only authorized code runs at startup and that any tampering is detectable after the fact.

Key Storage and Cryptographic Operations

The TPM functions as a secure keystore. Private keys generated inside the TPM never leave the chip in plaintext. Applications send data to the TPM for signing or decryption, and the TPM returns the result. This protects keys from malware, memory dumps, and physical attacks on the hard drive. Common uses include storing SSH keys, TLS private keys, PKI certificate authority keys, and code signing keys.

Remote Attestation

Attestation allows a remote party to verify that a machine is running expected software on genuine hardware. The TPM signs a quote containing the current PCR values with its Attestation Identity Key (AIK). The verifier checks the signature, confirms the TPM is genuine via the EK certificate chain, and compares the PCR values against known-good measurements. This is foundational for zero trust architectures where machines must prove their integrity before accessing resources.

Windows 11 Requirement

Microsoft made TPM 2.0 a hard requirement for Windows 11, signaling the industry's move toward hardware-rooted security as a baseline. Windows 11 uses the TPM for BitLocker, Windows Hello (biometric authentication), Credential Guard (isolating authentication tokens), and System Guard (firmware integrity). The requirement ensures that all Windows 11 systems have a hardware trust anchor available for the operating system's security features.

TPM in Key Management and HSM Use Cases

While the TPM was originally designed for platform integrity, its ability to securely store and operate on cryptographic keys makes it a powerful building block for key management systems. The challenge is that the raw TPM interface is low-level and complex — it was designed for chip-level operations, not for the kind of workflow-oriented key management that security teams need.

This is exactly the gap that TPM HSM fills. TPM HSM is an open-source project that turns every TPM 2.0 chip into a fully functional hardware security module (HSM). It adds the layers that make TPM practical for real-world key management:

• Multi-party threshold signing — require M-of-N approvals before the TPM will sign, using TPM 2.0 enhanced authorization policies.
• Hardware-enforced signing policies — bind signing operations to specific YubiKey signatures using TPM PolicySigned. Even a compromised server cannot bypass the policy.
• Remote attestation — verify that the TPM is genuine hardware from a known manufacturer before trusting it with your keys.
• X.509 PKI — full certificate management, CSR generation from TPM-protected keys, and certificate chain storage.
• Client-side key wrapping — keys are encrypted on the client using the TPM's public key (RSA-OAEP + AES-128-CFB) before transmission. Only the target TPM can decrypt them.

With these capabilities, a TPM 2.0 chip becomes a viable alternative to dedicated HSM hardware for many use cases — at zero additional cost.

TPM vs HSM: How Do They Compare?

Both TPMs and HSMs provide hardware-isolated cryptographic key storage, but they were designed for different use cases and operate at different scales. Understanding the differences helps you choose the right tool.

For high-volume transaction signing or strict compliance requirements (FIPS 140-2 Level 3), a dedicated HSM may be necessary. But for key storage, code signing, certificate authority operations, and infrastructure security, a TPM 2.0 chip — especially when paired with TPM HSM — delivers hardware-grade protection without the cost, complexity, or vendor lock-in of traditional HSM appliances.