Hardware Root of Trust, Firmware & BMC Security

Every security control in Part 11 — confidential computing, network microsegmentation, weight encryption, multi-tenant isolation — is software running on a stack of firmware that booted before any of it existed. If that firmware lied about what it loaded, none of the controls above it mean anything. This is the asymmetry that makes firmware the highest-value target in the building: it is the most privileged code (it runs before and beneath the hypervisor and the OS), the most persistent (an implant in SPI flash or a BMC survives OS reinstall, disk wipe, and often a motherboard swap), and the least observed (EDR, your SIEM, and your GPU telemetry all live above it and cannot see it). An attacker who plants a backdoor in the BMC has not compromised a server — they have compromised everything that server will ever run, invisibly, for the life of the asset.

This chapter is the decision framework for the layer beneath the OS. We start with why firmware is the target and what a hardware root of trust (RoT) actually buys you — the silicon-anchored chain that makes every higher claim, including the GPU attestation of Chapter 11.5, mean something. We work up through secure and measured boot, firmware-update integrity, and platform attestation: the machinery that lets a node prove — to your fleet, not just to itself — what it is running. Then we treat the BMC as the parallel computer it is, with its own threat model and its own segmentation discipline, and close on continuous integrity monitoring, because measured boot is a snapshot and an AI cluster runs for years.

Generic IT threat models treat firmware as a footnote because, on a fleet of fungible web servers, a bricked node is a ticket and a re-image. The economics invert in an AI data center for three reasons. First, the asset is irreplaceable and supply-constrained: a GB200 NVL72 rack is roughly $3M+ of allocation-limited silicon, so an attacker who can brick it from the management plane has a destructive weapon with grid-trip-adjacent leverage (the OT/destructive angle is Chapter 11.10). Second, the asset carries the highest-value digital IP in existence — frontier weights — and a firmware implant sits below the encryption boundary that is supposed to protect them, with a clear line of sight to plaintext in host memory and over PCIe (weight protection is Chapter 11.8). Third, the firmware layer is persistent and stealthy in a way nothing above it is: an implant in the BMC or in SPI-resident UEFI survives every remediation short of physical re-flash, and it is invisible to the entire detection stack you built for the OS and the network.

This is not hypothetical. In 2025 the canonical example arrived: CVE-2024-54085, an authentication-bypass in AMI's MegaRAC BMC firmware, scored CVSS 10.0 and was added to CISA's Known Exploited Vulnerabilities catalog on 25 June 2025. MegaRAC is OEM'd into BMCs across a dozen-plus server vendors; a remote, unauthenticated attacker reaching the Redfish interface can deploy malware, tamper firmware, brick the BMC or BIOS, force unrecoverable reboot loops, and — because BMCs on a flat management segment can command their neighbors — pivot to every other BMC on the same VLAN. Researchers found over a thousand internet-exposed instances. That single CVE is the entire thesis of this chapter in one disclosure: the most privileged, most persistent, least-watched computer in your rack shipped with a 10.0 and most operators did not know it was reachable.

A root of trust is the first piece of code that executes and is trusted without being measured by anything else — the anchor the whole boot chain hangs from. The fork is where that anchor lives and who can audit it. The legacy posture roots trust in a vendor's opaque boot ROM and BMC firmware: you trust it because the OEM says so, and you cannot inspect it. The 2026 posture, driven by the hyperscalers through OCP, roots trust in an open, immutable, dedicated silicon RoT that boots first, measures everything else, and whose implementation you can actually read.

The reference design here is Caliptra — an open-source silicon RoT spec contributed to OCP by Microsoft, Google, AMD, and NVIDIA, now a committed building block in Google and Microsoft first-party cloud silicon and AMD server silicon. Caliptra is an internal RoT: a hardware block integrated inside the SoC (not a discrete TPM hanging off a bus an attacker can interpose on) that establishes a cryptographic device identity and measures the first mutable firmware before it runs. The identity mechanism is DICE (Device Identifier Composition Engine): starting from a Unique Device Secret fused into the silicon, each boot layer derives the next layer's identity as a function of its own measured code. The consequence is the property that makes attestation meaningful — if any layer's firmware changes by a single bit, every derived key downstream changes, so a tampered boot chain cannot produce the same attestation as a clean one. You cannot forge your way back to a trusted measurement.

