How does the chain of trust work?

The chain of trust is a sequence of cryptographic verifications that begins at the hardware root of trust and extends through each stage of the boot process. The HRoT verifies the firmware, the firmware verifies the bootloader, the bootloader verifies the OS kernel, and so on. Each link in the chain must be verified before it is allowed to execute — if any link fails verification, the boot process stops or raises an alert.

What is the difference between a hardware root of trust and a TPM?

A hardware root of trust is the conceptual security anchor — the starting point of all trust in a system. A TPM (Trusted Platform Module) is one specific hardware component that serves as the root of trust in many PC and server platforms. Other hardware roots of trust include ARM TrustZone boot ROMs, Apple's Secure Boot ROM, and vendor-specific secure elements. A TPM is thus an implementation of a root of trust, not the concept itself.

What is UEFI Secure Boot?

UEFI Secure Boot is a firmware security mechanism that checks the digital signature of every bootable component — including the bootloader and operating system kernel — before allowing it to execute. It relies on a database of trusted keys stored in UEFI firmware to verify signatures. Only properly signed components can run, blocking boot-level malware such as bootkits and rootkits that install before the OS loads.

What is measured boot?

Measured boot is a process where each component in the boot sequence records a cryptographic hash of the next component into the TPM's Platform Configuration Registers (PCRs) before executing it. Unlike Secure Boot, which blocks unsigned components from running, measured boot records what actually ran without necessarily blocking anything. The PCR values serve as evidence for remote attestation, allowing a remote server to verify the exact software stack that booted.

Which systems need a hardware root of trust?

Any system that handles sensitive data, requires remote attestation, or must resist firmware-level attacks benefits from a hardware root of trust. This includes enterprise laptops and servers (TPM 2.0 is required for Windows 11), cloud infrastructure (hypervisors use measured boot for tenant isolation), IoT devices (automotive ECUs, medical devices), HSMs, network equipment, and government systems covered by standards like NIST SP 800-155 and FIPS 140-3.

What Is a Hardware Root of Trust? Chain of Trust Explained

Q: What is a hardware root of trust?

A hardware root of trust (HRoT) is the foundational security anchor in a computing system — an immutable hardware component that every subsequent security decision depends on. It is inherently trusted because it is implemented in hardware rather than software, making it resistant to tampering by malicious code running on the platform. All secure boot, key storage, and attestation functions trace back to the root of trust.

Introduction

In 2018, security researchers discovered that millions of servers from multiple major manufacturers could be silently compromised at the firmware level — below the operating system, below the hypervisor, invisible to every endpoint detection tool in the enterprise stack. The attack vector was a UEFI firmware implant that persisted across OS reinstalls and drove home a critical point: security cannot start at the OS layer. It must start at the silicon. The hardware root of trust is the industry’s answer — an immutable, hardware-enforced foundation from which every security guarantee in the system flows.

What Is a Hardware Root of Trust?

A hardware root of trust (HRoT) is the lowest-level, hardware-implemented security anchor in a computing system — the point from which all trust begins. It is the one component that every higher-level security mechanism depends on, and it must be inherently trustworthy because there is nothing beneath it to verify it. Unlike software-based security controls, which can be modified by malicious code with sufficient privilege, a hardware root of trust is implemented in silicon that cannot be altered after manufacture.

The concept is formalized across several standards. NIST SP 800-155 defines the requirements for BIOS/UEFI integrity measurement. NIST SP 800-193 extends this to platform firmware resilience. The Trusted Computing Group (TCG) specifies the TPM as the primary hardware root of trust for general-purpose computers.

A hardware root of trust must perform three core functions: measurement (recording a cryptographic hash of everything that runs next), storage (keeping those measurements and cryptographic keys tamper-proof), and reporting (proving the measurements to an external party through attestation).

How a Hardware Root of Trust Works

The mechanism by which the hardware root of trust operates is called the chain of trust — a sequence of cryptographic verifications that starts the moment the power button is pressed.

Stage 1 — Immutable boot ROM. Every HRoT begins with a read-only boot ROM — code burned into the chip at manufacture that cannot be modified. On ARM processors, this is the boot ROM in TrustZone. On Apple devices, it is the Boot ROM. On enterprise servers and PCs, the initial code runs from a protected UEFI flash region. This is the first and most critical link: it is trusted because it cannot be changed.

Stage 2 — Firmware verification. The boot ROM verifies the signature of the next-stage firmware using a cryptographic key stored in the hardware. If the signature matches a key in the trusted database, the firmware is allowed to run. If not, the system halts. This step blocks UEFI rootkits and firmware implants from surviving undetected.

Stage 3 — UEFI Secure Boot. UEFI Secure Boot extends the chain into the operating system loader. The UEFI firmware checks the digital signature of the bootloader and OS kernel against a key database (the Secure Boot db). Only components signed by trusted authorities in that database can execute. This is the layer that blocked the 2018 server firmware attacks in properly configured systems.

Stage 4 — Measured Boot and TPM PCR recording. In parallel with verification, the TPM records what actually ran. Each boot component (UEFI firmware, bootloader, kernel) is measured — its hash is extended into a TPM Platform Configuration Register (PCR). The PCR accumulates these measurements in a way that cannot be forged or rewound. When boot is complete, the PCRs contain a cryptographic fingerprint of the exact software that ran.

Stage 5 — Remote attestation. A remote server can request a TPM quote — a signed report of the PCR values — to verify that a machine booted exactly the software the server expects. If any component was modified, the PCR values change, and the remote server can detect the discrepancy and refuse to grant access. This is how confidential computing platforms verify VM integrity before allowing sensitive data to enter.

