What Is a Trusted Platform Module?

A Trusted Platform Module, or TPM, is a security-focused cryptographic processor that gives a computer a protected place to create, use, and safeguard certain keys and measurements. It may be a discrete chip on a motherboard, integrated into another component, or implemented in firmware with hardware-backed isolation. TPM specifications are maintained by the Trusted Computing Group, while operating systems provide the software that uses the device. The central idea is separation: sensitive operations and private material can be kept behind a narrow command interface instead of being handled like ordinary data in general-purpose memory.

A TPM can generate asymmetric key pairs and perform operations with private keys without exposing those keys to the operating system in exportable form. It also has a hierarchy of keys used to protect other objects stored outside the module. Applications can ask the TPM to sign data, decrypt a small value, or produce random numbers, depending on supported algorithms and authorization rules. The module has limited storage and processing capacity, so it is not a general substitute for a CPU or disk. It protects small secrets and cryptographic relationships that other software uses to secure much larger amounts of data.

Platform Configuration Registers, or PCRs, are a distinctive TPM feature. During measured boot, firmware and later startup components calculate hashes of code and configuration and extend those values into PCRs. Extending combines the previous register state with a new measurement, creating an ordered record that is difficult to rewrite into a chosen result. The PCRs do not normally contain entire programs, and a measurement is not automatically a verdict that code is good. They provide evidence of what was measured so local policy or a remote verifier can compare the resulting state with expected values.

Sealing ties access to a secret to selected TPM conditions, such as specific PCR values and user authorization. A disk-encryption system can use this feature to release a volume key automatically when the startup environment matches policy. If important firmware or boot settings change, the TPM may refuse automatic release and require a recovery key. Attestation uses TPM-protected keys to sign claims about platform state so another service can evaluate them. Privacy and provisioning rules matter because poorly designed attestation could become a durable tracking signal or reveal more device information than necessary.

Common uses include full-disk encryption, device identity, credential protection, secure sign-in, virtual smart cards, and enterprise health checks. The TPM usually protects or releases keys; it does not encrypt every sector of a drive by itself. It also does not scan for malware, guarantee that measurements correspond to secure software, or prevent every physical attack. Security depends on firmware, the operating system, application policy, recovery processes, and the implementation of the module. Vulnerabilities in any of those layers can weaken the result, and high-value systems may require additional tamper resistance.

TPMs must be provisioned and managed carefully. Clearing a TPM can remove protected keys and make encrypted data inaccessible unless recovery material exists elsewhere. Firmware updates, motherboard replacement, or boot configuration changes can also trigger recovery. Organizations therefore escrow recovery keys, document ownership and authorization settings, test updates, and retire devices with a deliberate key-destruction process. For an everyday user, the module is mostly invisible, but it supports important conveniences: a computer can unlock protected storage when its startup state is expected and demand stronger proof when that state changes. Its strength is controlled key use anchored to the device. TPM versions and capabilities differ, so software checks supported algorithms and feature levels rather than assuming every machine behaves identically. Virtual machines may receive virtual TPMs whose protection ultimately depends on the hypervisor and host. The same interface can therefore rest on different physical or managed trust boundaries.