Caliptra 2.x (the 2025 line) adds something the long-lived-asset thesis of this guide demands: post-quantum cryptography in the root itself. Via the open-source Adams Bridge accelerator it implements NIST's ML-DSA (signatures) and ML-KEM (key encapsulation) with side-channel countermeasures, making it the first open RoT hardened against harvest-now-decrypt-later. For a GPU asset on a 5-6 year book life whose attestation and signing keys must remain trustworthy across the PQC transition, rooting trust in pre-quantum crypto is a slow-motion mistake; the crypto-agility forward-pointer for weights and long-lived keys lands in Chapter 11.8.

Reading the table as a decision rather than a catalog: a discrete TPM is necessary but not sufficient. It gives you PCR-based measured boot, but it is a separate chip on a bus an attacker with physical access can interpose on, and it does not protect the host's own mutable firmware from being modified before the next boot measures it. The internal silicon RoT closes both gaps — it lives inside the package, and it measures the first mutable firmware before that firmware is allowed to execute. In practice the 2026 posture is both: a discrete TPM 2.0 for the platform measured-boot PCRs and an internal RoT (Caliptra-class) anchoring the silicon identity, which is exactly how the leading DC-SCM 2.0 modules ship.

The OCP Datacenter-ready Secure Control Module (DC-SCM) is the architectural answer to the BMC-as-liability problem. Rather than soldering the BMC, the RoT, and the TPM onto the motherboard — where they are tied to that board's design, its firmware lifecycle, and its supply chain — DC-SCM pulls all of the management, security, and control logic onto a pluggable module that mates to the host board over a standardized connector. The 2.0 generation (with 2.1 reference designs appearing in 2025) standardizes the horizontal external form factor and the interfaces, so the same security module can ride across multiple board generations and multiple-node designs.

The decision consequence is threefold. First, supply-chain provenance (the subject of Chapter 11.3) gets a clean boundary: the security-critical components — RoT, BMC, TPM — live on one auditable module you can source, attest, and update on its own cadence, instead of being entangled with a commodity motherboard. Second, firmware lifecycle decouples: you can refresh or harden the management stack without re-qualifying the entire server, which matters when a 10.0 BMC CVE lands mid-deployment. Third, it makes the management plane a discrete, attestable unit — the RoT on the DC-SCM measures and gates the BMC's own firmware, so the controller that has god-mode over the host is itself rooted in silicon you trust. The leading modules pair an internal RoT, an ASPEED AST2600-class BMC, and a discrete TPM 2.0 on the same card — the layered posture the table above argues for, productized.

