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.

The rest of the chapter is the decision framework for the layer beneath the OS. It begins with why firmware is the target and what a hardware root of trust (RoT) actually buys — the silicon-anchored chain that makes every higher claim, including the GPU attestation of Chapter 11.5, mean something. From there: secure and measured boot, firmware-update integrity, and platform attestation — the machinery that lets a node prove, to your fleet and not just to itself, what it is running. The BMC gets treated as the parallel computer it is, with its own threat model and its own segmentation discipline, and the chapter closes 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 about $3.1M server-only in the August 2025 hyperscaler model, with a separate accelerator-allocation constraint, and the GB300 NVL72 racks filling 2026 halls sit in the same allocation queue, 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. Eclypsium reported roughly 1,000 internet-exposed instances on 18 March 2025; the search establishes exposure, not exploitability or compromise of every device. The most privileged, most persistent, least-watched computer in the rack shipped with a CVSS 10.0.

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. ML-KEM protects long-lived ciphertext confidentiality against harvest-now-decrypt-later collection; ML-DSA protects future signature authenticity against forge-later attacks. For a GPU asset on a 5-6 year book life whose encrypted secrets must remain confidential and whose attestation signatures must remain authentic 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 supplies particular evidence, not a complete platform defense. 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. An internal silicon RoT can reduce the exposed trust boundary — it lives inside the package, and can authenticate and measure the first mutable firmware before execution; verify coverage and enforcement in the shipped implementation. One implementation uses both: a discrete TPM 2.0 for the platform measured-boot PCRs and an internal RoT (Caliptra-class) anchoring the silicon identity, but a DC-SCM 2.0 label alone establishes neither integration nor complete coverage. The nine-axis receipt below asks what each mechanism actually covers and what admission does when its evidence fails.

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 (2.1 spec released 2023; reference designs proliferating through 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 a tamper-evident 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 determines whether the implementation defends anything 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 — verify the counter’s trusted enforcement and recovery semantics; the security version need not equal a marketing release number. 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), demonstrated by interruption tests on the shipped platform; this limits recoverable update faults without promising immunity from denial of service.

At fleet scale the available interfaces include: 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. If the patch channel is compromised, use an independently trusted recovery path. Preserve anti-rollback enforcement during recovery; where downgrade is forbidden, qualify forward recovery or replace the unit.

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 returns signed evidence from its supported RoT/TPM interface, and the verifier obtains authenticated per-component Reference Integrity Manifests (RIMs) — the vendor-signed golden hashes of legitimate firmware — then compares the quote against known-good values for that exact hardware and firmware version. A policy match for the complete required evidence → the node may be 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, invalid evidence or verification unavailable → hold admission and classify the cause. The DMTF SPDM editions — DSP0274 1.4.1 (2 July 2026), DSP0277 2.0.0 and DSP0289 1.0.0 (8 December 2025), DSP0294 1.0.0 (31 August 2026) — describe available interfaces; the receipt must name the protocol/version actually implemented.

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 remains an availability or unprotected-platform threat even when the GPU evidence passes. A confidential release must compose the required CPU/CVM, GPU and workload evidence; 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.

One limitation quietly defeats a measured-boot-only posture: a fresh quote over boot-time measurements does not, by itself, remeasure runtime state at minute 10,000. A fleet can keep nodes running for long intervals between measured boots. 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: supported runtime remeasurement and fresh attestation of the objects each mechanism actually covers, 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; runtime monitoring can detect covered drift, while unmeasured state remains a residual boundary.

Firmware security is a posture you commit to at procurement and enforce every boot; it is 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 was the cheap lesson; the expensive one is the implant nobody finds for years.