The chain of trust starts at the hardware root of trust and extends through each verified boot stage. The TPM records measurements at every step, creating an unforgeable audit trail for remote attestation.

Hardware Root of Trust vs TPM vs Secure Boot

These three terms are closely related but distinct in scope and function.

Concept	What It Is	Function	Who Specifies It
Hardware Root of Trust	Concept: the foundational trusted hardware	Establishes initial trust before any code runs	NIST SP 800-193, TCG
TPM (TPM 2.0)	Specific component: secure cryptoprocessor	Stores keys, records measurements, produces attestation quotes	TCG TPM 2.0 Library Spec
UEFI Secure Boot	Mechanism: signature verification framework	Verifies bootloader/kernel signatures before execution	UEFI Forum
Measured Boot	Process: hash recording at each stage	Records what ran (evidence) without blocking it	TCG Measured Boot spec
Attestation	Service: cryptographic proof of boot state	Proves to remote parties what software ran	IETF RATS / TCG

The hardware root of trust is the anchor. The TPM is the most widely deployed implementation of that anchor for PCs and servers. Secure Boot is the enforcement mechanism using the anchor’s keys. Measured boot is the recording mechanism using the anchor’s secure storage. Attestation is the communication mechanism for proving the recorded state to outsiders.

Watch to understand how hardware roots of trust are implemented across embedded systems, IoT, and enterprise servers, including the difference between secure boot verification and measured boot recording.

Real-World Use Cases

Enterprise endpoint security. Windows 11 requires TPM 2.0 as a mandatory hardware component specifically to enforce hardware root of trust requirements. BitLocker disk encryption seals its volume keys to the TPM’s PCR values — if the boot sequence changes (indicating potential tampering), BitLocker locks the drive. This integration between full disk encryption and the TPM’s chain of trust is the most widely deployed HRoT application in consumer computing.

Cloud VM attestation. Cloud providers use hardware roots of trust to give tenants cryptographic proof of what hypervisor software their VMs are running on. AMD SEV-SNP’s attestation and Intel TDX’s attestation capabilities both root back to hardware measurements that the cloud provider cannot forge. An enterprise running workloads under FIPS 140-3 requirements can verify that the cryptographic module is executing on a known-good software stack before trusting it with production keys.

IoT and automotive security. Automotive ECUs (Engine Control Units), medical devices, and industrial controllers increasingly require hardware roots of trust to prevent firmware tampering during operation and over-the-air updates. ISO/SAE 21434 (automotive cybersecurity) and IEC 62443 (industrial control systems) both reference hardware roots of trust as baseline requirements. An OTA (over-the-air) update that fails signature verification is rejected at the boot ROM level — before the ECU can execute any modified code.

Common Mistakes to Avoid

Assuming Secure Boot alone is sufficient. UEFI Secure Boot verifies that only signed components run, but it does not record what ran. Without measured boot and TPM PCR logging, you have no forensic record and cannot support remote attestation. Secure Boot prevents obvious boot-level attacks; measured boot enables detection and auditability.

Disabling Secure Boot for compatibility. Organizations that disable Secure Boot to support legacy drivers or unsigned operating system components eliminate the entire chain of trust above the hardware root of trust. Any subsequent security control becomes difficult to trust because you cannot prove the OS itself was unmodified at boot time. Compatibility issues should be resolved by obtaining signed drivers, not by disabling the verification chain.

Leaving TPM PCR policies undefined. TPM-based BitLocker or disk encryption without defined PCR policies can unseal keys regardless of which OS booted — including a live attack OS booted from USB. Explicitly binding secrets to the correct set of PCRs (typically PCR 0, 2, 4, 7 for UEFI systems) ensures keys are only released when the legitimate verified OS loads.

Ignoring firmware update security. The hardware root of trust protects against unauthorized firmware changes — but authorized firmware updates must be signed and verified by the same chain of trust. An unsigned or improperly authenticated firmware update process creates a bypass for the entire security architecture. Reference NIST SP 800-193’s “Protect” function for firmware update authentication requirements.

Getting Started with Hardware Root of Trust

Verify TPM 2.0 is present and enabled. On Windows systems, run tpm.msc to check the TPM status. On Linux, verify /dev/tpm0 exists and run tpm2-tools to check the chip’s capabilities. If the TPM is disabled in UEFI firmware settings, enable it — it is the foundation of every subsequent trust guarantee.

Enable UEFI Secure Boot. In your system UEFI settings, ensure Secure Boot is enabled and operating in User Mode with your organization’s key database configured. For enterprise systems, enroll your own CA certificate into the Secure Boot db rather than relying solely on the default Microsoft keys — this gives you direct control over what can boot on your machines.

Implement measured boot and TPM-sealed secrets. For laptops and servers handling sensitive data, configure BitLocker (Windows) or systemd-cryptenroll (Linux) to seal disk encryption keys to TPM PCR values corresponding to your verified boot state. This ensures that if the boot chain is tampered with, the disk encryption key cannot be released.

Integrate attestation with your identity framework. For cloud workloads and zero-trust implementations, integrate TPM or confidential computing attestation into your identity and access management decisions. A workload that cannot prove it booted from a verified image should not receive production secrets or be granted access to sensitive data through your public key infrastructure. Organizations already using hardware security modules for key management should treat the HRoT as the attestation anchor that validates the entire deployment chain before HSM keys are released.