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 firmware that booted before any of it existed. If that firmware lied about what it loaded, none of the controls above it mean anything. That makes firmware the highest-value target in the building. It is the most privileged code, running before and beneath the hypervisor and the OS. It is the most persistent. A BMC or SPI-flash implant outlasts an OS reinstall and a disk wipe, and firmware on a part that travels with the chassis (a pluggable management module, a NIC, a GPU) can even outlast a board replacement. And it is the least observed, because 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 a decision framework for the layer beneath the OS. It starts with why firmware is the target and what a hardware root of trust (RoT) buys: the silicon-anchored chain that gives every higher claim, including the GPU attestation of Chapter 11.5, its meaning. Next come 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. The BMC gets treated as the parallel computer it is, with its own threat model and segmentation discipline. 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. In an AI data center the economics invert, 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. An attacker who can brick one from the management plane holds 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 meant to protect them, with a clear line of sight to plaintext in host memory and over PCIe (weight protection is Chapter 11.8). Third, firmware 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 detection stack you built for the OS and the network.

This is not hypothetical. The canonical example arrived in 2025: 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 who reaches the Redfish interface can deploy malware, tamper with firmware, brick the BMC or BIOS, and force unrecoverable reboot loops. Because BMCs on a flat management segment can command their neighbors, the attacker can also pivot to every other BMC on the same VLAN. Eclypsium reported roughly 1,000 internet-exposed instances on 18 March 2025; that search establishes exposure, not exploitability or compromise of every device. The BMC stack a server runs, whether a proprietary one like MegaRAC that reaches you through the OEM or open-source OpenBMC, decides who ships the fix for a flaw like this and how fast it reaches your fleet (Chapter 8.7). 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. It is 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 design the hyperscalers are pushing through OCP roots trust in an open, immutable, dedicated silicon RoT that boots first, measures everything else, and has an implementation you can read.

The reference design is Caliptra, an open-source silicon RoT specification contributed to OCP by Microsoft, Google, AMD and NVIDIA in 2022 and now developed under CHIPS Alliance. AMD has committed to integrate it from its 2026+ products. Confirm per part whether the shipped silicon carries Caliptra or a proprietary root. Caliptra is an internal RoT: a hardware block inside the SoC, not a discrete TPM hanging off a bus an attacker can interpose on. It 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.

By design, changing even one bit of any layer's firmware changes every key derived after it, so a tampered boot chain cannot reproduce a clean chain's attestation. Implementations can still break that property. In August 2026 the Caliptra project published an advisory for its Core ROM (CVE-2026-11835). It affects ROM 2.1.0 and 2.1.1 in subsystem mode, is rated medium, and is fixed in ROM 2.1.2. An attacker who already controls the companion microcontroller's firmware could change the image after verification, and attestation would still report the original digest. The project issued several other advisories in 2026. Because ROM is burned into the silicon, ask which ROM release your part carries and check it against the advisory list.

Caliptra 2.x (the 2025 line) adds something the long-lived-asset thesis of this guide demands: post-quantum cryptography in the root itself. With 2.1 (October 2025), the open-source Adams Bridge accelerator implements NIST's ML-DSA (signatures) and ML-KEM (key encapsulation) with side-channel countermeasures. Caliptra 2.2 is announced and scheduled for release in December 2026 (Microsoft, 13 October 2026). It halves the Adams Bridge area with a fully masked design and adds a USB controller for streaming boot, dual-core lockstep, control-flow monitoring and hardened PCRs. Until it ships, 2.1 is the latest released line, so ask which Caliptra release and ROM version your 2027 parts carry. 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 stay confidential and whose attestation signatures must stay 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 is in Chapter 11.8.

