Measured Boot and Platform Integrity for AI Servers

Measured boot builds a cryptographic record of everything that runs on a server before the operating system loads: firmware, bootloader, kernel, all of it. It watches rather than blocks, making sure nobody can lie about what happened afterward. Once GPUs start handling model weights and customer data, that distinction stops being academic and turns into the whole ballgame.

People confuse Secure Boot with Measured Boot constantly, and the mix-up costs real security margin. Secure Boot blocks unsigned code before it runs, no exceptions. Measured Boot does something else: it watches what runs and writes down a hash of it, building a log as the machine boots, without stopping anything itself. A system can sail through Secure Boot with every signature green and still have been tampered with in a way only the Measured Boot log catches. A record that only ever shows good outcomes is a rubber stamp, not evidence; Measured Boot exists so operators aren't stuck with a rubber stamp when it counts.

For AI infrastructure this stops being theoretical fast. An operator loading proprietary model weights onto a GPU cluster, or routing a customer's inference data through a shared fleet, needs a way to check the platform wasn't quietly altered somewhere between the loading dock and the data center floor. The question is whether it booted the exact stack it was supposed to. The sections below cover how that evidence gets built, why the boot chain became such an attractive target once AI workloads raised the stakes, and where the model still has gaps worth knowing about.

How PCR measurements accumulate from firmware through OS

Every component in the boot sequence gets measured before it's allowed to run: the UEFI or BIOS code, the bootloader, the OS kernel, the Secure Boot policy itself. Each produces a cryptographic hash, and that hash lands in a Platform Configuration Register, a PCR, inside the TPM.

Here's the part that makes the whole thing work: a new measurement extends the PCR instead of overwriting it. The TPM takes the current PCR value, appends the new hash, and hashes the result again, so PCR_new equals hash of PCR_old combined with the new measurement. Every later measurement chains mathematically to every earlier one. Change anything in the boot sequence, even something measured five steps back, and every PCR value computed after that point changes too. Nobody sneaks back and edits step two once the system's on step six. By the time the OS finishes loading, the final PCR values encode the entire ordered history of what ran, and that history doesn't forge quietly.

The PCRs live inside the TPM chip, walled off in hardware; the OS can read them but can't rewrite them. Different PCR indexes get assigned by convention to different stages, one for firmware, one for the boot manager, one for the OS loader, one for the kernel command line. Build an attestation policy without knowing which PCR maps to which component and you're building on guesswork. That's a bad place to stand when the policy is your entire trust boundary.

Identity here runs through two keys. The Endorsement Key, the EK, gets burned into the TPM at manufacture; the private half never leaves the chip, not even for the OS to see. It's the hardware root of identity. Using the EK directly in every attestation would leak a persistent hardware fingerprint, though, so TPMs use an Attestation Identity Key instead, an AIK, derived from the EK but safe to expose repeatedly. When a remote party wants proof of what booted, the TPM bundles the current PCR values into a quote and signs it with the AIK. That signed quote is what leaves the machine and lands in a verifier's hands.

Measured boot's job ends when the OS takes over, but the integrity story keeps going. Linux's Integrity Measurement Architecture, IMA, extends the same idea into runtime, measuring kernel modules and executables as they load after the system is already up. Measured boot covers pre-OS, IMA picks up the rest, and together they span the whole life of a running system instead of just its first few seconds.

Why the boot process became a high-value target for attackers against AI workloads

A compromise low in the boot chain doesn't stay contained. Replace the bootloader or hypervisor on a shared host and every workload sitting on top of it is compromised too, not just the one an attacker was originally after. That's the blast radius problem, and it's worse on AI infrastructure than on a typical web fleet, since one GPU node might serve inference for dozens of tenants at once.

Bootkits exploit exactly this setup. They grab control before any conventional security tool loads, run at the highest privilege level available, and stay invisible to antivirus or endpoint detection that only wakes up once the OS is running. By the time an EDR agent starts watching, the bootkit already has the keys.

Firmware compromise goes further. It survives an OS reinstall. It survives most forensics too, because forensic tools generally assume the firmware underneath them is honest, which is exactly the assumption a firmware implant breaks. Few hiding spots in a modern server come close.

There's a gap specific to AI compute that doesn't get discussed nearly enough: data in use. TLS protects data moving across a network. Disk encryption protects data sitting on a drive. Neither protects model weights or inference inputs sitting in plaintext inside GPU VRAM during active computation, which is exactly where that data has to sit for the GPU to do anything useful with it. A privileged process on a compromised host can read that memory directly. Network controls and storage controls do nothing to stop it, because the data was never encrypted at that layer to begin with.

Add AI-specific stakes on top of ordinary server risk and the target gets a lot more attractive. Model weights represent real intellectual property, sometimes a company's entire edge. Inference inputs often carry sensitive personal or business data. GPU clusters at scale run on shared management and orchestration networks, so one compromised node isn't an isolated event; it's a pivot point into everything else on the fabric.

