Most of a device's security lives in software that can be modified, so proving that a particular machine is genuine and untampered needs something the software cannot fake. A trusted platform module is a small dedicated chip soldered onto that machine to be exactly that anchor. It stores keys where software cannot copy them, records measurements of the code the device boots, and lets the device prove to a remote party what state it came up in. This guide explains what a TPM is, how it holds boot measurements in registers called PCRs to enable measured boot, how it supports remote attestation, and how it differs from a centralized hardware security module.
Trusted Platform Module (TPM) in one line: A trusted platform module, or TPM, is a dedicated secure chip on an individual device that stores cryptographic keys, holds measurements of the device's boot state in special registers called platform configuration registers, and enables measured boot and remote attestation. Because it is a separate piece of hardware, the keys and measurements it protects cannot be copied or forged by software running on the device. It is a per-endpoint building block for proving that a specific machine booted in an expected, untampered state.
A TPM is a small chip that belongs to one device and does a handful of security-critical jobs that would be unsafe to leave to software. It can generate and store cryptographic keys inside itself, keeping the private material where the device's operating system and applications cannot read it out, so a key protected by the TPM stays protected even if the software around it is compromised. It provides a hardware-backed source of the randomness that good cryptography depends on, and it offers a small amount of shielded storage for secrets. The unifying idea is a modest, tamper-resistant island on the board that the rest of the system can lean on but cannot pry open.
The other half of the TPM's role is measurement. As a device boots, each stage can be hashed and that hash recorded into the TPM before the stage runs, building up a record of exactly what code the machine executed on its way up. The current widely used generation is TPM 2.0, which broadened the algorithms and uses beyond earlier versions. What makes the TPM valuable is that these two jobs reinforce each other: it not only holds keys and measurements, it can bind the use of a key to a particular measured state, so a secret can be made available only when the device booted the way it was supposed to. That is a stronger property than storage alone, because it ties access to secrets to the integrity of the platform.
The registers that hold those boot measurements are the platform configuration registers, or PCRs. A PCR cannot simply be set to an arbitrary value; instead each new measurement is folded into the register's existing contents in a way that cannot be undone, so the final value reflects the entire sequence of measurements in order. This is what makes measured boot trustworthy: because you cannot rewind a PCR or overwrite it with a value of your choosing, a machine that booted tampered code ends up with PCR values that do not match those of a clean boot, and there is no way for the compromised code to quietly fix them up to look right. The PCRs become a faithful fingerprint of what the device actually ran.
Remote attestation is where that fingerprint is put to use. The device can produce a report of its PCR values, signed by a key held inside the TPM, and send it to a remote party who compares the values against what a known-good boot should produce. Because the report is signed by a TPM-protected key and the PCRs cannot be forged from software, the remote party gets meaningful evidence of whether the device booted an expected, untampered configuration, rather than merely a self-report the device could lie about. This is the crucial difference from measured boot alone: measured boot records the state locally, while attestation lets a distant system verify that state and decide whether to trust the device, admit it to a network, or release a secret to it.
It is easy to blur a TPM with a hardware security module, since both are tamper-resistant hardware that guards keys, but their roles are different. A TPM is soldered to one device and is about that device's own identity and integrity: its keys, its boot measurements, its ability to attest to its own state. An HSM is a centralized appliance built to guard the high-value keys that many devices depend on, such as a certificate authority's signing keys, and to perform signing at the volume a whole fleet demands. The TPM is the on-board endpoint chip; the HSM is the crypto appliance at the center. In a full system they complement each other, with the TPM proving each endpoint's integrity and the HSM protecting the central keys that anchor fleet-wide trust.
On OT endpoints, the TPM's natural homes are the more capable devices, the gateways, edge servers, and engineering workstations that sit between the field and the enterprise, rather than the smallest embedded controllers. On those devices a TPM lets the machine prove it booted untampered before it is trusted with sensitive work, and it protects the keys the device uses to authenticate itself. For a cloud SCADA deployment, this is directly useful: a gateway that aggregates telemetry from field assets and forwards it to a hosted platform such as Merobix is a high-value link worth being sure of, and a TPM on that gateway can protect its identity keys and provide evidence, through measured boot and attestation, that it is running genuine, unmodified software. That turns the gateway from a device you simply hope is clean into one that can offer hardware-backed proof of its integrity before the platform relies on the data flowing through it.
A TPM is a per-device secure chip that stores cryptographic keys where software cannot copy them, records measurements of the code a device boots, and lets the device prove its boot state to a remote party through attestation. It can also bind a secret to a particular measured state, releasing it only when the device booted as expected. In practice it is used to protect device identity keys and to give hardware-backed evidence that a machine started in an untampered configuration.
PCRs are platform configuration registers inside the TPM that hold boot measurements. Each new measurement is folded into a PCR in a way that cannot be undone or overwritten with an arbitrary value, so the final register value reflects the entire ordered sequence of code the device ran. A tampered boot produces PCR values that do not match a clean boot, and the compromised code cannot fix them up, which is what makes measured boot a trustworthy record of what actually executed.
A TPM is soldered onto one device and secures that device's own keys, boot measurements, and ability to attest to its state, so it is a per-endpoint chip. An HSM is a centralized appliance that guards the high-value keys many devices depend on, such as a certificate authority's signing keys, and handles signing at fleet scale. They complement each other: the TPM proves each endpoint's integrity, while the HSM protects the central keys that anchor trust across the whole system.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.