Two mechanisms are routinely conflated and do opposite jobs. Secure boot is enforcement: each stage cryptographically verifies the signature of the next stage before executing it, and refuses to run anything unsigned or tampered. It is a gate — it stops a known-bad boot. Measured boot is evidence: each stage hashes the next stage and extends that hash into a tamper-resistant register (a TPM PCR or the RoT's measurement log) before passing control, building a cryptographic transcript of exactly what ran, in order. It does not stop anything; it produces an unforgeable record you can later attest against. You want both. Secure boot keeps the obvious attacks out; measured boot lets you prove to a remote verifier what actually loaded, which is the only thing that lets a fleet make a trust decision about a node it cannot physically inspect.

The chain runs RoT → platform firmware (UEFI/BIOS) → bootloader → OS kernel → the workload's own attestation (and, in parallel, RoT → BMC firmware). The NIST backbone here is SP 800-193 (Platform Firmware Resiliency) — protect, detect, recover — together with SP 1800-34 (supply-chain provenance) and IR 8320 (hardware-enabled security). The decision that separates a real implementation from a decorative one is whether you enforce on the measurement: do you let a node into the cluster, hand it weights, and route it traffic only after its measured-boot quote is validated against a known-good golden value? If the answer is no — if measured boot produces a log nobody checks — you have built an audit trail for the forensics team, not a defense.

The update path is where a firmware defense most often quietly fails, because update is the one sanctioned way to change the code below the OS — so it is the channel an attacker most wants. Three properties are non-negotiable. Signed: the platform refuses any image not signed by a key chained to the RoT — no unsigned TFTP pushes, no vendor-tool side-loads. Versioned and anti-rollback: the hardware enforces a monotonic security version counter so an attacker cannot downgrade you to a known-vulnerable firmware to re-open a patched hole — rollback protection is a hardware fuse/counter, not a policy in software the attacker is trying to subvert. Atomic and recoverable: a failed or interrupted update must leave a known-good image to boot from (the A/B or golden-recovery pattern SP 800-193 calls for), so a botched flash is a reboot, not a brick — and so an attacker cannot weaponize the update path into a denial-of-service.

At fleet scale the mechanics are standardized: Redfish for the management API, PLDM-over-MCTP for component firmware update, and the OCP GPU Firmware Update specification for cross-vendor GPU firmware management over a secure out-of-band path. The decision consequence of getting this wrong is severe and specific: a fleet that accepts unsigned or downgradeable firmware has handed an attacker — or a poisoned supply-chain update — a way to make a backdoor resident below the OS and persistent across remediation. You cannot patch your way out of a firmware implant if the patch channel is the thing that let it in.

Local measured boot answers 'what did I load?' Remote attestation answers the question the cluster actually needs: 'should I trust that node enough to give it weights and traffic?' The flow: a verifier issues a challenge, the node's RoT/TPM returns a signed quote over its measurement log plus the per-component Reference Integrity Manifests (RIMs) — the vendor-signed golden hashes of legitimate firmware — and the verifier compares the quote against known-good values for that exact hardware and firmware version. Match → the node is admitted and, in a confidential-computing deployment, a key broker releases the keys that decrypt the workload's data only to an attested node. Mismatch → quarantine.

This platform attestation is the foundation the GPU attestation of Chapter 11.5 sits on top of: NVIDIA's device-identity certificate chain and NRAS/RIM verification establish that the GPU is genuine and running attested firmware, but a confidential-computing claim is only as strong as the host platform underneath it — a compromised BMC or tampered host firmware can undermine a perfectly-attested GPU. Attestation composes from the silicon RoT upward; skip the platform layer and you have built a tall trust chain on an unverified foundation. The honest caveat, expanded in Chapter 11.5: attestation proves provenance and integrity at boot, not the absence of every side channel or a benevolent operator — it is a necessary foundation, not a panacea.

Here is the limitation that quietly defeats a measured-boot-only posture: attestation proves what loaded at t=0 and says nothing about minute 10,000. An AI cluster runs for years between reboots. Runtime firmware exploits, malicious post-boot updates, and physical tampering all happen after the boot measurement is taken and signed. A defense that attests at boot and then never looks again is blind to exactly the persistent implant that firmware attacks are designed to plant. The mature posture adds continuous integrity monitoring: periodic re-measurement and re-attestation of firmware while the system runs, watching SPI flash and BMC firmware for unauthorized change, and tying anomalies into the SOC's detection coverage (Chapter 11.12) and the GPU/host telemetry pipeline (Chapter 10.6).

The OCP S.A.F.E. (Security Appraisal Framework and Enablement) program is the supply-side complement to runtime monitoring: it standardizes independent third-party security audits of device firmware by accredited Security Review Providers, producing cryptographically signed, machine-readable short-form reports that identify the vendor, device, and firmware by hash. It does not watch your fleet at runtime — it raises the floor on the firmware you onboard, so 'the firmware we shipped was independently audited' becomes a procurement requirement (the supply-chain framing is Chapter 11.3) rather than a vendor's promise. The two fit together: S.A.F.E. and signed RIMs establish what good looks like at intake; continuous monitoring detects drift from it in production.

Firmware security is a posture you commit to at procurement and enforce every boot, not a product you buy. The forks compound: an open silicon RoT or a vendor black box; a discrete TPM alone or paired with an internal RoT on a DC-SCM; attestation as a gate or as a logbook; signed-and-anti-rollback updates or a fleet that trusts any push; boot-time measurement only or continuous monitoring; PQC-ready roots or pre-quantum keys on a 6-year asset. Choose the weak side of each and you have not saved money — you have built every higher control in Part 11 on a layer that can lie, on assets too valuable to brick and too IP-rich to wiretap, with a detection stack that cannot see the one place a real adversary will live. The MegaRAC 10.0 is the cheap lesson; the expensive one is the implant nobody finds for three years.