A TPM (Trusted Platform Module) is a dedicated security processor on or attached to a motherboard that generates and protects cryptographic keys, records measurements of boot code and can prove to software that the platform has not been tampered with. In hardware, it acts as a small, isolated root of trust that the main CPU and operating system cannot freely read or modify.
The behavior of a TPM is defined by the TPM 2.0 specification from the Trusted Computing Group, later standardized as ISO/IEC 11889. On modern motherboards it appears either as a discrete chip, a plug-in header module or a firmware TPM running inside the processor or chipset, and it works closely with UEFI firmware and Secure boot.
How a TPM protects keys and measures the boot
A TPM protects secrets by keeping private keys inside the module and performing signing, decryption and key derivation internally, so the key material never appears in system memory. Each TPM holds a unique Endorsement Key, certified by the manufacturer, and derives a Storage Root Key that wraps every other key it manages.
The second function is measured boot. Before UEFI firmware hands control to the next stage, it computes a hash of that code and extends a Platform Configuration Register (PCR) with it. Extending means the new value equals the hash of the old value combined with the new measurement, so a PCR cannot be set to an arbitrary value, only accumulated in a fixed order since reset.
Because the final PCR values depend on every measured component, they act as a fingerprint of the boot chain. The TPM can seal a secret to specific PCR values, releasing it only when the platform boots the same firmware, bootloader and configuration. This is how full-disk encryption unlocks automatically on an unchanged machine but asks for a recovery key after tampering.
The following table lists the main internal objects of a TPM 2.0 module and the role each plays.
| Object | What it is | Typical use |
|---|---|---|
| Endorsement Key | Unique key pair burned in at manufacture | Proves the TPM is genuine |
| Storage Root Key | Top key of the storage hierarchy | Wraps keys stored outside the TPM |
| Attestation key | Signing key derived for quoting | Signs PCR reports for remote checks |
| PCRs | Usually 24 hash registers per bank | Record the boot chain measurements |
| NV index | Small protected nonvolatile storage | Holds counters, policies, certificates |
| Random number generator | Hardware entropy source | Seeds keys and nonces |
Discrete, firmware and integrated TPM implementations
TPM implementations differ in physical isolation, not in the commands they accept. A discrete TPM (dTPM) is a separate chip connected over the LPC or SPI bus, often soldered to the board or fitted to a dedicated header. A firmware TPM (fTPM) runs in a protected execution environment of the processor, such as the security processor on AMD platforms or the Platform Trust Technology on Intel platforms.
The table below compares the common forms found on consumer and business motherboards.
| Type | Where it runs | Strength | Weakness |
|---|---|---|---|
| Discrete TPM | Separate certified chip | Tamper-resistant, independent of CPU | Bus traffic can be sniffed |
| Firmware TPM | CPU or chipset security engine | No extra cost, fast | Shares silicon with the host |
| Integrated TPM | Dedicated security core in the SoC | Isolated yet close to the CPU | Depends on vendor design |
| Virtual TPM | Hypervisor software | Gives each virtual machine a TPM | Trust rests on the host |
Discrete chips are often certified to Common Criteria or FIPS 140 levels, which matters for regulated environments. Firmware TPMs are adequate for most desktop use, but their security depends on the processor vendor’s firmware, and several historical vulnerabilities affected exactly that layer.
TPM compared with Secure boot, UEFI and other security hardware
A TPM records and attests, while Secure boot enforces. Secure boot is a UEFI policy that refuses to run code without a trusted signature; the TPM does not block anything but records what ran so that keys and remote verifiers can react. The two are complementary, and many operating systems expect both.
| Mechanism | Main job | Blocks bad code | Holds keys |
|---|---|---|---|
| TPM | Measure, seal and attest | No | Yes |
| Secure boot | Verify signatures before execution | Yes | Only signature databases |
| UEFI firmware | Initialize hardware and start the loader | Through Secure boot | No |
| Hardware security module | High-volume key operations in servers | No | Yes, at far higher capacity |
| Smart card | Portable user credential | No | Yes, tied to a person |
A TPM is also not a cryptographic accelerator. It is deliberately slow, often needing tens to hundreds of milliseconds for an RSA signature, because it is designed for a small number of high-value operations rather than bulk encryption. Disk encryption itself runs on the CPU; the TPM only protects the key that unlocks it.
Practical uses and configuration on a motherboard
The most common uses are full-disk encryption key protection, Windows Hello and passkey storage, device health attestation in managed fleets and secure credential storage for VPN and certificate-based login. Windows 11 made TPM 2.0 a baseline requirement, which moved the module from an enterprise option into mainstream motherboards.
On most boards the TPM is configured in UEFI setup. The decision table below summarizes typical choices.
| Situation | Recommended setting | Reason |
|---|---|---|
| Home desktop with recent CPU | Enable firmware TPM | Meets OS requirements at no cost |
| Regulated business laptop | Use certified discrete TPM | Audit and certification needs |
| Older board with TPM header | Fit a matching TPM 2.0 module | Pin layouts differ by vendor |
| Replacing the CPU on fTPM | Suspend disk encryption first | fTPM keys may be lost |
| Linux server | Enable TPM 2.0, use tpm2-tools | Supports sealed keys and attestation |
Settings appear under names such as PTT, fTPM, Security Device Support or TPM device selection. Clearing the TPM from setup erases its owner hierarchy, so it should never be done while keys are still sealed to it.
Limitations, attacks and common mistakes
A TPM raises the cost of attacks but does not make a platform invulnerable. Its guarantees cover what it measures, and only as well as the firmware performs those measurements. Physical attackers with time and equipment can sometimes sniff the LPC or SPI bus of a discrete TPM to capture an unsealed disk key when no PIN is configured.
- TPM-only unlock protects against disk removal, but not against an attacker who boots the original machine; adding a pre-boot PIN closes much of that gap.
- Firmware updates change PCR values, so sealed secrets must be resealed or protection suspended before updating.
- Losing the recovery key after a motherboard or CPU swap can make encrypted data unrecoverable.
- TPM 1.2 is not equivalent to TPM 2.0; it lacks algorithm agility and is limited to SHA-1 and RSA.
- Attestation proves configuration, not intent: a measured but vulnerable component still passes.
Explained without jargon
A TPM is like a small, sealed safe built into the computer. It keeps secret keys inside and will not hand them out. When the computer starts, the safe also writes down a record of every piece of startup software, in order, in ink that cannot be erased.
If the record matches what it saw last time, the safe opens and the computer can unlock its encrypted drive automatically. If someone changed the startup software or moved the drive to another machine, the safe stays shut and asks for a backup code instead. The key point is that the secret only comes out when the computer is in a known, trusted state.
A typical use case
A mid-sized accounting firm issues laptops to staff who travel to client offices. IT enables the firmware TPM in UEFI, turns on Secure boot and activates full-disk encryption sealed to PCRs 7 and 11, with a six-digit pre-boot PIN. Recovery keys are escrowed in the company directory.
When one laptop is stolen from a car, the thief removes the SSD and connects it to another computer. The data stays encrypted because the key never left the original TPM. Weeks later, a staff member updates firmware without suspending protection and the laptop asks for its recovery key; the help desk supplies it from escrow within minutes. The outcome is no data exposure from the theft and only a brief interruption from the update, which led IT to automate suspension before firmware rollouts.