The BMC as an integrity blind spot beneath the measured boot chain

Everything above assumes the CPU's measured boot sequence is the first thing that runs. It isn't. Underneath it sits the Baseboard Management Controller, the BMC, a separate, autonomous controller with its own firmware, its own tiny OS, its own network stack, reachable even when the host is powered off.

That's genuinely useful for remote server management. It's also a real problem if the BMC can't be trusted, because it can alter boot parameters, flash new firmware, and change server state before the CPU's measured boot sequence has even started. A compromised BMC doesn't need to fight the measured boot chain at all. It can corrupt the inputs that chain is supposed to measure before measurement even begins.

None of this is hypothetical. NVIDIA's own security research found 18 vulnerabilities in BMC firmware used widely across data centers and built 9 working exploits against them. At internet scale, researchers found 36,872 server-management interfaces exposed directly to the internet; of those tested, 24,650 leaked password-derived authentication hashes before any login occurred, courtesy of CVE-2013-4786, opening the door to offline password cracking on systems that were never supposed to be reachable at all. In 2025, CVE-2024-54085, a maximum-severity 10-out-of-10 flaw in AMI's MegaRAC BMC firmware, landed on CISA's Known Exploited Vulnerabilities catalog in June, the first BMC vulnerability ever added to that list. The blast radius here isn't narrow.

What does this mean for everything above? Measured boot of the CPU stack produces strong evidence about what the CPU booted, but only if the inputs feeding that process were honest to begin with. Break that assumption at the BMC and the evidence gets compromised before it's even generated. BMC integrity is a load-bearing wall the whole chain leans on. Keep IPMI interfaces off the internet entirely, run BMC management over a dedicated out-of-band network, verify BMC firmware signing before any update lands, and use vendor-provided BMC attestation wherever it exists.

How GPU attestation extends the chain of trust to cover AI compute

Even a perfectly attested CPU trusted execution environment leaves a gap wide open: it says nothing about what happens inside the GPU. Model weights and intermediate activations computed there sit entirely outside the CPU's trust boundary. An odd place to draw the line, given that the GPU is doing most of the actual work.

NVIDIA's answer is a hardware root of trust fused into the silicon at manufacture, a private signing key that never touches software, firmware, or the host system. It plays roughly the same role for the GPU that the EK plays for the TPM. On H100 and Blackwell-generation GPUs, the sequence runs like this: the GPU boots into Confidential Computing mode, CC-On; hardware protections for code and data switch on; an SPDM session connects the GPU securely to the driver running inside the CPU's trusted execution environment; and the GPU produces a signed attestation report containing its measurements.

That report doesn't verify itself. NVIDIA's Remote Attestation Service, NRAS, checks the evidence against golden measurements stored in a Reference Integrity Manifest service, while a separate OCSP service handles certificate status. On the newest hardware, Blackwell HGX B200 and HGX B300 systems, confidential computing extends across as many as 8 GPUs at once, with NVLink encryption carrying the trust boundary across the whole NVSwitch fabric instead of stopping at a single card.

The more interesting development sits on the composite side. Intel Trust Authority can now attest a CPU TDX confidential VM and NVIDIA's confidential-computing GPUs in one workflow, under one policy, through one verifier, covering both halves of the compute stack that used to need separate trust stories. This isn't theoretical either: in March 2026, Corvex announced a verified production deployment of confidential computing on NVIDIA HGX B200 systems, running CPU-plus-GPU composite attestation through Intel Trust Authority in production. On performance, benchmarking on HGX B300 with a large-scale model found confidential computing added under 8% overhead to throughput and latency combined. That number matters more than it looks at first glance. It's roughly the point where the old objection, that confidential computing costs too much to run in production, stops holding up.

How remote attestation turns PCR measurements into a verifiable trust decision

All of this machinery, the PCR chain, the BMC checks, the GPU attestation reports, exists to feed one decision: should this platform be trusted with the workload sitting in front of it? Remote attestation turns raw measurements into that yes-or-no call.

The flow runs fairly straight. The TPM produces a signed quote of its PCR values, signed with the AIK. That quote travels to a remote verifier, something like Intel Trust Authority, which checks it against an attestation policy encoding the expected measurements for a clean, known-good boot. Match the policy and the platform gets trusted; secrets, encryption keys, or workloads get released to it. Miss the policy and that mismatch is itself the finding, a failed verification that blocks access quietly and by design.

Writing that policy correctly is harder than it sounds. It has to encode, exactly, what a clean boot of this specific hardware, running this specific firmware version, this OS, this kernel, is supposed to produce. Too loose and it stops catching real tampering. Too rigid and every routine patch breaks it. Cloud providers have already built working versions of this. Azure's Trusted Launch gives each VM a TPM 2.0-compliant vTPM measuring the full boot chain, and a Host Attestation Service checks host machines against policy before those hosts ever touch customer workloads, running the whole check inside a locked-down environment per cluster. Google Cloud's Shielded VMs root their vTPM in Titan security chips, and operators can turn on attestation for AI workloads with a single flag at VM creation.

