Hardware Root of Trust Explained: Secure Boot, TPM 2.0 (2026)

What Is a Hardware Root of Trust, and Why It Matters in 2026

A hardware root of trust is not a product you buy — it is a design principle. Somewhere in the platform, there is a piece of code or a dedicated chip that cannot be rewritten by an attacker, and everything else on the machine has to prove its legitimacy to that fixed point before it is allowed to run. Ubuntu's documentation puts it simply: with a hardware root of trust, the hardware verifies the UEFI firmware before it runs, based on a read-only piece of code in the CPU.

This matters because the traditional model — antivirus running inside an already-booted OS — arrives too late for firmware-level attacks. A bootkit that compromises UEFI or the firmware layer beneath it can persist across OS reinstalls, disk wipes, even hard drive replacements, because it never lived in the OS to begin with. Microsoft's own framing for Windows makes this the whole point of the mechanism: stopping unauthorised firmware or software from starting before the bootloader even gets a chance to run.

The 2026 shift is that this is no longer a specialist hardening option bolted onto high-security builds. It sits underneath Microsoft's Secured-core Server model, Ubuntu's hardware-backed disk encryption requirements, and NVIDIA's Jetson edge-computing platform — three quite different ecosystems, all leaning on the same underlying idea: verify silicon-down, not OS-up.

Secure Boot, Measured Boot and TPM 2.0 — Untangling the Terms

These three terms get used almost interchangeably in vendor literature, and that's a mistake worth correcting. Secure Boot is a gatekeeper: Microsoft describes it as verifying that a trusted author has digitally signed the UEFI firmware drivers and applications before the server hands control to the operating system. If a component isn't signed correctly, it doesn't run. Full stop.

Measured boot is a different job entirely — it doesn't block anything, it records. On Secured-core server systems, Microsoft's documentation confirms that every component loaded during boot is measured, and those measurements are stored in the TPM's Platform Configuration Registers (PCRs). Secure Boot answers "did anything unsigned try to run?" Measured boot answers a more useful question later on: "what actually ran, and can I prove it?"

TPM 2.0 is the standard component that makes measured boot verifiable after the fact — Microsoft confirms TPM 2.0 comes standard with Secured-core Servers as a protected store for sensitive keys and boot measurements. Windows System Guard uses Secure Boot itself as the hardware-based root of trust for its static early boot measurement, which is why the terms blur in practice — but treating Secure Boot and TPM-based measured boot as the same control is a category error that leaves gaps in an audit trail.

The Different Types of HRoT Implementation

Not every "hardware root of trust" is built the same way, and the differences matter for procurement, not just theory. A discrete TPM is a physically separate chip; a firmware TPM (fTPM) achieves the same standards-level functionality inside the CPU's own firmware. The specification language is identical — TPM 2.0 — but the procurement and performance implications differ, because you're trusting different silicon boundaries.

Beneath the TPM sits the mechanism that actually checks the firmware before anything runs. Ubuntu names the two dominant approaches directly: Intel Boot Guard Authenticated Code Module (ACM) and AMD Platform Secure Boot (PSB), both described as dedicated security-chip mechanisms used to verify or measure firmware. On top of that, Microsoft notes that processor support for Dynamic Root of Trust of Measurement (DRTM) can put firmware in a hardware-based sandbox, limiting the blast radius of vulnerabilities in highly privileged firmware code.

At the edge, the same principles get applied to very different hardware. NVIDIA's Jetson documentation describes secure boot as essential to the fTPM boot flow, establishing a Hardware Root of Trust, a Root of Trust for Reporting and a Root of Trust for Measurement — the same three-part logic as an enterprise server, scaled down to an embedded module.

• •Discrete TPM 2.0: separate chip, protected key/measurement store — standard on Secured-core Servers
• •Firmware TPM (fTPM): same TPM 2.0 functionality, implemented in CPU firmware rather than a separate chip
• •Intel Boot Guard ACM / AMD PSB: dedicated silicon mechanisms that verify or measure UEFI firmware before it runs
• •DRTM: sandboxes early firmware in hardware, limiting the impact of privileged-firmware vulnerabilities

The Supply-Chain Angle: Why Firmware Is the New Target

Supermicro's own security documentation frames its root of trust plainly: it starts a chain of trust that validates the server is booted with legitimate firmware. That word — legitimate — is doing a lot of work. A hardware root of trust isn't just checking that firmware hasn't been tampered with locally; it's checking that what's running is the firmware the manufacturer actually shipped, which is precisely the guarantee a supply-chain implant tries to defeat.