Read the table as a decision, not 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 modification before the next boot measures it. An internal silicon RoT can shrink 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. A DC-SCM 2.0 label alone establishes neither that integration nor complete coverage. At the October 2026 OCP Summit, Microsoft demonstrated another arrangement: the host TPM moves into the BMC's root-of-trust co-processor, the host keeps its standard TPM interface, and measurements stay readable out of band when the host OS is down. It is a demo with published source code, not a shipping product. The nine-axis matrix below asks what each mechanism 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. Instead of soldering the BMC, the RoT and the TPM onto the motherboard, where they are tied to that board's design, firmware lifecycle and supply chain, DC-SCM moves all of the management, security and control logic onto a pluggable module that mates to the host board over a standard connector. The 2.x generation (2.1 in 2023, now Rev 2.2 from September 2025 with LTPI 1.2; a DC-SCM 3.0 sub-project has started) 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 OCP MGX 1.2 specification (effective 6 October 2026) adds a compact module that stands vertically in a 1RU tray. It uses the same SFF-TA-1002 connector but only a subset of the DC-SCI pins, so check form factor and pinout before moving a module between an MGX tray and a standard 2.x slot. Between the host board and the module, OCP's OBMF-ICP 1.0.0 (7 October 2026) carries GPIO, I2C, UART, SPI, TPM and IPMI traffic as channels over one link such as USB. It has no encryption of its own, so a TPM or other sensitive channel needs its own protection or an SPDM session.

The consequence is threefold. First, supply-chain provenance (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-validating the entire server, which matters when a 10.0 BMC CVE lands mid-deployment. Third, the management plane becomes a discrete, attestable unit. The RoT on the DC-SCM measures and gates the BMC's own firmware, so the controller with god-mode over the host is itself rooted in silicon you trust. The leading modules pair an internal RoT, an ASPEED AST2600/AST2700-class BMC and a discrete TPM 2.0 on one card, which is the layered posture the table above argues for, productized.

Two mechanisms are routinely conflated, and they 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 that 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. The result is a cryptographic transcript of exactly what ran, in order. It stops nothing; it produces a tamper-evident record you can attest against later. 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 way a fleet can 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 is SP 800-193 (Platform Firmware Resiliency): protect, detect, recover. It comes with SP 1800-34 (supply-chain provenance) and IR 8320 (hardware-enabled security). Whether any of this defends anything depends on one decision: do you enforce on the measurement? That means a node enters the cluster, receives weights and gets traffic only after its measured-boot quote validates against a known-good golden value. 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 fails quietly. 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, with no unsigned TFTP pushes and 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 and re-open a patched hole. Verify that trusted hardware enforces the counter and how recovery treats it; 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). Demonstrate it with interruption tests on the shipped platform. That turns a failed or interrupted update into a recoverable event; it does not protect the node from denial of service.

Test the verifier, not the checkbox. In September 2025 Binarly disclosed that Supermicro BMC images could redirect signature checking to tables placed in unsigned space (CVE-2025-7937 and CVE-2025-6198), so an attacker with admin access could install persistent firmware past the BMC root of trust. Ask whether the verifier fixes the signed layout itself or trusts one the image describes, whether every boot stage including the kernel is authenticated, and how signing keys are scoped: per product line, or one key for the whole ecosystem.

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. Getting this wrong has a severe and specific consequence: 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, test forward recovery or replace the unit. A second A/B image does not help when a compromised signing key or the same corruption reaches both copies. Streaming boot, which Microsoft developed with OCP, lets devices run without local firmware flash: firmware arrives over I3C, USB or PCIe, and the device authenticates and measures it in isolated memory before it runs. Boot and recovery then share one path. Microsoft calls streaming boot a default Caliptra capability and demonstrated it over USB at the October 2026 OCP Summit.

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 and the node returns signed evidence from its supported RoT/TPM interface. The verifier obtains authenticated per-component Reference Integrity Manifests (RIMs), the vendor-signed golden hashes of legitimate firmware, and compares the quote against known-good values for that exact hardware and firmware version. If policy matches 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. If the evidence mismatches, is invalid, or verification is 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; your acceptance record must name the protocol and version the platform actually implements.

This platform attestation is the foundation under the GPU attestation of Chapter 11.5. 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. One open way to compose the platform part is Microsoft's Composite Entity Attestation Token (EAT), which Microsoft said on 13 October 2026 it has contributed to OCP. The BMC collects fresh evidence from CPUs, GPUs, drives and NICs, and its root of trust binds that evidence to the BMC's own measurements in one signed platform token; reference code ships in ASPEED and Nuvoton BMC and RoT SDKs. Ask whether your BMC emits it and which verifier appraises it. The 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.

A fresh quote over boot-time measurements does not, by itself, remeasure runtime state at minute 10,000. That limitation defeats a measured-boot-only posture. A fleet can keep nodes running for long intervals between measured boots, and 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 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 feeding 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, and produces 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, and runtime monitoring can detect drift in what it covers, while unmeasured state remains a residual gap.

Firmware security is a posture you commit to at procurement and enforce on 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, 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 5–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.