One technique worth flagging: Unified Kernel Images, UKIs, bundle the kernel, initramfs, and boot parameters into a single signed binary. Instead of measuring three separate artifacts, you measure one, and the kernel command line, including the dm-verity root hash, sits sealed inside where it can't change without changing the measurement covering the whole bundle.

What happens on a cluster running autoscaling, where nodes come and go all day? Attestation isn't a setup step done once and left alone. Every boot, on every node, needs verification before that node touches sensitive workloads, which means the check has to live inside the orchestration layer itself, not get bolted on afterward as an audit step. That's a real operational commitment. There's a trust angle worth sitting with too: an operator running AI infrastructure for customers can hand them this attestation evidence directly, giving the customer something to go check for themselves rather than a claim to take on faith. Moving from a promise to a proof is most of the point of building any of this.

The firmware supply chain as the weakest link in any attestation policy

Attestation works by comparing measurements against an expected value. So where does "expected" actually come from? Vendor-signed firmware. If the signing keys behind that firmware get compromised, an attacker can build firmware that produces exactly the expected measurement while doing something completely different underneath. The verifier checks the box. The box was never honest to begin with.

That's not a hypothetical worry. Between 2022 and 2025, a string of signing-key incidents hit the industry: leaked Boot Guard private keys traced to multiple major server vendors, including Lenovo, Supermicro, MSI, and Clevo; expired certificates inside Intel's PPAM program; test keys that somehow shipped in production firmware. Taken together, these opened conditions where an attacker could plausibly bypass UEFI Secure Boot across a wide swath of deployed hardware, not one vendor's line but many at once.

In July 2025, researchers disclosed four CVEs in Gigabyte UEFI firmware allowing code execution inside System Management Mode, SMM, and bypassing both Secure Boot and Intel BootGuard in the process. SMM runs at a privilege level below the OS, often below what measured boot even captures. Code planted there survives reboots while sitting entirely outside the measurement boundary this piece has been describing. That's a genuine blind spot, and not a small one.

So what actually helps here? Vendors release firmware patches, and operators need to apply them fast. Just as important, they need to re-baseline their attestation policies every time a firmware update lands, since the expected measurement shifts along with the firmware. NIST SP 800-155 defines Reference Integrity Manifests, RIMs, vendor-signed statements of expected firmware measurements a verifier can check without trusting an operator's self-reported baseline. On procurement, sourcing hardware only from verified channels, using tamper-evident packaging, and keeping a live inventory of firmware versions across the fleet before any node touches production all cut the odds of an already-compromised board entering the chain in the first place.

The structural point underneath all of this: measured boot gives strong evidence, but that evidence is only as honest as the signing and measurement infrastructure that built the baseline. Firmware supply chain security is part of the attestation threat model whether operators treat it that way or not.

What operators deploying AI infrastructure should verify at each layer of the stack

Pull the whole chain together, from the BMC up through the GPU, and a rough set of checks falls out for anyone actually running this hardware in production.

Start at the BMC. Verify its firmware version and signature before trusting anything the CPU measures afterward, isolate BMC and IPMI interfaces on a dedicated out-of-band network that never touches the public internet, and confirm the update channel is authenticated and supply-chain verified. Skip this layer and everything measured above it is standing on sand.

Move up to firmware and UEFI. Keep a firmware inventory for every node and check it against vendor RIMs before that node goes into production. Apply UEFI patches quickly and re-baseline PCR policies right after. Audit the signing chain periodically for leftover test keys or expired certificates, the exact conditions behind real incidents from 2022 through 2025.

At the CPU boot chain layer, enable measured boot with a hardware TPM 2.0 or vTPM, and confirm the PCR registers actually cover UEFI, bootloader, kernel, and command line, not some convenient subset. Use UKIs where the platform supports them, to shrink the number of separately measured artifacts and seal the kernel command line against tampering. Write attestation policies specific to each node class rather than one loose policy meant to cover everything. A catch-all policy barely beats no policy at all.

Runtime matters too. Turn on IMA to extend measurement past boot into kernel module and executable loading, and feed those IMA logs into the same remote attestation workflow, so runtime integrity isn't some separate, unverified story running alongside boot integrity.

At the GPU layer, turn on CC-On mode on H100 or Blackwell GPUs for any workload touching sensitive model weights or user data, require GPU attestation report validation through NRAS before releasing secrets to the workload, and use composite CPU-plus-GPU attestation wherever the deployment allows it. A chain of trust covering only half the compute stack isn't much of a chain.

None of this is a one-time job. Every layer here depends on the layer below it staying honest, which means the whole structure needs re-checking on a rolling basis as firmware updates, GPU drivers, and orchestration tooling keep shifting underneath it. That's what running AI infrastructure this way actually costs. It's also most of the reason it's worth doing at all.