Microsoft's framing for Azure Local reinforces this directly: being able to verify that firmware running during boot is validly signed by the expected author helps improve supply-chain security. For UK buyers, this reframes firmware verification from an anti-malware feature into a procurement control — one that sits alongside server BMC firmware security as part of what you should be checking before hardware goes into production, not after an incident.

A Worked Scenario: Verifying What Actually Booted

Consider a UK organisation deploying a fleet of Secured-core servers into a zero-trust segmented network. At power-on, the silicon-level check — Intel Boot Guard ACM or AMD PSB, depending on the platform — verifies the UEFI firmware itself before it's allowed to execute. UEFI Secure Boot then checks that every driver and boot loader component is signed by a trusted author, per Microsoft's Secured-core description, before handing control onward.

Every component loaded during this sequence gets measured, and those measurements land in the TPM 2.0 PCRs. Where the processor supports it, DRTM sandboxes the early firmware code so that even a vulnerability in privileged firmware can't quietly rewrite what the TPM eventually reports. Before the server is granted access to sensitive workloads under a Zero Trust security architecture, an attestation step compares the recorded PCR values against an expected baseline — proving, cryptographically, that the machine booted the way it was supposed to, rather than just assuming it.

This is the practical difference a hardware root of trust makes over software controls alone: it doesn't just block bad boot components, it produces evidence — evidence that can be checked remotely, logged for audit, and tied into access-control decisions rather than left as an assumption baked into the OS install.

Future-Proofing: AI-Era Attacks and the Post-Quantum Transition

Two pressures are reshaping how IT leaders should think about hardware roots of trust going forward, even where the underlying mechanics — verify, measure, attest — stay constant. First, the increasing sophistication of attackers in finding firmware vulnerabilities puts a premium on the DRTM-style sandboxing Microsoft describes: limiting what a compromised firmware component can actually do, rather than hoping it's never found in the first place.

Second, the cryptographic signatures underpinning Secure Boot and TPM attestation today will need to migrate over the hardware's operational lifetime as cryptography evolves. The practical implication for procurement isn't a number to plug into a spreadsheet — it's a question: does this platform support firmware and key updates over its expected service life, or does the root of trust become a fixed point you can never revisit? A root of trust that can't be updated is a liability dressed up as a security feature.

Choosing the Right HRoT: A Procurement Checklist for UK IT Leaders

Vendor data sheets rarely make these distinctions explicit, so the questions need to come from procurement, not marketing copy. Start with the silicon layer: does the platform use Intel Boot Guard ACM or AMD PSB, and is that the manufacturer's default configuration or an option that needs enabling? Then check the TPM: is it a discrete chip or a firmware TPM, and does that distinction matter for the workload — regulated data typically warrants asking directly.

Ask whether the platform supports remote attestation workflows, so measured-boot evidence can actually be checked after deployment rather than trusted blindly. And ask how what is a Trusted Platform Module (TPM) functionality gets configured on delivery — misconfigured or disabled TPMs are one of the most common gaps between what a platform is capable of and what's actually protecting it in production. For teams building this out, how to enable Secure Boot and TPM on your servers is the practical next step once the platform-level questions are answered.

• •Confirm whether Boot Guard ACM / AMD PSB is enabled by default or requires configuration
• •Establish discrete TPM vs firmware TPM and whether that distinction matters for your compliance scope
• •Check for remote attestation support so PCR measurements can be verified after deployment
• •Treat firmware-signing evidence as a supply-chain control, not just a boot-time nicety
• •Confirm the platform supports firmware/key updates over its service life, not a fixed root of trust

Conclusion: Trust That Starts Before the Operating System Does

A hardware root of trust doesn't replace endpoint protection, patching discipline or network segmentation — it underpins them, by guaranteeing that the platform those controls run on is the one you actually deployed. Secure Boot blocks unsigned components; TPM 2.0 measured boot proves what ran; silicon-level checks like Boot Guard ACM and AMD PSB verify the firmware itself; DRTM limits what a compromised firmware component can do. Together, they turn "we assume the server booted cleanly" into something you can actually check.

Sources

Every figure in this article traces to the sources below.

• •Microsoft — Silicon-assisted security, Azure Local (TPM 2.0, DRTM, firmware supply-chain verification)
• •Microsoft — Hardware-based root of trust protecting Windows (bootkit prevention, Secure Boot as HRoT for System Guard)
• •Microsoft — Secured-core Server (Secure Boot signature checks, TPM boot measurements)
• •Supermicro — Security features description (RoT chain of trust for legitimate firmware)
• •Ubuntu — Hardware-backed disk encryption requirements (Intel Boot Guard ACM, AMD PSB)
• •NVIDIA — Jetson firmware TPM documentation (HROT, RTR, RTM in secure boot flow)