Parag Mali - tag: uefi

Below the OS: The Pre-Boot Trust Chain Where Secure Boot Inherits Its Trust From

noreply@paragmali.com (Parag Mali) — Wed, 03 Jun 2026 00:00:00 GMT

**Secure Boot is not where trust begins on a modern PC.** It is the fifth rung in an eleven-rung pre-OS chain that starts with a one-time-programmable fuse inside the chipset and travels through Intel Boot Guard or AMD Platform Secure Boot, through an on-die security processor (Intel CSME on MINIX 3, or AMD's ARM Cortex-A5 Secure Processor), through UEFI and Measured Boot, before it ever loads `winload.efi`. Every rung's verifier inherits the trust of the rung below it -- and the chain's revocation surface narrows monotonically as you descend. The April 2023 MSI / Money Message OEM-key leak [@binarly-msi] and the May 9, 2023 KB5025885 boot-manager revocation programme [@kb5025885] are the two worked examples that make the asymmetric-revocation argument concrete: at the fuse layer, there is no revocation primitive at all. flowchart TD R0["Rung 0: CPU reset vector at 0xFFFFFFF0"] subgraph IL["Intel path"] I1["Rung 1: Microcode loads from SPI patch area"] I2["Rung 2: Authenticated Code Module verified vs silicon-fused Intel key"] I3["Rung 3: ACM reads Field Programmable Fuse, verifies KM and BPM"] I4["Rung 4: Initial Boot Block hashed and compared to BPM"] end subgraph AL["AMD path"] A1["Rung 1: ARM Cortex-A5 PSP comes out of reset before x86 cores"] A2["Rung 2: PSP boot ROM verifies PSP firmware vs AMD root key hash"] A3["Rung 3: PSP reads OEM-key fuse, verifies signed BIOS image"] A4["Rung 4: PSP releases x86 BSP from reset"] end R5["Rung 5: SEC and PEI phases, memory init, cache as RAM"] R6["Rung 6: DXE drivers loaded, UEFI variable services online"] R7["Rung 7: Secure Boot evaluates Authenticode against PK, KEK, db, dbx"] R8["Rung 8: Boot Device Selection picks bootmgfw.efi"] R9["Rung 9: Boot Manager loads, Measured Boot extends PCR 4 through 7"] R10["Rung 10: bootmgfw.efi verifies winload.efi"] R11["Rung 11: Hand-off to winload.efi"] R0 --> I1 R0 --> A1 I1 --> I2 --> I3 --> I4 --> R5 A1 --> A2 --> A3 --> A4 --> R5 R5 --> R6 --> R7 --> R8 --> R9 --> R10 --> R11

1. Permanently Downgraded to a Weaker Trust Model

On April 6, 2023, the Money Message ransomware actor published roughly 1.5 TB of MSI source code to a TOR-hosted leak site after MSI declined to pay a reported $4M ransom [@helpnet-msi-leak]. A month later, on May 5, Binarly's efiXplorer team opened the archive. Inside, they found something worse than source code. They found the Intel Boot Guard Key Manifest and Boot Policy Manifest private keys covering roughly 116 MSI systems, plus image-signing keys for 57 more products, with cross-OEM contamination across HP, Lenovo, AOPEN, CompuLab, and Star Labs [@binarly-msi] [@helpnet-msi-leak] [@register-msi-alt]. The affected platform generations spanned Tiger Lake, Alder Lake, and Raptor Lake [@register-msi-alt]. Binarly published a per-device impact catalogue in their SupplyChainAttacks repository for triage by the affected vendors [@binarly-supply-chain].

Those private keys correspond to public-key hashes that have already been burned, one-time-programmably, into a fuse inside the chipset of every affected machine. There is no revocation primitive at that fuse layer. Intel cannot patch this. MSI cannot patch this. Microsoft cannot patch this.

Note: Every Intel system whose Field Programmable Fuse holds the hash of a leaked MSI OEM public key is now in a permanent state of reduced assurance against firmware tampering. The leak does not require a successful in-the-wild exploit to count as damage. The capability transfer happened the moment Money Message published the archive [@binarly-msi].

This story matters because most public writing about "the boot security chain on a Windows PC" stops at Secure Boot. The popular framing -- that the Platform Key (PK) is the trust anchor and the rest of the chain hangs from it -- is not just incomplete. It is upside down. Secure Boot's PK is a tenant of UEFI authenticated NVRAM stored in the SPI flash chip soldered next to the chipset [@uefi-specs]. PK's integrity depends on the SPI flash being unwritable to attackers. That property is what the rung below Secure Boot enforces. Without the lower-rung silicon-fused verifier, PK is just bytes in flash.

A bootkit is malware that survives in the pre-OS firmware boot path. It runs before the kernel exists and outlives both reboots and clean OS installs. Two recent ones bracket the operational threat.

BlackLotus [@eset-blacklotus]. Analysed by ESET researcher Martin Smolar on March 1, 2023, sold on hacking forums since October 2022. It was the first public UEFI bootkit observed bypassing Secure Boot on fully-patched Windows 11, via CVE-2022-21894 [@cve-2022-21894-nvd].
Bootkitty [@bootkitty] [@helpnet-bootkitty]. Disclosed by ESET on November 27, 2024. It was the first analogue for Linux.

These are the threats the pre-boot chain exists to defeat. And the pre-boot chain works only as well as the layer below it.

Why is the most permanent layer of the trust chain also the layer with no recovery surface?

To answer that question, we have to walk down from the rung you know -- Secure Boot -- to the rung you probably do not: the fuse.

That walk is the article. The eleven-rung diagram in the TLDR is the map. Along the way we will visit Intel Boot Guard, AMD Platform Secure Boot, the Intel Converged Security and Management Engine, and the AMD Platform Security Processor. We will see what gets verified, by what, and against what trust anchor. And we will see, three times at three increasing levels of compression, why the chain's revocation surface narrows monotonically as you descend, until at the bottom there is no revocation at all. Companion articles on Secure Boot, Measured Boot, Pluton, ACPI Tables, and Secured-core PCs cover the rungs above this one. This article's lane is everything below them.

2. From "BIOS Is Trusted Because Nobody Can Write to It" to "BIOS Has Its Own SoC"

On September 13, 2011, Symantec analyst Liam Ge published an early analysis of Trojan.Mebromi on Symantec Connect [@symantec-bios-threat]; Liam O'Murchu's contemporaneous Symantec Threat Intelligence writeup is the source MITRE catalogues at ATT&CK ID S0001 as the canonical primary [@mitre-mebromi-s0001]. Mebromi was the first in-the-wild BIOS rootkit observed on shipping consumer PCs. It rewrote the Award BIOS Master Boot Record code so that it reinjected itself into the OS on every boot. The Wikipedia BIOS security section preserves the same provenance [@wiki-bios-security].

Four months earlier, in April 2011, NIST had published SP 800-147 ("BIOS Protection Guidelines") attempting to mandate the cure: signed BIOS updates with an authenticated update mechanism rooted in immutable code [@nist-sp-800-147]. The cure arrived just as the disease made its in-the-wild debut. That four-month gap captures the entire history of pre-boot security on the PC platform: the defensive architecture always lags the attacker by roughly one generation, and each generation moves the trust anchor one layer closer to the silicon.

Generation 1 -- Trust by physical inaccessibility (pre-2011)

The implicit model from the IBM PC through the late 2000s was that nobody could write to the BIOS ROM, so the BIOS was trusted because it was unreachable. That model held only as long as nobody bothered. By 2011 the protections that had compensated for writable flash (the BIOSWE, BLE, SMM_BWP, and FLOCKDN chipset configuration bits described in the contemporary CHIPSEC literature [@c7zero-chipsec]) were widely misconfigured on shipping platforms. Academic SPI-rewrite research predated Mebromi by nearly a decade. Mebromi simply demonstrated that the field had caught up.

Generation 2 -- Signed BIOS updates anchored in BIOS (2011-2013)

NIST SP 800-147 [@nist-sp-800-147] and OEM responses to Mebromi produced a generation of platforms that signed BIOS updates and verified the signature before flashing. The structural flaw was immediate: the verifier lived in the region it was verifying. Burn the verifier with the update payload and you owned the next boot. Seven years later NIST SP 800-193 ("Platform Firmware Resiliency Guidelines") explicitly raised the bar from Protection alone to Protection plus Detection plus Recovery [@nist-sp-800-193], implicitly conceding that Gen 2 had not closed the loop.

Generation 3 -- The trust anchor moves into silicon (2013-2015)

In the second quarter of 2013, Intel shipped Boot Guard alongside the Haswell CPU family. In the first half of 2014, AMD shipped the Platform Security Processor with the Family 16h "Beema" and "Mullins" mobile parts [@wiki-amd-psp]. The Wikipedia entry for AMD PSP records the architecture cleanly: "The PSP itself represents an ARM core (ARM Cortex-A5) with the TrustZone extension ... inserted into the main CPU die as a coprocessor" [@wiki-amd-psp]. With Gen 3, the trust anchor moved out of mutable storage entirely. The verifier was no longer a region of flash; it was a piece of silicon that could not be rewritten without replacing the chip.

In 2015, the Skylake CPU family shipped with ME 11, the first ME generation built on the Intel Quark x86 core (replacing the ARC-based predecessors) and running a modified MINIX 3 microkernel as its on-die runtime [@wiki-ime] [@wiki-ime-history]. The Converged Security and Management Engine (CSME) brand name folded ME, TXE, and SPS into a single architectural label.

In November 2017, Andrew S. Tanenbaum -- the creator of MINIX 3 -- published an open letter to Intel that read in part: *"Thanks for putting a version of MINIX inside the ME-11 management engine chip used on almost all recent desktop and laptop computers in the world"* [@tanenbaum-letter]. The hosted letter at cs.vu.nl carries no explicit publication date; the early-November dating derives from contemporaneous press coverage. Intel had never consulted him; he learned about MINIX's role only when independent researchers reverse-engineered the ME runtime.

The cultural moment mattered because it surfaced something the architecture had hidden: every modern Intel PC ships a second operating system, on a second processor, that boots before yours does. The trust chain you are reading about exists in part because that second OS exists.

ME 11 ran MINIX. Earlier ME generations (ME 1 through ME 10) ran ThreadX on ARC cores. Later CSME generations from Ice Lake forward moved to a Tremont-class x86 core but kept the MINIX 3 runtime [@wiki-ime] [@wiki-ime-history].

Thanks for putting a version of MINIX inside the ME-11 management engine chip used on almost all recent desktop and laptop computers in the world. -- Andrew S. Tanenbaum, November 2017 [@tanenbaum-letter]

A month after Tanenbaum's letter, on December 7, 2017, Mark Ermolov and Maxim Goryachy presented "How to Hack a Turned-Off Computer" at Black Hat Europe 2017 [@ermolov-goryachy-2017]. The talk demonstrated unsigned-code execution in the CSME via the JTAG / Direct Connect Interface chain that became Intel security advisory INTEL-SA-00086 [@intel-sa-00086]. Intel's CSME security white paper postdates the disclosure and treats the same architecture from the vendor side [@intel-csme-whitepaper]. A year later, in 2018, Yuriy Bulygin presented "A Tale of Disappearing SPI and the Intel Boot Guard Enchanted Dance" at Black Hat Europe 2018 [@eclypsium-publications], the canonical reverse engineering of the Boot Guard IBB-verification flow.

flowchart LR G1["Gen 1: Trust by physical inaccessibility, pre-2011"] G2["Gen 2: Signed BIOS update anchored in BIOS, 2011 to 2013"] G3["Gen 3: Silicon root of trust via Boot Guard and PSP, 2013 onward"] G4["Gen 4: Secure Boot and discrete TPM, 2012 onward"] G5["Gen 5: fTPM on CSME and PSP, 2015 onward"] G6["Gen 6: Microsoft Pluton, 2020 onward"] G7["Gen 7: Open multi-signer root of trust via Caliptra, prospective"] G1 --> G2 --> G3 --> G4 --> G5 --> G6 --> G7

The genealogy is a chain of trades, not a chain of unambiguous improvements. Gen 2 added a revocation surface and unanchored it. Gen 3 anchored the chain in silicon and removed the revocation surface. Gen 4 (Secure Boot, parallel to Gen 3) restored revocation above the firmware layer via the dbx deny-list but did not extend revocation to the fuse. Every move from one generation to the next migrated the failure surface to a different layer. The chain that ships in 2026 is the live composition of Gens 3 through 7, not a clean replacement.

If the trust anchor is now a silicon fuse, what exactly does the silicon do at boot -- and why does Intel's path differ from AMD's?

3. The Two-Vendor Stack: Intel Boot Guard plus CSME, AMD PSP plus PSB

Here is a fact that surprises most x86 engineers the first time they read it carefully. On a modern AMD desktop, an ARM Cortex-A5 with TrustZone boots before the x86 cores are released from reset. The x86 bootstrap processor (BSP) only comes out of reset after the on-die ARM core has verified the BIOS image in SPI flash and decided the platform is allowed to start [@wiki-amd-psp] [@amd-psb-whitepaper]. The "x86 PC" is, at boot, an ARM system-on-chip pretending to be an x86 PC for the first few hundred milliseconds.

Intel takes the opposite architectural shape. On an Intel system the BSP comes out of reset first, but the very first instructions it executes are an Intel-signed binary called the Authenticated Code Module (ACM) which runs inside the CPU package itself, gated by microcode that verifies the ACM signature against a public-key hash that has been fused into the silicon at manufacturing time [@eclypsium-publications]. The first thing your CPU does is verify a manifest signed by Intel that tells it where the OEM's keys live.

A small, Intel-signed binary that the CPU loads from a known SPI region into the CPU cache as private memory and executes before any unsigned code can run. The ACM is verified against a public key whose hash is fused into the chipset Field Programmable Fuse at silicon manufacturing time. The Boot Guard ACM is the verifier that walks the OEM-signed Key Manifest and Boot Policy Manifest. The TXT SINIT ACM is a separate, later-stage ACM used by Intel TXT for dynamic root-of-trust measurement. An array of one-time-programmable polysilicon fuses inside Intel's PCH (or, on Skylake and later, integrated into the CPU package) that the OEM blows during board manufacturing to record the hash of the OEM's Boot Guard public key, the chosen Boot Guard profile (verified-only, measured-only, or both), and the lock state. Once blown, the FPF cannot be unblown. The FPF is the bottom of the OEM-controlled portion of the Intel trust chain; below it sits the silicon-fused Intel public key that authenticates the ACM itself. An OEM-signed manifest that tells the Boot Guard ACM which SPI regions form the Initial Boot Block, what cryptographic hash to expect over those regions, which Boot Guard profile to enforce, and (on profile 4 or 5) what to do on verification failure. The BPM is signed with the OEM Boot Policy Key, which is itself authenticated against the Key Manifest, which is itself authenticated against the FPF. An ARM Cortex-A5 with TrustZone, integrated as a coprocessor on the AMD CPU die from Family 16h forward, that boots before the x86 cores are released from reset [@wiki-amd-psp]. The PSP runs its own boot ROM (immutable silicon), loads PSP firmware from a known SPI directory, verifies that firmware against the AMD root-key hash, and (on platforms with PSB enforced) verifies the OEM-signed BIOS image before releasing the x86 BSP from reset. The AMD architectural feature that has the PSP measure and verify the BIOS image against an OEM-key fuse before releasing the x86 cores [@amd-psb-whitepaper]. PSB ships in two activation states: PSB-capable (PSP runs but does not enforce verification) and PSB-enforced (the OEM has burned the OEM-key hash into the PSP fuse, and the PSP will halt the platform on verification failure). PSB-enforced on EPYC is widely deployed; on Ryzen it has historically been opt-in per platform.

Intel: Boot Guard, CSME, and the manifest chain

Inside an Intel platform the verifier walk is precise enough to render as a list:

The Boot Guard ACM loads into a protected region of CPU cache and executes inside the CPU package.
It reads the FPF for the OEM key hash and the active profile bits.
It pulls the Key Manifest (KM) from SPI and verifies the KM signature against the FPF-stored hash.
It pulls the Boot Policy Manifest (BPM) and verifies the BPM signature against the KM public key.
It hashes the SPI regions declared by the BPM as the Initial Boot Block (IBB) and compares the hash against the BPM-declared expected value.
On a match, it transfers control to the IBB and the chain proceeds.
On a mismatch, it halts (profile 4 and profile 5) or extends PCR 0 with the measurement and continues (profile 3) [@eclypsium-publications].

The Bulygin BH EU 2018 reverse engineering remains the most readable primary on the actual code path [@eclypsium-publications].

Separately, while the CPU is doing the Boot Guard walk, the CSME runs its own startup sequence on its own core, with its own MINIX 3 runtime [@intel-csme-whitepaper]. Once stable, it exposes three optional services [@intel-csme-whitepaper]:

Intel Active Management Technology (AMT). Out-of-band management; only on systems where the OEM has enabled it in firmware.
Intel Platform Trust Technology (PTT). A TPM 2.0 endpoint implemented in CSME firmware, so the platform does not need a discrete TPM chip.
Intel Identity Protection Technology (IPT). Hardware-rooted one-time-password generation.

Each service depends on CSME being trustworthy. And CSME's own runtime is verified, at boot, by the chain we have just walked.

AMD: PSP boot ROM, PSP firmware, and the OEM-key fuse

The AMD walk is structurally simpler and architecturally cleaner. The PSP boot ROM is silicon -- it cannot be modified after fabrication. It reads the PSP directory from a known SPI offset, validates the directory header, loads the PSP firmware image, and verifies that image against the AMD root-key hash that is part of the PSP boot ROM itself [@amd-psb-whitepaper]. On a PSB-enforced platform, the PSP then loads the OEM PSB key, verifies it against the OEM-key hash fused in the PSP, and uses the OEM PSB key to verify the OEM-signed BIOS image before releasing the x86 BSP from reset.

The "separate core boots first" architectural primitive is a different kind of isolation than Intel's "microcode plus signed ACM." Intel's verifier runs in the CPU package but inside a protected cache region. AMD's verifier runs on a physically separate core with its own memory map. Neither is obviously better. Both shift the trust anchor out of writable storage and into silicon.

The ARM Cortex-A5 implements ARMv7-A and ships TrustZone. TrustZone partitions execution into a Non-Secure World (the Rich Execution Environment, REE) and a Secure World (the Trusted Execution Environment, TEE) with hardware-enforced isolation. The PSP runs its boot ROM and firmware in the Secure World [@wiki-amd-psp].

CSME generation	Core	Runtime	Era
ME 1 -- ME 10	ARC	ThreadX	2006 -- 2014
ME 11 (Skylake)	Intel Quark x86	MINIX 3	2015 -- 2018
CSME (Ice Lake+)	Tremont-class x86	MINIX 3	2019 -- present

Sources: [@wiki-ime] [@wiki-ime-history].

The generational table for the Intel side has been the source of several recurring errors in secondary literature: claims that "every CSME runs MINIX" are wrong (the ARC-based ME 1 through ME 10 ran ThreadX), and claims that "CSME still runs on Quark" are equally wrong (Ice Lake and later moved to a Tremont-class x86 core but kept the MINIX 3 runtime) [@wiki-ime] [@wiki-ime-history].

AMD has not published a complete PSP architectural document. The PSB whitepaper [@amd-psb-whitepaper] covers the PSB-flow at a marketing-architecture level; the PRO security whitepaper [@amd-pro-whitepaper] is the broadest vendor primary. Everything else about the PSP -- the runtime, the directory layout, the soft-fuses, the glitch surface -- flows through community reverse engineering. The most useful primaries are Buhren and Werling's voltage-glitching corpus at TU Berlin (now indexed via the Fraunhofer publication record) [@fraunhofer-amd], the Buhren / Jacob / Krachenfels / Seifert "One Glitch to Rule Them All" CCS 2021 paper [@one-glitch-2021], the Jacob / Werling / Buhren / Seifert "faulTPM" USENIX Security 2024 paper (arXiv v1 submitted April 28, 2023) [@faultpm-2023], the open PSPReverse toolchain on GitHub [@pspreverse-org] [@psp-glitch-repo], and Matthew Garrett's 2022 reverse engineering of the PSP directory entry 0xB BIT36 "soft fuse" that gates Pluton on Ryzen 6000 [@garrett-pluton-2022]. The "AMD has not published" caveat travels with every architectural claim about the PSP in this article.

The hedge matters for one specific premise: the ARM Cortex-A5 + TrustZone architectural claim is well-attested for Family 15h and Family 17h via the Buhren / Werling / Jacob / Seifert reverse-engineering corpus [@one-glitch-2021] [@faultpm-2023] [@wiki-amd-psp]. The specific core in Family 19h+ is not publicly documented. The widely-repeated "Cortex-A7" claim is unsupported by any vendor primary I could verify. This article uses "Cortex-A5 with TrustZone" only where Family 15h / 17h is in scope and says "the PSP" generically elsewhere.

Now that we know who the verifiers are, let us watch them work -- one rung at a time -- from CPU reset to winload.efi.

4. The Chain Walk: From CPU Reset to winload.efi

Eleven rungs. We will walk each one in order. By the end you will know exactly what gets verified, by what, against what trust anchor, and what happens when that verification fails.

flowchart TD R["CPU reset, vector at 0xFFFFFFF0"] subgraph IB["Intel Boot Guard"] I1["Microcode loads ACM from SPI"] I2["ACM verified vs silicon-fused Intel key"] I3["ACM reads FPF: OEM key hash plus profile bits"] I4["KM signature verified vs FPF hash"] I5["BPM signature verified vs KM public key"] I6["IBB regions hashed and compared to BPM"] I7["Profile 4 or 5 halts on mismatch, Profile 3 extends PCR 0"] I1 --> I2 --> I3 --> I4 --> I5 --> I6 --> I7 end subgraph AP["AMD PSP plus PSB"] A1["PSP boot ROM (silicon, immutable) executes"] A2["PSP firmware loaded from SPI PSP directory"] A3["PSP firmware verified vs AMD root key hash"] A4["OEM PSB key loaded from SPI"] A5["OEM PSB key verified vs OEM-key fuse"] A6["BIOS image verified vs OEM PSB key"] A7["x86 BSP released from reset"] A1 --> A2 --> A3 --> A4 --> A5 --> A6 --> A7 end R --> I1 R --> A1 I7 --> H["Hand-off to IBB and SEC phase"] A7 --> H

4.1 Reset and microcode bootstrap

The x86 CPU starts executing at physical address 0xFFFFFFF0 per the Intel SDM Volume 3A §9.1.4 ("First Instruction Executed") specification [@intel-sdm-vol3a], which the chipset aliases into the SPI flash region containing the reset vector.That address is sixteen bytes below the top of 32-bit physical memory; the first instruction is typically a near jump down into the bulk of the firmware. The very first action is a microcode load: the CPU executes its built-in microcode, which then loads any microcode patches from a known SPI region. On Intel platforms the microcode patch is itself signed against an Intel public key burned into silicon. On AMD platforms the equivalent step is the PSP boot ROM execution, which happens slightly earlier in wall-clock time because the PSP starts before the x86 BSP is released [@wiki-amd-psp].

4.2 Intel ACM execution and AMD PSP first-stage boot

The Intel ACM is signed by Intel and stored in SPI. The microcode loader verifies the ACM signature against the silicon-fused Intel public key and runs the ACM inside a protected region of cache. The AMD analogue is the PSP boot ROM, which is silicon and therefore cannot be modified after fabrication. Both architectures share the invariant: the first executable code path is anchored in silicon, not flash.

4.3 FPF and OEM-fuse policy read

On Intel, the ACM reads the FPF to learn the hash of the OEM Boot Guard public key and the active Boot Guard profile. It then verifies the Key Manifest (KM) signature against the FPF hash, and the Boot Policy Manifest (BPM) signature against the KM public key. The KM and BPM together form a two-level OEM signing structure: the KM authenticates a set of permitted Boot Policy signing keys, and the BPM names the IBB regions and their expected hash.

On AMD, the PSP reads the PSP directory from a known SPI offset, authenticates the directory entries against the AMD root key, and (on PSB-enforced platforms) authenticates the OEM PSB public key against the PSP-fused OEM-key hash before validating the BIOS image [@amd-psb-whitepaper].

4.4 IBB verification and SEC phase

The first chunk of UEFI firmware that the lower-rung silicon verifier cryptographically covers. On Intel platforms with Boot Guard, the IBB regions are declared by the BPM and hashed by the ACM. On AMD platforms with PSB, the equivalent role is played by the PSP-verified BIOS image as a whole. The IBB is where UEFI's own code path begins.

After IBB verification succeeds, control transfers to the IBB itself. The IBB executes the SEC (Security) phase of the EDK II firmware lifecycle: it sets up the cache as RAM, enables initial CPU features, and prepares to hand off to PEI.

Intel's umbrella term, introduced with Skylake (ME 11) in 2015, for the on-die security processor that runs alongside the x86 cores and provides services to the platform: firmware TPM (PTT), AMT, identity protection, secure storage, and the runtime verifier for some pre-OS measurements [@intel-csme-whitepaper] [@wiki-ime]. CSME runs its own RTOS on its own core and is the single most complex piece of pre-OS firmware on a modern Intel platform.

4.5 PEI and DXE phases

The PEI (Pre-EFI Initialization) phase completes memory controller initialisation and discovers the platform's DRAM. The DXE (Driver eXecution Environment) phase then loads UEFI drivers (storage, USB, network, video, and platform-specific drivers) and brings the UEFI services online. The TianoCore EDK II reference UEFI implementation [@edk2-repo] is the canonical open-source codebase for studying PEI and DXE in detail, and every commercial vendor BIOS is structurally a fork of EDK II with proprietary platform code.

"SPI flash" on a modern platform is not one trust domain. The main BIOS SPI region is what Boot Guard / PSB verify. But a modern PC may also have separate SPI or NVRAM regions for the Embedded Controller (keyboard, battery, lid sensor), the Thunderbolt controller, the fingerprint reader, and on servers the baseboard management controller (BMC). Each of those has its own update mechanism, its own verifier (if any), and its own attack surface. The article will revisit this in section 8.

4.6 DXE Secure Boot variable evaluation

During DXE the UEFI runtime brings the Secure Boot variable services online. The Platform Key (PK), Key Exchange Keys (KEK), Authorized Signature Database (db), and Forbidden Signature Database (dbx) are stored as UEFI authenticated variables in NVRAM, per UEFI Specification §8 [@uefi-specs]. When DXE loads a UEFI binary, the verifier compares the binary's Authenticode signature against db entries, refuses to load binaries whose hash appears in dbx, and (in the default policy) refuses to load binaries that do not match any db entry.

The companion article on Secure Boot covers the PK / KEK / db / dbx model and the SBAT generation-number deny-list in detail. The point for this chain walk is that Secure Boot itself does not start until DXE has set up the UEFI variable services, and DXE itself only runs because the IBB verified by Boot Guard / PSB executed correctly.

Note: This is rung 5 of 11. The rungs above this one -- Secure Boot policy, TPM PCR semantics, Pluton silicon enumeration, ACPI table integrity, Secured-core PC configuration -- are covered in the companion articles. The lane of this article is the rungs below Secure Boot. From here forward we summarise the upper rungs only enough to show where the trust chain hands off.

4.7 Boot Device Selection and bootmgfw.efi

After DXE completes, the BDS (Boot Device Selection) phase enumerates the boot variables stored in NVRAM, finds the first valid EFI_LOAD_OPTION, and loads the EFI binary it points to. On Windows that is \EFI\Microsoft\Boot\bootmgfw.efi. On Linux estates running shim it is \EFI\<distro>\shimx64.efi, which is the first non-Microsoft binary the chain consents to load and which then verifies a distro-signed second-stage loader (GRUB2 in most cases) [@garrett-shim-19448].

4.8 Boot Manager verifies winload.efi; Measured Boot extends PCR 0 through 7

The Windows Boot Manager (bootmgfw.efi) verifies winload.efi against its built-in trust anchor, then asks the TPM to extend a sequence of PCR measurements covering the chain it has just walked. Per the TCG PC Client Platform Firmware Profile, PCRs 0 through 7 cover (0) the platform SRTM and firmware, (1) host platform configuration, (2) UEFI drivers and option ROMs, (3) UEFI driver and application configuration, (4) the boot manager code and boot attempts, (5) boot manager configuration and the GPT, (6) host-platform-manufacturer-specific events, and (7) the Secure Boot policy [@tcg-tpm-lib]. The companion article on Measured Boot covers the PCR semantics in detail.

4.9 Hand-off to winload.efi

winload.efi loads the NT kernel, the early-launch antimalware drivers, and the Code Integrity policy. The Windows OS-side trust chain takes over from here. This article ends its lane at the hand-off.

{// Toy SHA-256 substitute (NOT cryptographically real -- demonstrates the extend chain only). function hashHex(s) { let h = 2166136261; for (const c of s) h = ((h ^ c.charCodeAt(0)) * 16777619) >>> 0; return h.toString(16).padStart(8, '0').repeat(8); } function extend(pcr, measurement) { return hashHex(pcr + measurement); } const pcr0 = '00'.repeat(32); const afterAcm = extend(pcr0, 'ACM-binary@SPI:0x10000'); const afterIbb = extend(afterAcm, 'IBB-region@SPI:0x100000'); const afterDxe = extend(afterIbb, 'DXE-driver-set-vendor-A'); const afterSb = extend(afterDxe, 'SecureBoot-policy:PK=hashA,KEK=hashB,db=hashC,dbx=hashD'); const afterBm = extend(afterSb, 'bootmgfw.efi:authenticode=hashE'); const afterLoad = extend(afterBm, 'winload.efi:authenticode=hashF'); console.log('PCR0 after ACM ->', afterAcm.slice(0, 32) + '...'); console.log('PCR0 after IBB ->', afterIbb.slice(0, 32) + '...'); console.log('PCR0 after DXE ->', afterDxe.slice(0, 32) + '...'); console.log('PCR7 after PolicyB->', afterSb.slice(0, 32) + '...'); console.log('PCR4 after BootMgr->', afterBm.slice(0, 32) + '...'); console.log('PCR4 after WinLoad->', afterLoad.slice(0, 32) + '...'); console.log(); console.log('Change ANY measurement and the chain hash diverges from quote-expected value.');}

Eleven rungs. Each rung's verifier inherits the trust of the rung below it. That single property -- inheritance -- is what makes the next section's argument inevitable.

5. The Breakthrough: The Hardware Fuse as Root of Trust, and the Asymmetric Revocation Surface

The strongest layer in the chain is the layer you cannot fix. That is not a bug. It is the definition of a hardware root of trust -- and it is also why the MSI 2023 leak is permanent.

The architectural insight is structural. Trust must be anchored somewhere, and the only place that survives an OS reinstall, a BIOS reflash, an SPI chip swap, and a malicious bootloader is a piece of silicon that the attacker cannot rewrite without replacing the chip. One-time-programmable polysilicon fuses give exactly that property. Burn the OEM key hash into the FPF at manufacturing time, and from that point forward only OEM-signed firmware will run on that board. The fuse is "the bottom" by construction.

The cost is symmetric. One-time programmable means one-way trust. Once an OEM's public key hash is burned, it cannot be removed without replacing the chip. If the OEM later loses control of the corresponding private key, the public-key hash that authenticates everything signed by that private key is still in the fuse. The fuse layer has no revocation primitive.

Key idea: Trust strength and revocation expressiveness move in opposite directions as you descend the pre-boot trust chain. The fuse layer is the strongest because nothing can change it -- which is exactly why nothing can revoke it. Permanence is the source of both properties, not a side effect of one.

This is the article's load-bearing observation, and it is worth making concrete. Going up the chain from the fuse, the revocation surface gets progressively more expressive.

A monotonically increasing version number embedded in a signed firmware artifact (boot manager, ACM, microcode patch). When the platform's stored SVN floor is bumped, the platform refuses to load any artifact whose embedded SVN is below the floor. SVN bumps are an alternative to per-hash revocation that scales better as the number of bad artifacts grows, but they require the firmware vendor to maintain an SVN namespace and to bump it on every revocation event. A generation-number revocation model introduced by the rhboot shim project to replace per-hash dbx revocation for shim and downstream components [@sbat-md]. Each shim, GRUB2 build, and second-stage component embeds a vendor-specific SBAT generation. When a vulnerability is found, the vendor publishes a new shim with an incremented generation. The shim verifier on the running platform refuses to load any component with a generation lower than the platform's stored floor. As the SBAT documentation notes, "This single revocation event consumes 10kB of the 32kB, or roughly one third, of revocation storage typically available on UEFI platforms" [@sbat-md], which is exactly the dbx exhaustion problem SBAT is designed to solve.

At the top of the chain, on a Pluton-equipped platform, Microsoft can ship Pluton firmware updates through Windows Update [@pluton-learn]. That is the most expressive revocation surface on the chain: software cadence, OS-mediated delivery, no OEM gating on the runtime channel after initial enrolment. (The SPI-resident Pluton firmware loaded at every boot is still updated through the OEM's UEFI capsule pipeline; the OS-mediated runtime channel sits on top of it [@pluton-learn].)

Below Pluton, SBAT denies entire classes of vulnerable shim binaries with one generation bump [@sbat-md]. Below SBAT, dbx denies individual bootloader hashes (with the ~32 KB capacity constraint that SBAT exists to relieve). Below dbx, KEK and PK are progressively more permanent because they sit at the root of UEFI's variable-authentication structure, and any change requires a Platform Key signature. Below the UEFI variables, the OEM Boot Policy Manifest is replaced only by an OEM-signed firmware update. And below the BPM, the FPF / OEM-key fuse is unrecoverable.

flowchart TD L0["Pluton firmware via Windows Update: software cadence"] L1["SBAT generation bump: revoke an entire class with one entry"] L2["dbx hash list: revoke per-binary, capped at roughly 32 KB"] L3["KEK and PK: revoke only via Platform Key signature"] L4["OEM Boot Policy Manifest: replaced by OEM-signed firmware update"] L5["FPF / OEM-key fuse: NO REVOCATION PRIMITIVE"] L0 --> L1 --> L2 --> L3 --> L4 --> L5

MSI 2023 as the worked example

The April 2023 MSI leak is the existence proof. The FPF on every affected Intel platform stores the SHA-256 hash of the OEM Boot Guard public key. The corresponding private key is now public. There is no operational path to revoke that hash at the fuse layer without physical chip replacement. The only "revocation" surfaces available to a platform owner are upper-layer compensations, and each one has a structural limit:

An OS-level driver block list does not apply at boot, because the OS does not exist yet.
A dbx update can deny specific malicious firmware images by hash, but the attacker can sign a new image with the leaked key and rotate around the deny-list, exactly the way per-hash deny-lists always fail against an attacker who controls the signing oracle.
An Intel BIOS Guard SVN bump can raise the SVN floor, but the OEM has to sign the updated firmware -- using the same Boot Guard signing infrastructure that has been compromised. The leaked key signs the SVN bump too.

Help Net Security's contemporaneous reporting captured the counts that make the impact concrete: "private code signing keys for firmware images used on 57 MSI products, and private signing keys for Intel Boot Guard used on 116 MSI products ... one of the leaked keys has been detected on devices from HP, Lenovo, AOPEN, CompuLab, and Star Labs" [@helpnet-msi-leak]. The Register confirmed the affected platform generations as Tiger Lake, Alder Lake, and Raptor Lake [@register-msi-alt]. Binarly's per-device catalogue lists the affected SKUs in detail [@binarly-supply-chain].

Every Intel chip with the leaked OEM key hash burned in is permanently downgraded to a weaker trust model -- and nothing in the layers above can recover what the fuse layer lost.

SBAT exists for exactly the kind of revocation expressiveness the fuse layer lacks [@sbat-md]. SBAT is the negative-space comparator: this is what fuse-layer revocation could look like if it existed. It does not exist. That is the breakthrough -- and the limit -- of Gen 3 silicon roots of trust on commodity client platforms in 2026.

If the fuse is unrecoverable, what does the rest of the modern stack do to compensate?

6. State of the Art: What a Modern Pre-Boot Trust Chain Looks Like in 2026

In 2026 the chain has settled into a recognisable shape on Secured-core PCs and EPYC servers. Here is what is shipping, and what each piece is for.

The current best-practice configuration is roughly: Boot Guard or PSB enforced at the silicon verifier rung; BIOS Guard for runtime SPI write protection; SMM locked down via Intel TXT or AMD SKINIT; Measured Boot extending PCRs into a TPM 2.0 endpoint (discrete TPM, Intel PTT, AMD fTPM, or Microsoft Pluton); Windows DRTM enabled (extending PCR 17 through PCR 22); and the KB5025885 boot-manager revocation programme applied as it rolls out across 2025 and 2026 [@kb5025885].

KB5025885: db plus dbx plus SVN, not "PK rotation"

A late-launch primitive (Intel TXT via the SINIT ACM, or AMD SKINIT via the SLB) that re-anchors the trust chain after the static root has done its work. DRTM allows the OS to enter a measured launch environment in which a small, trusted hypervisor or secure kernel is loaded and measured into PCRs 17 through 22, independent of the firmware boot chain. Windows DRTM uses TXT or SKINIT to bring the Secure Kernel and Hypervisor Code Integrity online with a fresh chain of measurements.

Note: Press coverage frequently described KB5025885 as a "PK rotation" or "Microsoft rotating the Platform Key." It is neither. The Microsoft support article spells out the actual mechanism: KB5025885 adds the Windows UEFI CA 2023 certificate (PCA2023) to the Database Key (DB) and adds the hashes of vulnerable boot manager binaries to the Forbidden Signature Key (DBX) [@kb5025885]. The Platform Key itself is not modified by KB5025885. The MSRC blog framing is consistent: KB5025885 is a staged-rollout programme for managing the revocation of vulnerable Windows boot manager binaries associated with CVE-2023-24932 [@msrc-blog-2023-24932] [@msrc-cve-2023-24932].

KB5025885 was originally published on May 9, 2023 as part of May 2023 Patch Tuesday, in response to CVE-2023-24932 (a Secure Boot Security Feature Bypass) [@cve-2023-24932-nvd] [@kb5025885]. The CVE was the underlying vulnerability that the BlackLotus bootkit had exploited via CVE-2022-21894 several months earlier [@eset-blacklotus] [@cve-2022-21894-nvd]. Microsoft's response was structurally cautious: a multi-year staged rollout, rather than an immediate forced revocation, because forcing a dbx update that would brick any unpatched Windows install or any third-party EFI loader still in distribution would have been operationally catastrophic.

gantt dateFormat YYYY-MM-DD title KB5025885 boot manager revocation programme section Disclosure CVE-2023-24932 published :2023-05-09, 7d KB5025885 initial publication :2023-05-09, 7d section Deployment Manual deployment phase :2023-07-11, 270d Evaluation phase :2024-04-09, 90d Automatic enrollment phase :2024-07-09, 540d section Cutover Automatic certificate replacement :2026-01-01, 150d PCA2011 expiration window :2026-06-01, 30d

The rollout dates above follow the Microsoft KB5025885 article timeline [@kb5025885]: manual deployment beginning July 11, 2023; evaluation phase beginning April 9, 2024; automatic enrolment of mitigations beginning July 9, 2024; automatic certificate replacement on Windows 11 beginning January 2026; and the PCA2011 / UEFI CA 2011 / KEK CA 2011 expiration window in June 2026. The mechanism throughout is db + dbx + SVN, not Platform Key rotation.

Pluton's structural role in the modern chain

Microsoft Pluton was announced on November 17, 2020 as a "chip-to-cloud" security processor co-designed with AMD, Intel, and Qualcomm Technologies [@pluton-blog]. The current Microsoft Learn enumeration of Pluton silicon as of 2024 reads: "AMD: Ryzen 6000, 7000, 8000, 9000 and Ryzen AI Series processors; Intel: Core Ultra 200V Series, Ultra Series 3 and Series 3 processors; Qualcomm: Snapdragon 8cx Gen 3 and Snapdragon X Series processors. ... Pluton platforms in 2024 AMD and Intel systems will start to use a Rust-based firmware foundation" [@pluton-learn].

Pluton's structural contribution to the chain is the firmware-update channel. Discrete TPMs cannot be patched after manufacturing in any meaningful way. CSME PTT firmware ships through OEM BIOS updates with all the latency that implies. Pluton firmware reaches devices through two channels: the traditional OEM UEFI capsule that updates the SPI-resident Pluton image at boot, and an OS-mediated runtime channel through which Microsoft can ship new firmware via Windows Update [@pluton-learn] [@garrett-pluton-2022-update]. The second channel is the one no other shipping silicon root-of-trust has, and the one that closes the patch-latency gap.

Silicon comparison

Property	Intel Boot Guard	AMD PSB	Apple Silicon Boot ROM	Google Titan-M2	Microsoft Pluton
Trust anchor	FPF in PCH or package	OEM-key fuse in PSP / FCH	Mask ROM on the AP	On-die in Titan-M2 chip	On-die in SoC fabric
Revocation surface	None at fuse layer	None at fuse layer	Vendor seed (Apple)	Vendor seed (Google)	Microsoft via Windows Update
FW update channel	OEM BIOS	OEM BIOS	macOS updates	Android updates	Windows Update [@pluton-learn]
OS attestation API	TPM 2.0 quote (PTT)	TPM 2.0 quote (fTPM)	DeviceAttestationKey	KeyMint attestation	TPM 2.0 + Pluton-specific
Deployment posture	Widespread, OEM-gated	EPYC widespread, Ryzen opt-in	All Apple Silicon Macs	All Pixel 6 and later	Ryzen 6000+, Core Ultra, X-series

The asymmetry that matters for the article's argument is the third row. Apple, Google, and Microsoft control the firmware update channel for their respective trust anchors. Intel and AMD do not -- the OEM does, and the OEM's release cadence varies by vendor, by product line, and (for end-of-life models) drops to zero.

Bootkit comparison: same invariant, different break

Bootkit / vuln class	CVE	Vulnerable layer	Primitive	dbx state at disclosure	Fix mechanism
BlackLotus	CVE-2022-21894	Windows Boot Manager	baton drop on unpatched bootmgfw [@eset-blacklotus]	unpatched bootmgfw hashes not yet in dbx	KB5025885 dbx + db + SVN programme [@kb5025885]
BootHole	CVE-2020-10713 [@cve-2020-10713-nvd]	GRUB2 BootHole buffer overflow	GRUB2 cfg parser overflow [@eclypsium-boothole]	initial dbx update exhausted 10 KB of capacity	dbx hash list bump (SBAT later introduced to solve scale) [@sbat-md]
LogoFAIL	multiple in 2023	UEFI DXE image-parsing libraries	malicious BMP / PNG / JPEG in boot logo region	Boot Guard verifier passed; DXE parser exploited	per-OEM firmware update + library fixes [@binarly-logofail]
Bootkitty	(PoC, 2024)	User-controlled trust posture	Self-signed bootkit plus in-memory GRUB integrity-check patches before kernel hand-off [@bootkitty]	dbx unchanged for Bootkitty PoC	Keep Secure Boot enabled; audit MOK enrolments; SBAT is not the corrective surface for this class [@bootkitty]

The common pattern is the same invariant -- "the chain is only as strong as the rung that was broken" -- with four different break points:

BlackLotus broke at rung 9 (Boot Manager); the fix lived at rung 7 (Secure Boot policy via dbx).
BootHole broke at rung 10 (the chain-loaded GRUB2); the fix lived at rung 7 again (dbx, until SBAT replaced the per-hash approach).
LogoFAIL broke at rung 6 (a DXE image-parsing library); the fix had to live at rung 6 as well, because the verifier at rung 7 had already approved the binary.
Bootkitty did not break at shim or GRUB2; it operated alongside them, under the assumption Secure Boot was either disabled or the attacker's certificate had been pre-enrolled into MOK. ESET's primary disclosure confirms it is self-signed and patches GRUB integrity-check functions in memory after being loaded [@bootkitty].

The LogoFAIL story is especially instructive. Binarly's December 6, 2023 disclosure showed that Boot Guard validates the firmware image, but the image then parses attacker-controlled logo data through CVE-laden image parsers, executing attacker code in DXE without crossing any signature boundary [@binarly-logofail] [@binarly-logofail-slides] [@hackernews-logofail] [@darkreading-logofail].

Pluton is the most aggressive structural answer to the asymmetric-revocation problem on shipping silicon. But Pluton is not the only structural answer -- and even Pluton inherits one rung of OEM trust. The next section is the competing-approaches map.

7. Competing Approaches: Microsoft Pluton vs the Chipset Fuse Model

Pluton and Boot Guard are not competing for the same rung. They compose. Pluton sits in the SoC fabric on supported silicon and provides a TPM 2.0 service plus a Microsoft-controlled firmware-update channel; Boot Guard and PSB continue to verify the BIOS image at the silicon-verifier rung [@pluton-learn]. The interesting design fight is not Pluton-versus-Boot-Guard, it is Pluton-versus-the-OEM-controlled-fuse for the role of trust anchor of last resort.

Pluton's value proposition

Pluton's pitch, as Microsoft has articulated it since the November 2020 announcement, is to cycle the trust anchor from the OEM's fuse to a Microsoft-controlled root of trust that also lives in silicon but whose firmware can ship through Windows Update [@pluton-blog].

The trade is explicit: trust goes from "OEM, with no Microsoft visibility into key-management hygiene" to "Microsoft, with the platform integrated into Microsoft's signing infrastructure and update cadence."

The shift cuts two ways:

For organisations whose threat model treats OEM-key-management hygiene as the weakest link (and the MSI 2023 leak makes a strong empirical case for that view), Pluton is a structural improvement.
For organisations whose threat model treats Microsoft as a higher-risk root than the OEM, Pluton makes things worse on net.

The Pluton-present-is-not-Pluton-enabled trap

On April 11, 2022, Matthew Garrett published a reverse engineering of the ROG Zephyrus G14, an AMD Ryzen 6000 laptop, showing that "PSP directory entry 0xB BIT36 have the highest priority... If bit 36 is set, the PSP tells Pluton to turn itself off" [@garrett-pluton-2022].

The procurement consequence is easy to miss. Pluton-equipped silicon ships from AMD with Pluton present in the die, but the OEM can flip a single bit in the PSP firmware directory at manufacturing time that gates Pluton entirely. The platform passes "Pluton-equipped" advertising checks while Pluton is functionally disabled.

Garrett's December 2022 follow-up documented that Lenovo's ThinkPad Z13 shipped with Pluton default-disabled and exposed two ACPI device IDs (MSFT0101 and MSFT0200) that platform tooling could use to detect the configuration [@garrett-pluton-2022-update]. The operational lesson: "Has Pluton" is not the same question as "Pluton is enabled and acting as the TPM 2.0 endpoint."

Note: On Windows, Get-Tpm | Select-Object ManufacturerIdTxt, ManufacturerVersion returns the TPM 2.0 endpoint vendor and version. A Pluton-active platform reports MSFT as the manufacturer; a CSME PTT platform reports INTC; an AMD fTPM platform reports AMD; a discrete TPM reports the dTPM vendor (Infineon, Nuvoton, STMicroelectronics, etc.). This is the simplest field-confirmable check for which endpoint is actually serving as the TPM.

AMD PSB on EPYC versus Ryzen

AMD Platform Secure Boot has a deployment split that maps onto the consumer-versus-datacenter market structure. On EPYC, PSB-enforced is widely deployed: the datacenter customer wants the silicon-rooted verifier and is willing to accept the cost.

The cost on EPYC is sharp. Once an OEM has burned its key hash into the PSP fuse on a given CPU, that CPU is irreversibly locked to that OEM. The chip cannot be resold into another OEM's platform that uses a different OEM key. Secondary-market liquidity for fused EPYC parts is essentially zero. This is not a hypothetical liability. Datacenter operators who refresh hardware on a 3-5 year cycle find that PSB-fused EPYC parts have markedly lower resale value than equivalent non-fused parts. The "right answer" depends on the customer's threat model, but the trade is real.

On Ryzen client parts, PSB has historically been opt-in per platform; many consumer Ryzen systems ship with PSB unfused and Pluton (where present) gated by the soft-fuse [@amd-psb-whitepaper] [@garrett-pluton-2022].

Caliptra: the open multi-signer answer

The most ambitious structural answer to the MSI-leak problem currently in active development is Caliptra, a CHIPS Alliance project announced on December 13, 2022 [@chipsalliance-caliptra]. Caliptra is "the specification, silicon logic, ROM and firmware for implementing a Root of Trust for Measurement (RTM) block inside an SoC" [@caliptra-repo]. The full RTL is open at chipsalliance/caliptra-rtl [@caliptra-rtl] and the firmware at chipsalliance/caliptra-sw [@caliptra-sw], both under Apache 2.0. The founding members include AMD, Google, Microsoft, and NVIDIA.

The structural properties Caliptra targets, which neither Boot Guard, PSB, nor Pluton currently provide on commodity client silicon, are: (1) open RTL so the trust anchor's silicon implementation is auditable gate-by-gate; (2) multi-signer support so a single OEM key compromise does not unilaterally compromise the trust chain; (3) datacenter-class scope first, with the design choices that follow from that target. Caliptra is not yet on shipping client silicon. It is the negative-space answer to the MSI leak: the structural fix that the chipset-fuse model does not have, but that the architecture community has now spent four years designing in the open.

Pluton closes the patch-latency gap. Caliptra closes the single-signer gap. Neither closes the supply-chain-of-silicon gap. That is the next section.

8. Theoretical Limits: Where the Chain Cannot Reach

Every defensive chain has a payload at the bottom -- the thing the chain ultimately protects against. The pre-boot trust chain protects against five attack classes. Here are the five it does not.

Key idea: The chain closes three threat classes well (OS-level rootkit persistence; signed-but-revoked bootloader chain-loading; remote firmware reflash without physical access) and structurally cannot close two others (physical-SPI-access before the platform is fused and locked; leaked OEM key on already-shipped silicon). Naming both sets is the precondition for any honest threat-model claim.

Limit 1 -- Physical SPI access bypasses everything above it

Even with Boot Guard or PSB enforced, an attacker who can write to SPI flash before the platform is fused and locked can overwrite the IBB and the BPM and own the next boot. Access vectors: manufacturing, repair, or certain integrated circuits that expose SPI on a debug header.

CHIPSEC [@chipsec-repo] [@chipsec-page] -- originated by Bulygin and colleagues at CanSecWest 2014 [@c7zero-chipsec] -- is the canonical pre-deployment audit framework for verifying the chipset write-protect bits on shipping platforms. Trammell Hudson's Thunderstrike, presented at 31C3 in December 2014 [@thunderstrike] [@ccc-31c3], is the canonical real-world demonstration: SPI substitution via a Thunderbolt Option ROM on Apple Mac EFI. It is the existence proof that "physical access plus the right bus" can bypass the silicon-rooted verifier when the platform's write-protections are not fully engaged.

Limit 2 -- A leaked OEM key cannot be revoked at the fuse layer

The MSI 2023 incident, recompressed: the FPF stores the hash of the OEM Boot Guard public key, not a revocation list against that hash. There is no fuse-layer primitive for marking the hash as "revoked." Once the corresponding private key leaks, every chip carrying that hash is permanently downgraded to a model in which the attacker can sign new Boot Guard firmware that the platform will accept [@binarly-msi] [@helpnet-msi-leak] [@register-msi-alt].

The structural fix is per-batch key derivation or multi-signer trust anchors; on commodity client silicon in 2026 this fix exists only as a design specification (Caliptra) and not as a shipped product [@caliptra-repo] [@chipsalliance-caliptra]. Eclypsium's "Vulnerable Boot Guard implementations" series [@eclypsium-blog] documents that the MSI leak is the third or fourth such incident across the Boot Guard vendor space. Lenovo, HP, Compal, and Quanta have all experienced similar leaks; MSI is simply the most extensively catalogued.

Limit 3 -- The trust chain cannot defend against malicious silicon

If the verifier chip itself is malicious -- substituted upstream of the customer's supply chain -- the chain's invariants do not hold, because the bottom of the chain is what defines the trust model. Defending against this class is the supply-chain-of-silicon problem and is out of scope for this article. The open-RTL property of Caliptra is partial mitigation in the sense that the customer can at least verify that the silicon matches the specification, but verifying that a fabricated die corresponds to its RTL is an entirely separate research programme.

Limit 4 -- Thunderbolt SPI is a separate SPI region

Bjorn Ruytenberg's Thunderspy disclosure on May 10, 2020 [@thunderspy-report] [@thunderspy-site] targeted firmware vulnerabilities in the Thunderbolt controller chip on PCs with Thunderbolt 1 / 2 / 3 ports. The controller has its own firmware in its own SPI region, distinct from the main BIOS SPI region that Boot Guard / PSB verify.

Thunderspy let an attacker with physical access to the port flash modified Thunderbolt controller firmware, weakening the DMA isolation Thunderbolt 3 was supposed to provide. Thunderspy did not bypass Boot Guard, PSB, or Secure Boot. It bypassed a different verifier in a different SPI region for a different protocol.

The conflation -- "Thunderspy broke Secure Boot" -- appeared in early press coverage and persists in some secondary writing. The primary report is unambiguous that the target was Thunderbolt controller firmware [@thunderspy-report].

The structural lesson generalises beyond Thunderbolt: "SPI" on a modern PC is not a single trust domain. The main BIOS region, the Thunderbolt controller, the Embedded Controller, the fingerprint reader, and (on servers) the BMC each have their own SPI regions, their own update mechanisms, and their own verifier (if any). A vulnerability in one does not necessarily affect the others; but inventorying which regions are independently verified is a non-trivial procurement exercise.

Limit 5 -- The ME and PSP are themselves attack surface

The CSME and PSP exist to verify the platform's trust chain, but they are themselves programs running on processors. They have bugs. The disclosure record is sobering:

INTEL-SA-00086 (November 2017). Remote code execution in CSME via CVE-2017-5705, CVE-2017-5706, CVE-2017-5708, and CVE-2017-5712, pre-disclosed by the Ermolov / Goryachy BH EU 2017 work [@intel-sa-00086] [@ermolov-goryachy-2017].
CVE-2020-8705. A Boot Guard ACM vulnerability in the S3-resume code path that Trammell Hudson wrote up [@cve-2020-8705-nvd] [@trmm-sleep].
One Glitch to Rule Them All (CCS 2021). Buhren, Jacob, Krachenfels, and Seifert demonstrated voltage-glitching attacks against the AMD PSP on Zen 1, Zen 2, and Zen 3 [@one-glitch-2021], with open tooling at PSPReverse/amd-sp-glitch [@psp-glitch-repo].
faulTPM (USENIX Security 2024). The follow-up paper (arXiv v1 April 28, 2023) showed the same primitive could extract sealed TPM blobs from AMD fTPM, enabling BitLocker key recovery on devices using AMD fTPM-as-TPM [@faultpm-2023].

The faulTPM hardware cost is in the low hundreds of US dollars (commodity microcontroller plus voltage-glitching circuit). The capability the cost buys is full extraction of fTPM-sealed blobs. The "expensive nation-state-grade attack" framing does not apply here.

These attacks do not break the concept of a silicon-rooted trust chain. They break specific implementations of it. The conceptual chain is sound; the engineering surface inside each implementation has bugs that, once disclosed, get patched and shifted up the cadence. The pattern is structurally similar to OS kernel CVE disclosures. The existence of bugs does not mean the kernel concept fails; it means kernels need patch cadence. The difference at the firmware layer is that patch cadence at the CSME or PSP runs through the OEM BIOS update pipeline, which is slower than the OS pipeline by a factor of roughly ten.

Five limits. The first three are deep. The last two are open research.

9. Open Problems: What Is Still Being Researched

Five open problems. Three are about the chain. Two are about who gets to see inside it.

OEM key-management hygiene at industry scale. The Eclypsium series on leaked Boot Guard keys covers Compal, Quanta, Lenovo, and MSI across multiple disclosures [@eclypsium-blog]. The structural fix -- per-batch keys, multi-signer trust anchors, hardware-bound signing services -- exists as Caliptra in specification [@caliptra-repo] but not in shipping client silicon. The 2026 research question is not "do we know how to solve this" but "when and on which silicon families does Caliptra (or an equivalent) actually ship to consumer platforms."

Pluton firmware-runtime transparency. Microsoft has committed to a "Rust-based firmware foundation" for Pluton on 2024+ AMD and Intel systems [@pluton-learn] but has not publicly named the specific runtime. Community speculation around Tock OS [@tockos] (an embedded Rust kernel designed for security-critical microcontrollers) remains speculation; the connection has not been confirmed by Microsoft. Microsoft also has not published gate-level documentation of the Pluton silicon. The accountability gap -- "we asked you to trust this runtime; what is it" -- is itself an open problem and is the single most-cited objection to Pluton in the open-firmware community.

The Linux side of the KB5025885 transition. Shim distributions must coordinate with the PCA2011 to PCA2023 cutover or face boot failures on enforced-Secure-Boot multi-OS estates [@garrett-shim-19448] [@garrett-shim-17872] [@sbat-md]. Matthew Garrett's 2012 first-hand description of shim remains the cross-vendor architectural reference, and his 2022 / 2023 follow-ups document the operational hazards. The risk is not theoretical: a distribution that ships a shim signed only by PCA2011 and does not coordinate the migration to PCA2023 will not boot on Windows 11 systems that have completed the KB5025885 cutover.

Vendor-level attestation incompatibility. TCG TPM 2.0 quotes [@tcg-tpm-lib] are widely supported, but vendor-level attestation (Intel SGX DCAP [@sgx-dca], AMD SEV-SNP attestation, Pluton attestation) remain three incompatible schemes with three sets of root certificates, three quote formats, and three verifier libraries. A relying party that wants to attest a Confidential VM running on a mixed-vendor fleet must integrate against all three. The TPM 2.0 quote covers only the rungs visible to the TPM; it does not attest the CSME runtime, the PSP runtime, or the Pluton runtime in a vendor-neutral way.

DRTM deployment and revocation maturity. Windows 11 Secured-core requires DRTM via Intel TXT or AMD SKINIT, but mature revocation for DRTM-measured payloads is nascent. AMD fTPM glitch resistance on Zen 4+ is not yet publicly gate-level documented; the faulTPM team explicitly left Zen 4+ for future work [@faultpm-2023], and the absence of vendor disclosure leaves the question open at the level of public knowledge.

That is the research frontier. What follows is the practitioner's manual.

10. Practical Guide: How to Audit, Configure, and Reason About the Chain

Three audiences. Three checklists. One decision tree.

For the procurement architect: the seven-question silicon checklist

flowchart TD Q1{"Boot Guard enforced (profile 4 or 5) on Intel, or PSB-enforced on AMD?"} Q2{"PSB-fused to the correct OEM (not another OEM's key)?"} Q3{"Pluton present AND not gated by the OEM soft fuse?"} Q4{"DRTM-capable, Intel TXT or AMD SKINIT?"} Q5{"KB5025885 cumulative update applied?"} Q6{"PCA2023 present in db?"} Q7{"dbx SVN current per Microsoft January 2026 baseline?"} OK[Procurement-grade Secured-core posture] BAD[Reject or remediate before deployment] Q1 -- yes --> Q2 Q1 -- no --> BAD Q2 -- yes --> Q3 Q2 -- no --> BAD Q3 -- yes --> Q4 Q3 -- no --> BAD Q4 -- yes --> Q5 Q4 -- no --> BAD Q5 -- yes --> Q6 Q5 -- no --> BAD Q6 -- yes --> Q7 Q6 -- no --> BAD Q7 -- yes --> OK Q7 -- no --> BAD

For the firmware engineer: SBAT versus dbx revocation capacity

The asymmetric-revocation point gets sharper when you run it as code. The shim SBAT documentation makes the capacity claim concrete: "This single revocation event consumes 10kB of the 32kB, or roughly one third, of revocation storage typically available on UEFI platforms" [@sbat-md]. The block below shows what a single SBAT generation bump replaces in dbx storage.

{const DBX_CAPACITY_BYTES = 32 * 1024; const SHA256_HASH_BYTES = 32; const SBAT_ENTRY_BYTES = 40; const dbxCapacityHashes = Math.floor(DBX_CAPACITY_BYTES / SHA256_HASH_BYTES); const sbatCapacityEntries = Math.floor(DBX_CAPACITY_BYTES / SBAT_ENTRY_BYTES); console.log('dbx capacity in SHA-256 hashes :', dbxCapacityHashes); console.log('Equivalent SBAT generation rows :', sbatCapacityEntries); console.log(); const vulnerableShimBuilds = 256; const dbxBytesForShim = vulnerableShimBuilds * SHA256_HASH_BYTES; const dbxFractionUsed = (dbxBytesForShim / DBX_CAPACITY_BYTES * 100).toFixed(1); const sbatBytesForShim = 1 * SBAT_ENTRY_BYTES; const sbatFractionUsed = (sbatBytesForShim / DBX_CAPACITY_BYTES * 100).toFixed(1); console.log('Revoking', vulnerableShimBuilds, 'distinct vulnerable shim builds:'); console.log(' via dbx hashes :', dbxBytesForShim, 'bytes -', dbxFractionUsed + '% of capacity'); console.log(' via SBAT bump :', sbatBytesForShim, 'bytes -', sbatFractionUsed + '% of capacity'); console.log(); console.log('SBAT is roughly 256x more capacity-efficient at revoking entire vulnerability classes.');}

For the detection engineer: CHIPSEC modules per chain rung

Chain rung	CHIPSEC module	What it audits
SPI access policy (rung 1-2)	`common.spi_access`	SPI controller access permissions and region descriptors
SPI descriptor lockdown	`common.spi_desc`	SPI flash descriptor lock bit (FLOCKDN)
BIOS write-protect	`common.bios_wp`	BIOSWE / BLE / SMM_BWP configuration
BIOS timestamp	`common.bios_ts`	BIOS update timestamp consistency
SMM lockdown	`common.smm`	System Management Mode protections including SMM_BWP
SPI controller lockdown	`spi.spi_lock`	Per-region SPI write-protect and SPI controller lock

The full CHIPSEC module catalogue is in the chipsec/modules directory of the project repository [@chipsec-repo] [@chipsec-page]. A typical pre-deployment audit runs chipsec_main with the platform-specific module set and produces a per-module pass / fail report; any FAIL on the modules above maps directly to a known CVE class.

On a CHIPSEC-supported platform (Linux or Windows, with the kernel driver installed), `sudo chipsec_main` runs the full default module set against the current platform and prints a per-module PASS / FAIL summary. To restrict to the SPI / BIOS protection subset above, use `sudo chipsec_main -m common.bios_wp -m common.spi_desc -m common.spi_access -m spi.spi_lock -m common.smm -m common.bios_ts`. Read the CHIPSEC manual at [@chipsec-page] before running on production hardware; some modules touch SMI handlers and can wedge a misconfigured platform.

For the threat-model architect: three closed, three open

The chain closes three threat classes:

OS-level rootkit persistence below the kernel (Mebromi-class attacks against unprotected SPI).
Signed-but-revoked bootloader chain-loading (BlackLotus-class attacks against bootmgfw + Secure Boot).
Remote firmware reflash without physical access (driver-class attacks against poorly-locked SPI controllers).

The chain does not close three other classes:

Physical-SPI-access before the platform is fused and locked (Thunderstrike-class attacks via debug headers or controller ports).
Leaked OEM key on already-shipped silicon (MSI 2023-class capability transfers).
Supply-chain compromise of the silicon itself (the most-cited but operationally rarest class).

Practitioner alternative stacks

Note: If the OEM trust chain does not meet your threat model, the open-firmware community has an alternative for many platforms. - coreboot [@coreboot-org] [@wiki-coreboot] (originated as LinuxBIOS at Los Alamos National Laboratory in 1999) is the most widely deployed open firmware, shipping by default on every Chromebook. - Heads [@heads-repo] (Trammell Hudson's payload) runs on top of coreboot to provide TPM-measured boot with second-factor attestation (typically a YubiKey). It is the high-assurance Linux deployment baseline of choice for several investigative-journalism shops. - EDK II [@edk2-repo] is the reference open-source UEFI implementation if you need UEFI semantics rather than coreboot semantics. None of these magically restore revocation at the fuse layer, but they remove the OEM signing infrastructure as a single point of failure for everything above the fuse.

You now have the chain, the limits, and the controls. The FAQ kills the recurring misconceptions.

11. Frequently Asked Questions

Secure Boot in the abstract protects against unsigned-bootloader execution; it does not by itself protect against signed-but-vulnerable bootloader execution. BlackLotus exploited CVE-2022-21894 against a Microsoft-signed boot manager [@cve-2022-21894-nvd] [@eset-blacklotus]. The vulnerable binary was still signed -- and "patched" is not the same as "revoked." Until Microsoft adds the vulnerable binary's hash to dbx (which is what KB5025885 does, on a multi-year staged rollout to avoid bricking unpatched systems [@kb5025885]), Secure Boot will continue to load and execute the vulnerable binary. No -- see §6 Callout. KB5025885 modifies DB (PCA2023 added) and DBX (vulnerable bootmgfw hashes added); the Platform Key is untouched [@kb5025885]. This is a threat-model question, not a factual one. The Intel ME (now CSME on Skylake and later) runs MINIX 3 [@wiki-ime] [@tanenbaum-letter] and provides a set of services that the OEM may or may not have enabled: Active Management Technology, PTT firmware TPM, and Identity Protection Technology, among others [@intel-csme-whitepaper]. Whether you call that "a backdoor" depends on whether you consider remote attestation, hardware-rooted identity, and out-of-band management to be services or threats. The factual content is that the CSME runs, has its own runtime, has had CVEs (INTEL-SA-00086 [@intel-sa-00086] [@ermolov-goryachy-2017]), and ships on essentially every consumer Intel platform since Skylake. No. The name appears to be a confabulation that does not correspond to any verifiable primary research. The real SPI-write research bases for the pre-boot chain are Thunderstrike (Trammell Hudson, 31C3, December 2014 [@thunderstrike] [@ccc-31c3]), CHIPSEC (Bulygin et al., CanSecWest 2014 [@c7zero-chipsec]), and LogoFAIL post-exploitation (Binarly, December 2023 [@binarly-logofail]). If you see "Hudson Hammer" cited, treat it as a hallucinated reference. No -- Thunderspy targets a separate SPI region for the Thunderbolt controller. See §8 Limit 4 for the full mechanism [@thunderspy-report]. Cortex-A5 with TrustZone is the well-attested answer for Family 15h and Family 17h (see §3 hedge for the reverse-engineering corpus). Cortex-A7 is unsupported by any vendor primary or community reverse engineering. Family 19h and later is not publicly documented. No -- pre-Skylake ME (1 through 10) ran ThreadX on ARC; ME 11 (Skylake) introduced MINIX 3 on Intel Quark; Ice Lake and later CSME moved to Tremont-class x86 but kept MINIX 3. See the §3 generational table [@wiki-ime]. Because capability transfer is permanent regardless of when it gets operationalised. The leaked keys correspond to public-key hashes that have already been burned into the FPF on every affected chip [@binarly-msi] [@helpnet-msi-leak]. There is no fuse-layer revocation primitive [@register-msi-alt]. The chips are permanently downgraded to a model in which an attacker who has the leaked keys can sign new Boot Guard firmware that the platform will accept. The waiting time between disclosure and operationalisation is the only variable; the structural condition is not recoverable.

Closing thought

You came in believing Secure Boot was the trust anchor. You leave knowing it is the fifth rung. The four rungs below it -- microcode, ACM or PSP boot ROM, FPF or OEM-key fuse policy read, IBB verification -- are the ones that actually anchor the chain. The most permanent of those is the bottom rung, and the most permanent rung is also the one with no revocation surface. Read those two sentences together and you have the whole article in a paragraph. Read them with the MSI 2023 leak in mind and you have the reason this article needed to exist.

Secure Boot in Windows: The Chain From Sector Zero to Userinit, and Every Place It Has Broken

noreply@paragmali.com (Parag Mali) — Sat, 09 May 2026 00:00:00 GMT

Windows boots through a chain of verifications and measurements that runs from CPU reset to your desktop. UEFI Secure Boot signs the boot manager; Trusted Boot extends the signature check to every kernel-mode component; Measured Boot extends a parallel hash of every step into the TPM's PCR 0-7 and PCR 11, with DRTM later seeding PCR 17-22 from a CPU-vendor-signed late-launch anchor. After fifteen years of BIOS rootkits, MBR bootkits, and ESP-resident bootkits, that chain holds -- but every public Secure Boot break since 2022 (BlackLotus, Bitpixie, Bootkitty, LogoFAIL) has exploited the same gap: between patching a vulnerable Microsoft-signed binary and revoking it in dbx. Pluton-rooted firmware on Microsoft's update cadence is the planned escape.

1. Eight seconds in 2010, and everything that could already be wrong

Picture a small business owner in December 2010. She unplugs her three-year-old Dell, drives it home, and powers it on. The fan spins. The BIOS chimes. The Windows 7 logo appears. By the time she types her password and the desktop loads, eight seconds have passed.

In those eight seconds, a TDL-4 bootkit that has been on disk for two weeks has already done its work. The infected master boot record patched the operating system loader in memory before the kernel finished initialising. Driver Signature Enforcement, the policy that was supposed to keep unsigned kernel drivers out, was disabled before the kernel checked for it. A ring-0 rootkit is now staged inside ntoskrnl.exe. Kaspersky's June 2011 analysis counted 4,524,488 infected machines in the first three months of 2011 alone [@kaspersky-tdl4]. The owner notices nothing. By the time she authenticates, the operating system that authenticates her is loading code the operating system never agreed to load.

The structural question raised by that scene is the question this article exists to answer: what would it take for Windows to know, by the time the user types a password, that the machine has not been tampered with since power-on?

The answer Microsoft began designing in 2011-2012 is a chain. UEFI Platform Initialization brings up the firmware. UEFI Secure Boot verifies the boot manager. Trusted Boot extends the signature check through winload.efi, the kernel, and every boot-start driver. Early Launch Anti-Malware classifies subsequent drivers. The Secure Kernel comes up in a hardware-isolated execution mode. Through every one of those rungs, a parallel rail -- Measured Boot -- writes a tamper-evident hash log into the TPM's Platform Configuration Registers, so that what was loaded can be proven later, even if the verifier itself was bypassed.

That chain is the spine of this article. We will walk it rung by rung. We will see where it has been broken in the wild. And we will see why every successful break since 2022 has exploited the same operational invariant -- the gap between patched and revoked -- rather than any flaw in the cryptography.

flowchart TD SEC["SEC -- CPU reset, immutable ROM"] --> PEI["PEI -- platform init"] PEI --> DXE["DXE -- Secure Boot verifier lives here"] DXE --> BDS["BDS -- pick boot variable"] BDS --> BMGR["bootmgfw.efi (Microsoft-signed)"] BMGR --> WLOAD["winload.efi (Microsoft-signed)"] WLOAD --> NT["ntoskrnl.exe + boot-start drivers"] NT --> ELAM["ELAM (Defender, signed AM)"] NT --> SK["securekernel.exe (VTL1) + Trustlets"] ELAM --> SMSS["smss.exe -> wininit -> winlogon"] SK --> SMSS SMSS --> USR["userinit.exe -> explorer.exe"] TPM[("TPM PCR 0-7, PCR 11")] DXE -. extend .-> TPM BMGR -. extend .-> TPM WLOAD -. extend .-> TPM NT -. extend .-> TPM ELAM -. extend .-> TPM

Before there was a chain to walk, there was no chain at all.

2. Before Secure Boot: sector zero and the fiction of OS-level security

Ask what was actually verified during a 2011 PC boot, and the answer is: one byte pair. The 0x55AA magic at the end of the 512-byte master boot record. That is a format check, not an authenticity check. The 16-bit BIOS power-on self test loaded sector zero of the boot device into memory at 0000:7C00 and jumped [@wp-mbr]. No signature. No measurement. Whatever was at sector zero, ran.

That architectural fact had been the structural lesson of computer-security history for a quarter century. Stoned, the boot sector virus written by an unknown student in Wellington, New Zealand in 1987, demonstrated it without malicious intent: the virus was a prank that displayed "Your PC is now Stoned!" and propagated by writing itself to the boot sector of every disk a victim machine touched [@wp-stoned]. Brain (Pakistan, 1986) [@wp-brain] and Michelangelo (1991) [@wp-michelangelo] were the same lesson at scale. The lesson was not that those particular authors were dangerous. It was that any code reaching sector zero ran with implicit privilege.

A class of malware that survives operating-system reinstallation and antivirus scanning by infecting code that runs *before* the operating system loads -- traditionally the master boot record or the partition's volume boot record, more recently the EFI System Partition or the firmware itself. A bootkit's defining property is that the operating system it boots is one the bootkit itself chooses to load.

The modern bootkit family arrived in 2005 and ran undefended for the next seven years. Derek Soeder and Ryan Permeh of eEye published BootRoot at Black Hat USA 2005 [@bhusa05-bootroot], a proof of concept that hooked the BIOS interrupt 13h disk-read service before any operating system loaded and intercepted Windows kernel images on the way to memory. Vbootkit (Vipin and Nitin Kumar) followed in 2007, demonstrating the same primitive on Vista [@vbootkit-archive]. Mebroot (the malware family Sinowal/Torpig used) compiled in November 2007 according to early infection telemetry, weaponised the technique against actual victim populations [@wp-mebroot]. By 2011, TDL-3 and TDL-4 had pushed the lineage into the millions of infected hosts [@kaspersky-tdl4].

The category took its final structural step on 13 September 2011, when Marco Giuliani at Webroot's threat lab disclosed Mebromi, the first BIOS rootkit found in the wild. Mebromi targeted Award BIOS firmware. It used the legitimate Phoenix CBROM.EXE utility -- a tool the BIOS vendor itself shipped for assembling firmware images -- to splice malicious code into the firmware ROM image, then flashed the modified ROM through System Management Mode. On every subsequent boot, the firmware itself reinstalled the rootkit's MBR before any operating system existed to scan for it.The Mebromi reuse of the legitimate CBROM.EXE firmware-assembly utility is the canonical illustration of the architectural problem. The defender's tools and the attacker's tools were the same tools. The firmware-update path had no signature, no measurement, and no policy gate; CBROM was just an executable that knew the Award ROM image format. The fix was not better antivirus. The fix was a hardware root that the OS itself could not rewrite.

The structural argument that Mebromi made unanswerable: there was no measurement endpoint and no signature verifier anywhere below the operating system. Every operating-system-level defence was rhetorical against this layer. Kernel-Mode Code Signing, the policy Windows Vista x64 had introduced in 2006 [@app-identity-sibling], was enforced by code that the bootkit could rewrite before the kernel started checking. Driver Signature Enforcement was a setting the operating system wrote into a memory location the operating system could not yet defend.

Trust must be rooted in something the operating system cannot rewrite. That means the chain has to start before the operating system exists. The next rung is firmware itself.

3. UEFI Platform Initialization: SEC, PEI, DXE, BDS, and where Secure Boot actually lives

If Secure Boot starts at the operating-system loader, which exact piece of firmware decides whether the operating-system loader is allowed to run, and what verifies that piece? The answer is a four-phase pipeline that almost no Windows engineer ever writes about. It is also where every modern firmware attack lands.

The Unified Extensible Firmware Interface Platform Initialization specification defines the internal architecture firmware uses to bring a system up. It splits boot into four phases: Security (SEC), Pre-EFI Initialization (PEI), Driver Execution Environment (DXE), and Boot Device Selection (BDS). Standard Windows usage of "UEFI" almost always means the externally-visible behaviour exposed by BDS and the EFI runtime services, not the multi-phase internal pipeline the firmware uses to get there.

The four phases, per the TianoCore reference flow [@tianocore-pi-flow]:

SEC. The Security phase begins at processor reset. Code runs from immutable on-die ROM or a locked region of SPI flash before main memory is even initialised. SEC's job is to establish the root of trust in the firmware -- before any flexible code path can be taken, the firmware has committed to an instruction stream the operating system cannot influence.
PEI. Pre-EFI Initialization brings up DRAM, configures the memory controller, populates Hand-Off Blocks (HOBs) the later phases consume, and dispatches the small drivers needed to reach a state where general firmware code can run. SEC and PEI together are the part of firmware that fits in the few hundred kilobytes of cache-as-RAM the CPU offers before main memory is up.
DXE. The Driver Execution Environment hosts most of what we think of as firmware: the disk drivers, the network stack, the human-interface drivers, the USB stack, and Secure Boot's image verifier. This is where LoadImage() runs db/dbx checks against incoming PE/COFF binaries. DXE phase code is several megabytes on a modern x86 platform.
BDS. Boot Device Selection reads the BootOrder UEFI variable, picks a boot entry, hands the platform off to the operating system loader, and -- in normal operation -- never runs again until the next reboot.

flowchart LR BG["Boot Guard / AMD PSB
(microcode, OTP fuses)"] --> SEC["SEC
immutable ROM"] SEC --> PEI["PEI
DRAM init"] PEI --> DXE["DXE
Secure Boot LoadImage()"] DXE --> BDS["BDS
read BootOrder"] BDS --> OS["bootmgfw.efi"]

There is one rung below SEC. Intel Boot Guard verifies the firmware via a CPU-microcode-loaded Authenticated Code Module signed by Intel [@wp-txt]; AMD Platform Secure Boot performs the same role from the AMD Platform Security Processor (PSP), an ARM-based co-processor embedded on the SoC [@ioactive-psb, @wp-amd-psp]. Both run before SEC can begin. Intel introduced Boot Guard on platforms based on the Haswell processor family (4th-generation Core, Lynx Point PCH) in 2013 [@eset-lojax, @wp-txt]; the actual root-of-trust fuses live in the PCH (on Haswell through Skylake-era platforms; from Ice Lake (2019+) onward, Intel placed the fuses on the CPU die itself) [@eset-lojax], and the OEM commits the verification key at provisioning, so Boot Guard support is a chipset-and-OEM property rather than a bare CPU-model property [@eset-lojax, @ioactive-psb]. AMD's PSB followed on EPYC server parts and was rolled out to Ryzen Pro platforms over the next several years; the PSP itself has been present on AMD client and server parts since around 2013 [@wp-amd-psp], but PSB is a distinct firmware-signing flow that uses it [@ioactive-psb].The Windows Hardware Compatibility Program codified UEFI 2.3.1 as the firmware floor for Windows 10 security features [@ms-oem-uefi]. Anything below 2.3.1 cannot host a Secure Boot configuration that Microsoft will certify. The keys that anchor those verifications are burned into one-time-programmable fuses inside the package, so the OEM commits to a public key when the part ships and cannot rotate it later [@eset-lojax, @ioactive-psb]. ESET's 2018 LoJax disclosure recommended Boot Guard explicitly: "if possible, have a processor with a hardware root of trust as is the case with Intel processors supporting Intel Boot Guard (from the Haswell family of Intel processors onwards)" [@eset-lojax].Boot Guard's OTP fuses are the canonical example of why hardware-rooted verification cannot have a software-only escape hatch [@eset-lojax, @ioactive-psb]. If the OEM's signing key leaks, the fuses cannot be reprogrammed in the field; an attacker with the leaked key can produce firmware that the silicon will accept. This is the structural argument behind moving the root one more rung down -- into Pluton, where Microsoft, not the OEM, owns the update cadence.

The conclusion is the part most engineers skip. By the time bootmgfw.efi is verified, several megabytes of DXE-phase code have already executed. Anything that compromises the DXE compromises Secure Boot from below: the verifier itself is now the attacker's code. That is the precondition that LogoFAIL exploits, and it is the reason "Secure Boot starts at the OS loader" is the wrong mental model.

NIST recognised the structural problem early. NIST Special Publication 800-147 BIOS Protection Guidelines (April 2011) [@nist-sp-800-147] articulated the BIOS-update-signing baseline two years before Boot Guard shipped a hardware-rooted answer. SP 800-147 said only that firmware updates must be signed; it did not say who must verify the signing key. Boot Guard and PSB were the hardware-rooted answer to that gap, with the OEM holding the verification key in OTP fuses.

Now we have a place to put a verifier. The next question is what it verifies, and who signed the allowlist.

4. Secure Boot itself: PK, KEK, db, dbx, and the Microsoft monoculture

Secure Boot is four UEFI variables, one Authenticode hash per binary, and one centralised root of trust. The technical content of this section is not the hard part. The social and operational content -- who holds which key, and what happens when a signed binary becomes vulnerable -- is the rest of the article.

The four authenticated UEFI variables, defined in UEFI 2.3.1 (April 2011) and refined through the current 2.11 specification (December 16, 2024) [@oem-secure-boot]:

PK -- the Platform Key. The OEM holds the private half. Whoever holds PK can rewrite KEK, db, and dbx; whoever holds PK can turn Secure Boot off by replacing PK with a key it does not actually own.
KEK -- the Key Exchange Key. Both the OEM and Microsoft hold KEKs. KEK is the trust anchor for db and dbx updates. A KEK-signed update can add or remove entries in db and dbx without touching PK.
db -- the signature database. This is the allowlist: hashes the firmware will accept, plus certificates whose signers it will accept. db typically contains a small handful of entries.
dbx -- the forbidden signatures database. The denylist: hashes and certs the firmware must refuse, even if they would otherwise pass db.

Four EFI variables defined by the UEFI specification that together form Secure Boot's trust hierarchy. Each variable is *authenticated*: any update must be signed by a key one rung up the hierarchy. PK signs updates to KEK, db, and dbx; KEK signs updates to db and dbx. Microsoft requires the Microsoft Corporation KEK CA to be present in KEK on every Windows-certified PC, so that Microsoft can push db and dbx updates without OEM cooperation per device.

The verification algorithm runs every time UEFI calls LoadImage() on a PE/COFF binary, in this order:

Hash the PE/COFF image. The Authenticode digest excludes the signature directory and the checksum field, so the hash is computed over the parts of the image that should not change between signing and loading [@ms-pe-format].
If the hash matches a hash in dbx, reject.
Else if the signer's certificate chains to a certificate in dbx, reject.
Else if the hash matches an entry in db, accept. Else if the signer chains to a certificate in db, accept.
Else, reject.

Microsoft's WHCP requires firmware components to be signed with at least RSA-2048 and SHA-256 [@oem-secure-boot]. That floor is generous by 2026 standards but has held without serious controversy since the original UEFI 2.3.1 release.

flowchart TD L["LoadImage(image)"] --> H["Compute Authenticode hash"] H --> D1{"Hash in dbx?"} D1 -- yes --> R["REJECT"] D1 -- no --> D2{"Signer chains to dbx cert?"} D2 -- yes --> R D2 -- no --> D3{"Hash in db, OR signer chains to db cert?"} D3 -- yes --> A["ACCEPT (load image)"] D3 -- no --> R

The de facto roots for x86 PCs are two Microsoft-rooted certificate authorities, both pre-trusted in db on essentially every certified Windows-class system: the Microsoft Windows Production PCA 2011, which signs Microsoft's own Windows boot binaries (bootmgfw.efi, bootmgr.efi, winload.efi), and the Microsoft Corporation UEFI CA 2011, which signs third-party UEFI binaries -- Linux's shim, option ROMs, and third-party firmware drivers [@sbat-shim, @oem-secure-boot]. The rhboot/shim project documents the arrangement: every certified PC is "typically configured to trust 2 authorities for signing UEFI boot code, the Microsoft UEFI Certificate Authority (CA) and Windows CA" [@sbat-shim]. The fact that both are Microsoft-rooted is the reason Secure Boot, as deployed, and "Microsoft is the gatekeeper of which operating systems may boot" are operationally the same thing. The UEFI Forum's specification did not require that monoculture. The economics did. There are exactly two certificate authorities every OEM is willing to trust by default, and both belong to the operating-system vendor whose installer media every OEM ships.

The X.509 certificate authorities Microsoft uses for Secure Boot. Two CAs from the 2011 family ship pre-installed in db on essentially every Windows-certified PC: the **Microsoft Windows Production PCA 2011** signs Microsoft's own Windows boot binaries, and the **Microsoft Corporation UEFI CA 2011** signs third-party UEFI binaries (Linux's `shim`, option ROMs, third-party firmware drivers). Both 2011 certificates begin expiring in late June 2026. The **Windows UEFI CA 2023** is their successor; its industry-wide enrolment began in May 2023 with the KB5025885 program responding to CVE-2023-24932 and is still rolling out under phased automatic enrolment via monthly Windows Updates as of 2026. Linux's path through Secure Boot runs through `shim.efi`, a small bootloader Matthew Garrett released on November 30, 2012 -- his last day at Red Hat. The trick is structural: Microsoft signs `shim` itself; `shim` is shipped on the install media of every major Linux distribution; once running, `shim` validates a distribution-signed `grubx64.efi` (or kernel) using a key the distribution embeds, *or* a Machine Owner Key (MOK) the user has enrolled at install time. Garrett credits the MOK design to engineers at SUSE. The arrangement is the open-source community's pressure valve against the Microsoft monoculture: Linux still boots on Secure Boot hardware because Microsoft signs one bootloader that delegates trust to a community-managed key store. It also explains why Linux dual-boot installs began breaking after May 2023 -- the certificates that signed older copies of `shim` are being rotated out.

The dbx variable carries the operational weight of the system. If a signed bootloader is found to be vulnerable, the only blocking remedy is to add its hash to dbx. dbx lives in NV-RAM; on commodity Windows PCs the storage budget is roughly 32 KB total [@sbat-shim].The 32 KB figure comes from the rhboot/shim project's SBAT documentation, which notes that the BootHole disclosure of July 2020 -- a single GRUB vulnerability requiring revocation of three certificates and roughly 150 image hashes -- consumed approximately 10 KB of dbx in one event. That is one third of the available capacity, used up by one CVE. Linux distributions and Windows share the same dbx region. A botched update can refuse to validate a bootloader that the platform actually needs, and there is no remote rollback for a brick-on-write to dbx. Section 9 will show what happens when dbx revocation lags behind a CVE.

The CA-2023 transition is therefore not a routine certificate rotation. The original 2011 certificates begin expiring in late June 2026. Microsoft's industry-wide Windows UEFI CA 2023 rollout started May 2023 with KB5025885, the patch advisory that paired with CVE-2023-24932, and is on track to be, in Microsoft's own framing, one of the largest coordinated security maintenance efforts the Windows install base has ever seen [@kb5025885]. The phasing, as published: enrol the new CA in db; sign new bootloaders with it; enrol new dbx entries to revoke older signed-but-vulnerable binaries; finally, revoke the 2011 CA. The published cautionary text is unambiguous: once the irreversible mitigation step is enabled on a device, "it cannot be reverted if you continue to use Secure Boot on that device. Even reformatting of the disk will not remove the revocations if they have already been applied" [@kb5025885].

{` // Sketch of what UEFI does for every PE/COFF binary it loads. function loadImage(image, db, dbx) { const hash = authenticodeHash(image); const signerCert = parseSignerCert(image);

if (dbx.hashes.includes(hash)) return { ok: false, reason: "dbx hash" }; if (signerCert && chainsTo(signerCert, dbx.certs)) { return { ok: false, reason: "dbx cert" }; } if (db.hashes.includes(hash)) return { ok: true, reason: "db hash" }; if (signerCert && chainsTo(signerCert, db.certs)) { return { ok: true, reason: "db cert" }; } return { ok: false, reason: "not in db" }; }

const decision = loadImage( { hash: "abc", signer: "Microsoft Windows Production PCA 2011" }, { hashes: [], certs: ["Microsoft Windows Production PCA 2011", "Microsoft Corporation UEFI CA 2011"] }, { hashes: [], certs: [] } ); console.log(decision); `}

Verification is a one-shot signature check at firmware boundaries. The chain still has to extend all the way to userland. Microsoft's name for what comes next is Trusted Boot. And here is the thing the patch-cadence narrative fails to convey: patched is not revoked. Microsoft can ship a fixed bootmgfw.efi next month. It cannot delete the old, vulnerable, validly-signed copy from every machine in the world. As long as the old binary's hash is not in dbx, Secure Boot will load it.

5. Trusted Boot: bootmgfw.efi, winload.efi, and the Windows-specific chain

Secure Boot can answer "is this .efi file in our allowlist?" It cannot answer "is every kernel-mode driver loaded after this .efi file in our allowlist?" That second question is what Trusted Boot exists to answer.

Microsoft's term for the post-firmware portion of the verified boot chain. UEFI Secure Boot validates `bootmgfw.efi`. `bootmgfw.efi` validates `winload.efi`. `winload.efi` validates `ntoskrnl.exe`, the Hardware Abstraction Layer, every boot-start driver, and the ELAM driver. `ntoskrnl.exe` validates every driver loaded thereafter against the active code-integrity policy. Trusted Boot is therefore the Microsoft policy enforcement chain layered *on top of* Secure Boot's firmware-side verifier; it is what extends the signature check past the operating-system loader into kernel mode.

The mechanics, after the firmware hands control to bootmgfw.efi: the boot manager reads the Boot Configuration Data store, locates winload.efi (or winresume.efi for resuming from hibernation), and enforces the boot-time integrity policy on every component it loads [@ms-trusted-boot]. The verifier handoff, however, is more interesting than the Microsoft Learn paragraph suggests. It runs in three stages.

Stage A: winload's in-image bootlib verifier. winload.efi does not call kernel-mode ci.dll to validate boot images. It carries its own boot-time code-integrity verifier inside the bootlib boot library shared with bootmgr. Reverse-engineering work on the Elysium bootkit research framework reconstructed the call chain inside winload.efi: OslLoadDrivers -> OslLoadImage -> LdrpLoadImage -> BlImgLoadPEImageEx -> ImgpLoadPEImage, with ImgpValidateImageHash performing the Authenticode digest check against the trusted boot policy embedded in winload itself [@elysium-bootkit]. Boot-start drivers, ntoskrnl.exe, the Hardware Abstraction Layer, and the ELAM driver all flow through this chain before kernel mode is alive to do anything about it.

Stage B: handoff via LOADER_PARAMETER_EXTENSION. When winload.efi is done validating, it has to hand the validated state across the loader-kernel boundary. The mechanism is LOADER_PARAMETER_EXTENSION (LPE), the under-documented structure that hangs off the LOADER_PARAMETER_BLOCK whose address the loader passes to the kernel.The LPE structure has been Microsoft-internal in every shipping Windows release; the public reference Geoff Chappell maintains is the canonical third-party reverse-engineering of its layout across Windows builds. New fields are added at the tail of the structure when shipping features need to communicate state across the loader/kernel boundary. The fact that Smart App Control's CI state needed two new LPE fields is a small but telling indicator of how much policy state Trusted Boot now carries. Geoff Chappell's reference describes the LPE as "part of the mechanism through which the kernel and HAL learn the initialisation data that was gathered by the loader" [@geoffchappell-lpe]. The structure has grown across Windows builds; with Smart App Control on Windows 11 22H2, two new fields -- CodeIntegrityData and CodeIntegrityDataSize -- were added so that the loader-validated CI state, including the active SiPolicy and the pre-validated boot-start driver list, would survive the handoff intact [@n4r1b-sac].

Stage C: kernel-mode ci.dll continuation. Only after ntoskrnl.exe is itself running does the kernel-mode ci.dll come into play. It picks up the SiPolicy state from the LPE and continues the same code-integrity policy enforcement on every kernel-mode image loaded after the loader's window closes -- principally via the Se-prefixed validation routines that the kernel's image-load notification routines call into. From that point, every subsequent driver load goes through the same code-integrity gate. The bootlib -> LPE -> kernel-mode ci.dll decomposition is the underlying mechanism Microsoft's high-level documentation collapses into a single sentence:

The Windows bootloader verifies the digital signature of the Windows kernel before loading it. The Windows kernel, in turn, verifies every other component of the Windows startup process, including boot drivers, startup files, and your anti-malware product's early-launch anti-malware (ELAM) driver. -- Microsoft Learn [@ms-trusted-boot]

Trusted Boot is therefore the Windows-specific extension of the verifier into kernel mode. UEFI Secure Boot is platform-agnostic; it ships in db on every certified PC. Trusted Boot is the policy engine that reuses the firmware-side trust anchor and walks it forward into ntoskrnl.exe. The mechanism for how SiPolicy is parsed, how publisher rules are evaluated, and how the kernel's code-integrity state machine handles attempts to load binaries outside policy, lives in this article's App Identity sibling and is not redefined here [@app-identity-sibling].

There is a failure mode you can see coming. If the trusted boot manager itself is signed but vulnerable, the chain still validates, the policy still enforces, and the entire defence is bypassed. The signature is correct; the code path is what is wrong. Section 9 will show what happens when an older bootmgfw.efi revision contains a memory-map manipulation flaw that lets attacker-controlled data flow before the SiPolicy enforcement engine is up. That is the BlackLotus failure. For now, hold the framing: Trusted Boot's guarantee is "every kernel-mode component has a valid Microsoft signature." It is not "every Microsoft signature in this chain corresponds to a binary that is itself secure."

Verification can stop loading bad code. It cannot prove that good code was loaded. For that we need a parallel rail.

6. Measured Boot: SRTM, the TPM event log, and PCR 0-7+11 in order

Verification stops bad code from running. Measurement makes sure you can prove, after the fact, what code did run. The two rails do not protect against the same thing. This is the article's mechanism-densest section, and the place a few key terms have to be exactly right.

A boot-time chain of cryptographic measurements anchored in a Core Root of Trust for Measurement (CRTM): a code segment in the platform's flash that is implicitly trusted because it is immutable and is *measured by construction* into the TPM before any flexible code runs. SRTM extends one PCR per component as the chain unfolds, producing a tamper-evident log of exactly which firmware, boot manager, and kernel the platform launched. The measurement does not stop bad code; it records what code ran so a verifier can decide later.

The TPM extend primitive is the cryptographic core. The TPM never overwrites a PCR. When the platform asks the TPM to extend PCR N with a measurement m, the TPM does:

$$\mathrm{PCR}[N] := H\bigl(\mathrm{PCR}[N] ,\Vert, m\bigr)$$

where H is the bank's hash algorithm (SHA-1 on TPM 1.2; SHA-1 and SHA-256 banks both required by the TCG PC Client Platform Firmware Profile on TPM 2.0; SHA-384 and SHA3 banks optional and present on some newer parts) and || is byte concatenation [@syss-bitpixie]. The TPM 2.0 specification was finalised by the Trusted Computing Group on 9 April 2014 [@wp-tpm]. The mechanism guarantees that any later PCR value is a function of every prior measurement in the order it was extended -- you cannot rewind, and you cannot reorder. The TPM 2.0 PC Client profile specifies at least 24 PCRs, the first 16 of which are append-only and non-resettable until the platform itself is reset [@syss-bitpixie]. The full TPM extend mechanics are covered in this article's TPM sibling; we do not redefine them here [@tpm-sibling].

The PCR allocation, per the TCG PC Client Platform Firmware Profile, corroborated against the SySS Bitpixie writeup [@syss-bitpixie] and Microsoft Learn [@ms-secure-boot-process]:

PCR	Extended by	What it measures
0	CRTM, SEC, PEI	SRTM core firmware code (BIOS/UEFI)
1	PEI / DXE	Host platform configuration (CPU microcode, NVRAM settings)
2	DXE	UEFI driver and application code (option ROMs)
3	DXE	UEFI driver and application configuration / data
4	DXE / BDS	Hashes of all boot managers in the boot path; `bootmgfw.efi` lands here
5	BDS	Boot manager code config and data; GPT; boot attempts
6	DXE / OEM	Host platform manufacturer specific
7	DXE	State of Secure Boot: PK, KEK, db, dbx hashes; the `SecureBoot` variable; signing certificate of every loaded image
11	`bootmgfw.efi`	BitLocker access control: locked after VMK is obtained

sequenceDiagram participant CRTM participant SEC participant DXE participant BMGR as bootmgfw.efi participant TPM as TPM PCRs CRTM->>TPM: extend PCR[0] with SRTM hash SEC->>TPM: extend PCR[1] with platform config DXE->>TPM: extend PCR[2] with option-ROM code DXE->>TPM: extend PCR[7] with Secure Boot state DXE->>TPM: extend PCR[4] with bootmgfw.efi hash BMGR->>TPM: extend PCR[4] with winload.efi hash BMGR->>TPM: extend PCR[7] with signer cert of winload BMGR->>TPM: extend PCR[11] with BitLocker access flag

PCR[7] deserves a section of its own. On modern Windows, PCR[7] is the canonical seal target for BitLocker. A protector sealed to PCR[7] unwraps cleanly across firmware updates, microcode revisions, and option-ROM changes, because PCR[7] reflects only the Secure Boot state -- the keys in PK, KEK, db, dbx, the SecureBoot variable, and the signing certificates of loaded images. PCR[0..4] are too volatile for sealing on a real fleet because every BIOS update changes them. PCR[7] changes only when Secure Boot policy itself changes [@syss-bitpixie, @ms-system-guard]. The full BitLocker key hierarchy is covered in this article's BitLocker sibling [@bitlocker-sibling]; here we are placing PCR[7] in the chain.

Key idea: Verification stops bad code. Measurement records what code ran. Neither rail is sufficient alone. Modern Windows boot integrity needs both rails reaching the same place -- the kernel and the Secure Kernel -- before user-mode runtime defences take over.

The TCG event log makes the measurement chain useful for more than sealing. Every extend is logged through the TCG2 EFI Protocol with the hash, the algorithm, and a description of what was measured. A verifier (BitLocker locally; an attestation service remotely) can replay the log to recover which binary hashed to which PCR value, and -- if the replay does not match the live PCRs -- detect tampering. Microsoft Learn describes exactly that path: "the PC's firmware logs the boot process, and Windows can send it to a trusted server that can objectively assess the PC's health" [@ms-secure-boot-process].

There is a second root of measurement that sidesteps the firmware-trust regress entirely. DRTM -- Dynamic Root of Trust for Measurement -- is late-launched after firmware boot, via Intel TXT's GETSEC[SENTER] instruction or AMD's SKINIT. It resets PCR[17..22] at locality 4 and re-anchors a measurement chain in a vendor-controlled allowlistable module that does not depend on the DXE phase having been clean [@wp-txt, @ms-system-guard]. Microsoft documents the motivation in plain language:

There are thousands of PC vendors that produce many models with different UEFI BIOS versions. This creates an incredibly large number of SRTM measurements upon bootup. [@ms-system-guard]

The argument: SRTM measurements are platform-specific. An attestation service that wants to know whether a given device booted clean must hold an allowlist of SRTM measurements covering N OEMs * M models * K firmware revisions. The allowlist explodes; the blocklist is asymmetric in the attacker's favour. DRTM collapses the allowlist by defining one small, well-known late-launched measurement chain that the attestation service can recognise across every Secured-core PC.

A late-launched measurement chain that re-anchors trust *after* firmware boot, by using a CPU instruction (`GETSEC[SENTER]` on Intel, `SKINIT` on AMD) to reset a designated set of PCRs and execute a small, vendor-controlled measured launch module. DRTM is Microsoft's answer to the SRTM allowlist explosion. It powers System Guard Secure Launch, which Windows 10 1809 introduced; on supported hardware, the late-launched module brings up the hypervisor and Secure Kernel from a trust anchor that the firmware cannot influence.

The DRTM PCR allocation is parallel to SRTM but lives in a separate range, PCR[17..22], reset only by the late-launch event. Per the TCG PC Client Platform Firmware Profile (corroborated against the Wikipedia Trusted Execution Technology mirror, since TCG returns HTTP 403 to non-browser fetches) and Microsoft's System Guard documentation [@wp-txt, @ms-system-guard]:

PCR	Reset by	What it measures
17	`GETSEC[SENTER]` / `SKINIT` at locality 4	DRTM-event measurement and Launch Control Policy hash extended by the SINIT ACM (Intel TXT) or the Secure Loader block hash (`SKINIT` on AMD)
18	locality 4	Trusted-OS start-up code (the Measured Launch Environment itself)
19	locality 4	Trusted-OS measurement, e.g., OS configuration
20	locality 4	Trusted-OS measurement, e.g., OS kernel and other code
21	locality 4	Reserved for and defined by the Trusted OS
22	locality 4	Reserved for and defined by the Trusted OS

The reset semantics are the load-bearing detail. PCR[0..16] are append-only after platform reset; they cannot be cleared without rebooting the box. PCR[17..22] are different: they can be reset during runtime, but only by an atomic late-launch event. That asymmetry is what makes DRTM's anchor verifiable [@wp-txt, @syss-bitpixie].

The mechanism that enforces it is TPM locality. Locality is a side-channel attribute on every TPM command identifying which entity issued the request. Locality 0 is general OS and application traffic. Locality 4 is assertable only by the CPU itself, during the atomic GETSEC[SENTER] (Intel TXT) or SKINIT (AMD) sequence. The TPM accepts a Reset of PCR[17..22] only when the request arrives tagged with locality 4. No software running outside the late-launch instruction can forge that tag. That is the structural reason DRTM's late-launch is verifiable rather than forgeable [@wp-txt].

The asymmetry pays off for an attestation service. If a remote verifier reads PCR[17] and finds it equal to zero, DRTM did not happen on this boot. If it reads PCR[17] and finds it equal to the iterated extend $\mathrm{PCR}[17] := H\bigl(0 ,\Vert, H(\text{SINIT_ACM_hash} ,\Vert, \text{LCP_hash})\bigr)$ (or, more accurately, the chain of extends the SINIT ACM logged), a CPU-vendor-signed SINIT Authenticated Code Module seeded the chain, and the value is recomputable by the verifier from the published, signed SINIT ACM and the platform's Launch Control Policy [@wp-txt, @ms-system-guard]. The verifier's allowlist for DRTM measurements is bounded by the small set of CPU-vendor-signed measured-launch modules in circulation (SINIT ACMs on Intel TXT; the Secure Loader block measured directly by SKINIT on AMD) -- not by the cross-product of OEMs, models, and firmware revisions.

{` // Demonstrates the PCR extend formula: // PCR[N] := H( PCR[N] || measurement ) // Run it to see how PCR[4] would evolve as bootmgfw, winload, and ntoskrnl // hashes are extended one after another.

const sha256 = (buf) => createHash('sha256').update(buf).digest();

function extend(pcrHex, measurementHex) { const pcr = Buffer.from(pcrHex, 'hex'); const m = Buffer.from(measurementHex, 'hex'); return sha256(Buffer.concat([pcr, m])).toString('hex'); }

// Real PCRs start as 32 bytes of zero on a TPM 2.0 reset. let pcr4 = '00'.repeat(32);

const measurements = [ { name: 'bootmgfw.efi', hash: 'aa'.repeat(32) }, { name: 'winload.efi', hash: 'bb'.repeat(32) }, { name: 'ntoskrnl.exe', hash: 'cc'.repeat(32) }, ];

for (const m of measurements) { pcr4 = extend(pcr4, m.hash); console.log(`after ${m.name}: PCR[4] = ${pcr4.slice(0, 16)}...`); } `}

We now have two rails of trust ready to converge in the kernel. The next thing the kernel has to do is hand control to defenders that can keep the chain alive into runtime.

7. ELAM, the kernel, and the Secure Kernel bring-up: where the chain ends

Trusted Boot has signed every kernel-mode binary along the path. Then what? The chain still has to outlive the boot.

A specially-signed driver class introduced in Windows 8 (2012) that loads as the *first* boot-start driver -- ahead of every other boot-start driver -- and classifies each subsequent boot-start driver as *Good*, *Bad*, *Unknown*, or *BadButCritical* before the operating-system loader allows it to load [@ms-elam, @ms-elam-driver-requirements]. ELAM's classification influences whether Windows loads the driver. The ELAM driver itself is a Microsoft-signed binary in the `Early-Launch` service-start group and is itself measured into the SRTM chain; the user-mode anti-malware service that consumes its classification events runs as a Protected Process Light (PPL).

ELAM exists for a specific reason. The boot-start group includes anti-malware, device, and disk drivers that have to load before the rest of the operating system. Before Windows 8, those drivers all loaded in an undefined order, with no anti-malware product running yet. A bootkit that survived the kernel's signature check (or a driver that was signed but malicious) had a window in which nothing was watching. ELAM closed that window by ordering one driver -- a Microsoft-signed AM driver -- as the first boot-start driver, and giving it the right to classify those drivers as they loaded [@ms-elam]. ELAM is itself a boot-start driver; the Microsoft documentation specifies the INF requirement plainly: "An ELAM Driver advertises its group as 'Early-Launch'" [@ms-elam-driver-requirements]. The associated user-mode anti-malware service runs as a Protected Process Light (PPL), so even SYSTEM-privileged user-mode code cannot inject into it [@ms-elam, @app-identity-sibling].The classification surface ELAM exposes is the four-element set Good / Bad / Unknown / BadButCritical, enumerated in Microsoft's BDCB_CLASSIFICATION reference (ntddk.h) as BdCbClassificationKnownGoodImage, BdCbClassificationKnownBadImage, BdCbClassificationUnknownImage, and BdCbClassificationKnownBadImageBootCritical (the ELAM driver requirements page itself only enumerates three classes in prose; the fourth lives in the enum reference) [@ms-elam-driver-requirements]. The fourth category exists because some drivers are required for the system to boot; the AM driver's verdict on those is advisory rather than blocking. Defender ships the ELAM driver in Windows; Microsoft's interface allows third-party AM products to ship their own [@ms-elam].

The kernel itself does the next set of jobs. ntoskrnl.exe initialises memory protections and DMA defences. Kernel DMA Protection enables the IOMMU (Intel VT-d or AMD-Vi) so that PCIe peripherals either DMA only to memory their compatible driver has assigned (DMA-Remapping-compatible drivers, enumerated and started normally) or are blocked from starting and performing DMA entirely until an authorised user signs in or unlocks the screen (DMA-Remapping-incompatible drivers, the user-presence-gated default); both regimes block the drive-by-DMA pattern that targets arbitrary kernel memory and defend against malicious Thunderbolt peripherals [@ms-kernel-dma-protection]. The Driver Block List, enforced at code-integrity load time, refuses to load a recognised set of vulnerable signed drivers (the canonical example is gdrv2.sys); details in this article's App Identity sibling [@app-identity-sibling]. HVCI (Hypervisor-Enforced Code Integrity, also called Memory Integrity) is loaded inside the Secure Kernel and enforces W^X on all kernel-mode memory; details in the Secure Kernel sibling [@secure-kernel-sibling].

Then the Secure Kernel comes up. securekernel.exe and skci.dll initialise in Virtual Trust Level 1 -- a Hyper-V-managed isolation domain that the normal Windows kernel in VTL0 cannot read or write. The first Trustlet is LSAIso, the isolated process Credential Guard uses to hold NTLM hashes and Kerberos tickets out of reach of any kernel-mode attacker [@secure-kernel-sibling]. Control returns to the normal kernel; the user-mode tail begins.

flowchart TD WL["winload.efi"] --> NT["ntoskrnl.exe (VTL0)"] NT --> SK["securekernel.exe (VTL1)"] SK --> LSA["LSAIso (Credential Guard Trustlet)"] NT --> ELAM["ELAM driver"] ELAM --> BS["boot-start drivers (classified by ELAM)"] BS --> SMSS["smss.exe"] SMSS --> WI["wininit.exe"] WI --> WL2["winlogon.exe"] WL2 --> UI["userinit.exe -> explorer.exe"]

The user-mode tail is not security-cryptographic per se. SMSS (the Session Manager) loads system DLLs and starts the first Win32 subsystem session. wininit.exe initialises the LSA, the Service Control Manager, and the Local Session Manager. winlogon.exe paints the credential UI, calls into Windows Hello [@no-secrets-to-steal-sibling] if applicable, and authenticates the user. userinit.exe runs the logon scripts and launches explorer.exe [@ms-trusted-boot]. From the boot-integrity perspective, userinit is the moment the static-time guarantees of Trusted Boot end and the runtime defences -- Defender, EDR, attestation -- take over.

We have walked the chain end to end. The next question is: when did this chain actually start working?

8. The breakthroughs that made the chain land (2014-2024)

Secure Boot existed in 2012. Secure Boot worked (in the sense of defending most of what it claims to defend) only after roughly a decade of operational fixes that almost nobody outside Microsoft and a handful of OEMs ever wrote about. Four breakthroughs deserve naming. The matrix below collates them by layer fixed and fix-delivery vehicle before the prose treatments that follow.

#	Breakthrough	Year	Layer it fixed	Fix-delivery vehicle
B1	PCR[7] becomes the canonical BitLocker seal target	~2014-2016	Sealing brittleness; PCR[0..4] churn vs. firmware-revision cadence	Windows servicing + BitLocker policy default change [@syss-bitpixie, @ms-system-guard]
B2	Forced retirement of the Microsoft UEFI CA 2011	May 2023 - June 2026	Revocation gap (BlackLotus / Baton Drop)	KB5025885 / CVE-2023-24932 multi-year, opt-in dbx push and CA-2023 enrolment [@kb5025885]
B3	Secure Kernel becomes the launch destination	Win10 2015 - Win11 2021	"Kernel signed" is insufficient (TDL-4 lesson)	OS feature ship and WHCP requirement; HVCI / Driver Block List default-on by 2024 [@ms-trusted-boot, @secure-kernel-sibling]
B4	Pluton arrives as a Microsoft-firmware-authored RoT	Nov 2020 announcement; Q1 2022 first silicon	LPC/SPI bus-sniffing class against discrete TPMs; OEM patch-cadence latency for fTPM/PTT firmware	Windows-Update-delivered Pluton firmware (alongside UEFI capsule), Rust-based on 2024+ AMD/Intel parts [@ms-pluton]

The first row is operational, not architectural: PCR[7] becoming the canonical BitLocker seal target, somewhere between Windows 8.1 and Windows 10 1607 [@syss-bitpixie, @ms-system-guard]. Before PCR[7], BitLocker sealed against PCR[0..4]: firmware code, platform configuration, option ROMs, option-ROM configuration, and boot-manager hashes. Every UEFI update -- and on real fleets they happen monthly -- changed PCR[0..4] and forced BitLocker into recovery, which forced an IT staffer to find the recovery key, which was annoying enough to make people turn BitLocker off. PCR[7] sealing decoupled the BitLocker protector from the firmware-revision churn and made Measured Boot durable in practice. This is the operational fix that made Measured Boot actually worth running on a fleet of thousands of laptops with monthly UEFI capsule updates.

The second row is the forced retirement of the Microsoft UEFI CA 2011, which began in May 2023 with KB5025885 and CVE-2023-24932 and is on track to complete in late 2026 [@kb5025885]. This was the first serious dbx housekeeping in a decade. The relevant point: the fix had to be a programme, not a hotfix, because dbx is too small to handle a one-shot revocation of a CA-rooted set without bricking either some Linux dual-boots or some Windows machines. The CA-2023 rollout phases the work across four years.

The third was VBS and the Secure Kernel becoming the launch target the boot chain was actually defending. Without the Secure Kernel as a destination, Trusted Boot's guarantee ended at "the kernel is signed", which TDL-4 had already shown was insufficient -- a signed kernel is of limited use if the SYSTEM-privileged user-mode code that follows can rewrite kernel memory through a vulnerable signed driver. The Secure Kernel arrived in Windows 10 1507 (2015) and matured into its enforced-by-default form in Windows 11 (2021), at which point the chain had a hardware-isolated destination that even a SYSTEM-level attacker could not reach without a hypervisor exploit [@secure-kernel-sibling].

The fourth is still landing. Pluton, the cryptoprocessor whose firmware Microsoft (not the OEM) ships and updates, was announced in November 2020 and reached its first silicon -- AMD Ryzen 6000 -- in Q1 2022 [@ms-pluton]. Pluton is not yet ubiquitous, and its Secure Boot story is pending: as of 2026, Pluton ships as a TPM 2.0 implementation [@ms-pluton-as-tpm], not as a replacement verifier. Section 10 unpacks why the Microsoft-firmware-on-silicon-Microsoft-doesnt-own model matters more than the part numbers do.

These were the operational fixes. The architectural breaks they were responding to are the next section.

9. The boot-chain attacks that actually worked

There has never been a public Secure Boot attack that broke the cryptographic primitive. Every successful attack has exploited the same gap: between fixing a vulnerability and revoking the signed binaries that carried it. The CVE numbers change. The structure does not.

Scope note: LoJax (ESET, September 2018) was the first real-world UEFI rootkit deployed in the wild, but it operates at the SPI flash layer -- below Secure Boot's signature verification chain -- and is therefore outside the scope of this table. The table focuses on attacks on the Secure Boot signature-enforcement chain itself.

Attack	Year	Rung broken	Prerequisite	dbx state at disclosure	Fix path
ESPecter	2021	ESP-resident bootmgr replacement	Secure Boot disabled	n/a	Enable Secure Boot
FinSpy UEFI	2021	bootmgfw.efi replaced on ESP	Secure Boot disabled	n/a	Enable Secure Boot
BlackLotus / CVE-2022-21894 (Baton Drop)	2022-23	Signed-but-vulnerable older bootmgfw	Patched but unrevoked old binaries	Old binaries not revoked	dbx update via KB5025885
Bitpixie / CVE-2023-21563	2022-24	PXE soft-reboot leaks BitLocker VMK	TPM-only BitLocker; LAN + keyboard	n/a (no signature break)	Pre-boot PIN; KB5025885
LogoFAIL / CVE-2023-39539 et al.	2023	DXE-phase image-parser RCE	UEFI logo customisation accepting attacker BMP	n/a	OEM UEFI updates
Bootkitty	2024	Self-signed PoC; Secure Boot disabled or LogoFAIL	Linux target	n/a	Enable Secure Boot; patch LogoFAIL
WinRE / CVE-2024-20666 family	2024	Recovery Environment downgrade	TPM-only BitLocker; reachable WinRE	n/a	Servicing stack updates

ESPecter (ESET, October 2021) [@eset-especter] is the simplest case. It is an ESP-resident bootkit that bypasses Driver Signature Enforcement to load its own unsigned kernel driver -- but only on systems with Secure Boot disabled. ESPecter is in the table to make the category visible: the ESP is a writable FAT partition with no signature on the contents, and any malware that can write to the ESP and persuade the firmware to boot from a different bootmgfw path can win on a non-Secure-Boot system. The fix is to turn Secure Boot on.

FinSpy (Kaspersky, September 2021) [@kaspersky-finspy] is the same attack family carrying an actual nation-state-grade payload. Kaspersky's GReAT analysis names the mechanism plainly: "All machines infected with the UEFI bootkit had the Windows Boot Manager (bootmgfw.efi) replaced with a malicious one." The malicious bootmgfw injected code into winlogon.exe for persistence. Again, Secure Boot disabled was the precondition. FinSpy was the proof that the ESP-resident category had real-world tradecraft attached, not just academic interest.

BlackLotus (advertised on hacking forums from at least October 2022 [@eset-blacklotus]; ESET writeup 1 March 2023) is the case that defines the modern era [@eset-blacklotus, @wack0-batondrop]. BlackLotus does not disable Secure Boot. It chain-loads a legitimately-signed but vulnerable older bootmgfw.efi revision. The vulnerability is CVE-2022-21894, nicknamed Baton Drop: an older boot manager honoured a truncatememory setting that removed blocks of memory containing serialised data structures from the memory map. The Wack0 PoC repository describes the primitive: "Windows Boot Applications allow the truncatememory setting to remove blocks of memory containing 'persistent' ranges of serialised data from the memory map, leading to Secure Boot bypass" [@wack0-batondrop]. The chain: boot the legitimately-signed older bootmgfw; trigger Baton Drop; install a malicious SiPolicy that disables further checks; load an unsigned kernel driver; persistently disable HVCI, BitLocker, and Defender from below the trusted-boot horizon. Microsoft's incident-response guide for BlackLotus enumerates six classes of detection artefact: recently-written ESP files, staging directories, registry entries, event-log evidence of policy changes, network indicators, and BCD-log modifications [@ms-blacklotus-guidance]. The NSA and CISA published a joint mitigation guide on 22 June 2023 [@nsa-blacklotus]. ESET's epitaph is the article's recurring quote:

Exploitation is still possible as the affected, validly signed binaries have still not been added to the [UEFI revocation list]. -- Martin Smolar, ESET, March 2023 [@eset-blacklotus] sequenceDiagram participant Attacker participant ESP as EFI System Partition participant FW as UEFI firmware participant BMGR as bootmgfw (older signed) participant OS as Windows kernel Attacker->>ESP: drop legit but old signed bootmgfw FW->>BMGR: LoadImage() -- signature OK, hash NOT in dbx Attacker->>BMGR: trigger CVE-2022-21894 (truncatememory) BMGR->>BMGR: install malicious SiPolicy BMGR->>OS: load unsigned driver OS->>OS: disable HVCI, BitLocker, Defender

The "disables HVCI / BitLocker / Defender from below the trusted-boot horizon" framing in the caption is verbatim from the ESET disclosure and is reinforced by Microsoft's own incident-response guide [@eset-blacklotus, @ms-blacklotus-guidance].

Bitpixie / CVE-2023-21563 [@neodyme-bitpixie, @syss-bitpixie] is BlackLotus' twin in BitLocker space. The vulnerability was discovered by Rairii in August 2022; Thomas Lambertz of Neodyme published a public PoC at 38C3 in December 2024. The mechanism is a downgrade. The attacker boots the target machine into Windows' PXE network-recovery soft-reboot path, which loads a Microsoft-signed but older bootmgfw.efi revision. That older revision does not erase the BitLocker VMK from physical memory before the PXE soft-reboot hands off, leaving the VMK in RAM where the chained payload (a signed Linux PE or downgraded WinPE) can dump it. The combination of TPM-only BitLocker (no pre-boot PIN), a Microsoft-Account-defaulted Windows 11 install (which biases toward TPM-only encryption), and physical access to a network port and keyboard, decrypts the disk in minutes. Lambertz' framing: "All an attacker needs is the ability to plug in a LAN cable and keyboard to decrypt the disk" [@neodyme-bitpixie]. Bitpixie does not break Secure Boot. It exploits the same operational invariant -- old-but-signed binaries still validate -- in a different protection domain.

Note: TPM-only BitLocker is no longer a defensible default on Windows 11 once Bitpixie's PoC is public; the attack reduces to a LAN cable and a keyboard. See Section 11's Replace TPM-only BitLocker bullet for the pre-boot-factor fix list [@neodyme-bitpixie, @kb5025885].

Bootkitty (ESET, 27 November 2024) [@eset-bootkitty] closes a symmetry. Twelve years after Andrea Allievi's September 2012 PoC -- the first UEFI bootkit designed for Windows 8 [@theregister-allievi] -- Bootkitty is the first UEFI bootkit aimed at Linux. Bootkitty was uploaded as a self-signed PoC, so on systems with Secure Boot enabled, it does not load unless the attacker's certificate has been enrolled in the Machine Owner Key (MOK) list -- either by a user via mokutil (the ordinary Linux path), by a prior compromise enrolling the cert, or by chaining LogoFAIL (CVE-2023-40238) to inject a rogue MOK certificate from a malicious BMP, as Binarly demonstrated [@binarly-logofail-bootkitty]. Bootkitty patches kernel-image-integrity functions and pre-loads ELF binaries via init. ESET later updated the attribution: an analysis posted in early December 2024 traced the build to a Korean Best of the Best (BoB) student project. The structural lesson is platform-orthogonal -- Secure Boot's gaps live in the firmware and revocation surfaces, not in any one operating system.

The Allievi 2012 ITSEC PoC was *the first UEFI bootkit*, full stop -- a research artefact that demonstrated, on Windows 8, the same trick BootRoot had demonstrated on the Windows NT/2000/XP MBR seven years earlier. Twelve years later, Bootkitty is the first UEFI bootkit *for Linux*, also a research artefact. The arc closes a symmetry: UEFI's verifier is platform-agnostic, so its weaknesses are too. A LogoFAIL-style image-parser bug in DXE compromises Secure Boot whether the operating system above it is Windows or Ubuntu. The attacker community needed twelve years to apply the technique to the second platform, but only because the second platform's market share for boot-chain attacks was smaller, not because the verifier was structurally any safer.

LogoFAIL (Binarly REsearch, Black Hat EU 2023; CVE-2023-39539, CVE-2023-40238, CVE-2023-5058; advisory BRLY-2023-006) is the most architectural of the breaks because it compromises the verifier itself. The DXE phase parses a customisable boot logo image -- the OEM splash screen displayed on power-on -- and the parser is a piece of firmware code accepting an attacker-controlled input. Binarly demonstrated parser bugs in the BMP, GIF, JPEG, PCX, and TGA decoders shipped in reference code by all three major Independent BIOS Vendors -- AMI, Insyde, and Phoenix -- across roughly six hundred enterprise device models. A successful exploit gives the attacker code execution at the DXE phase, which is below Secure Boot's LoadImage() verifier. From DXE, the attacker can do whatever they want before the operating-system loader runs. Bootkitty later carried a LogoFAIL exploit (CVE-2023-40238) to inject a rogue MOK certificate from a malicious BMP, demonstrating the chain end to end [@binarly-logofail-bootkitty].

Finally, the WinRE / ReAgent.xml downgrade family (CVE-2024-20666 and successors) is the smaller cousin of the bigger story [@nvd-cve-2024-20666]. The Recovery Environment is a Windows partition with its own boot path; older WinRE images that contain unrevoked vulnerable bootmgr.efi revisions can be persuaded to mount the encrypted volume under attacker control. The attack does not break the Secure Boot chain; it routes around it. The point of including it in this catalogue: it is another instance of the dbx-revocation-by-hash limit. As long as an older signed binary exists and is reachable, Secure Boot's verifier will validate it.

Every attack here exploits the same operational invariant: the gap between patched and revoked is wide, and dbx is too small to close it. The next section examines whether anything can.

10. Theoretical limits, open problems, and the Pluton pivot

If every break has been operational, why has nobody fixed the operations? Because the operational bounds are themselves theoretical.

Six structural limits.

The verifier-of-verifiers regress. Secure Boot's verifier is firmware code that itself must be trusted. Boot Guard and AMD PSB push that root one rung deeper, into silicon ROM and OTP fuses [@ioactive-psb, @wp-txt]. Pluton arguably pushes it one rung deeper still, into silicon Microsoft directly updates. There is no software-only bottom turtle. Every architecture in the field has some layer that is trusted because there is no further layer to which trust can be deferred. The engineering question is which party owns that layer -- OEM, Intel, AMD, or Microsoft via Pluton -- and on whose update cadence the layer can be patched. IOActive's 2024 review of AMD PSB found that "various major vendors fail to" configure PSB correctly [@ioactive-psb], which is the kind of operational failure mode no cryptographic primitive can fix.

Why dbx revocation is hard. dbx is small, shared with Linux, vendor-implemented, and a brick-risk if mismanaged. The list stayed nearly empty for a decade until BlackLotus forced KB5025885's multi-year program [@nvd-cve-2023-24932]. SBAT (Secure Boot Advanced Targeting), the partial answer in the rhboot/shim project [@sbat-shim], revokes by generation number rather than by image hash. SBAT works by embedding a CSV-formatted vendor-and-component-version table in every shim-signed binary; when the firmware-side SBAT policy variable says "minimum acceptable shim generation is 4", every older shim hashes correctly but is refused for being too old. SBAT collapses tens of revocation events that would each consume hundreds of bytes of dbx into a single small metadata bump. The UEFI Forum has, since 2024, deferred to the canonical Microsoft-managed secureboot_objects GitHub repository [@ms-secureboot-objects] as the source of truth for KEK, db, and dbx contents.

A revocation scheme designed by the rhboot/shim project to address dbx capacity exhaustion. Instead of revoking each vulnerable signed binary by Authenticode hash (which consumes ~32 bytes of dbx per binary), SBAT revokes by *generation number*: each signed component carries a CSV-formatted version table; a small SBAT policy variable in firmware specifies the minimum generation accepted; older builds are refused without consuming dbx capacity. SBAT is the project's structural answer to the cohort-revocation problem the §4 Sidenote quantifies.

The SBAT generation-number scheme is also the model the Microsoft UEFI CA 2023 rollout extends across the wider Windows install base. KB5025885's mitigation strategy combines a small set of dbx hash revocations with a CA rotation, because no single mechanism by itself can revoke a decade's worth of signed bootloaders within the dbx storage budget [@kb5025885, @sbat-shim].

The signed-but-vulnerable problem. As long as Microsoft-signed bootloaders with known flaws exist on the install media of any production Windows installation, Secure Boot must revoke by hash, by SVN, by SiPolicy, or by certificate -- each with collateral damage. Hash revocation does not cover binaries the attacker has not yet seen. SVN revocation forces a rebuild of every signed binary across the install base. SiPolicy revocation depends on the SiPolicy update reaching every machine. CA rotation breaks PXE recovery, recovery USBs, dual-boot Linux, and custom WinPE images.

Supply chain at the firmware level. LogoFAIL, BMC-resident attacks against rack servers, Boot Guard key leaks (which OTP fuses cannot recover from), and OEM ME/PSP fuse misconfiguration are the categories Secure Boot cannot, by construction, defend against. The verifier sits above these layers; if these layers are compromised, the verifier is running on a base it cannot trust.

SRTM allowlist explosion. N OEMs, M models, K firmware revisions; the allowlist of "good SRTM measurements" explodes; the blocklist is asymmetric in the attacker's favour. DRTM late-launch is the only known way to collapse the allowlist. As Microsoft puts it, "DRTM lets the system freely boot into untrusted code initially, but shortly after launches the system into a trusted state" [@ms-system-guard].

Bus interception of discrete TPMs. A discrete TPM on the LPC or SPI bus can be sniffed by a physical attacker. This is what motivates the move to Pluton: the TPM moves on-die, the bus disappears, and the BitLocker VMK no longer crosses a sniffable wire [@tpm-sibling].

Key idea: Every public Secure Boot break has exploited the gap between patched and revoked, not the cryptographic primitive. The dbx revocation half-life is the article's invariant. Pluton closes the cadence gap on the verifier-update side. It does not close the gap between patched and revoked.

The Pluton pivot. Pluton's pitch, for the boot chain, is to re-anchor both the verification root (long term) and the measurement endpoint (today) in silicon Microsoft can patch [@ms-pluton, @ms-pluton-as-tpm]. Pluton implements TPM 2.0 on the CPU die, so the existing measurement chain plugs in unchanged. What changes is the firmware update cadence -- Pluton firmware ships through Windows Update as an additional channel alongside existing UEFI capsule updates; the key difference is that Microsoft authors and controls the firmware, and the Windows Update path enables Microsoft to deliver fixes independent of OEM release scheduling. The bus disappears: Pluton's interface is on-die--there is no external LPC or SPI bus crossing a package boundary that can be physically tapped, eliminating bus-sniffing as an attack class. And on 2024+ AMD and Intel parts, the Pluton firmware itself is written in Rust, addressing the memory-safety class of bugs that has historically dominated firmware CVEs [@ms-pluton].

flowchart LR subgraph Discrete["Discrete TPM"] CPU1["CPU"] -- LPC/SPI bus
(sniffable) --> dTPM["dTPM (Infineon, STM)"] end subgraph PlutonTopo["Pluton"] CPU2["CPU"] -- on-die mailbox --> PL["Pluton"] end The first reaction to "dbx is too small" is always: make it bigger. Three constraints stop that. First, dbx is implemented by hundreds of OEM firmware vendors against a UEFI specification floor; raising the floor would invalidate every shipped UEFI implementation. Second, dbx is shared between Windows, Linux, ESXi, and other operating systems, so growing it requires coordination across vendors with different incentives. Third -- and the real blocker -- the variable lives in NV-RAM with limited write cycles; a runaway revocation update can brick a board if the write fails partway through. The realistic fix is SBAT for image-version bumps and CA rotation for cohort-scale revocation. Both are partial. Pluton's design only makes sense against the contrast with the two endpoints of the design space.

At one endpoint sits Apple. Apple authors the silicon, the Boot ROM, the iBoot bootloader, the kernel, and the Secure Enclave Processor's sepOS firmware. The Apple Boot ROM holds the Apple Root certificate authority public key directly; it verifies iBoot before iBoot loads anything else; on older A-series parts an additional Low-Level Bootloader stage is verified by the Boot ROM and in turn loads and verifies iBoot [@apple-boot]. The Secure Enclave Processor is "a dedicated secure subsystem integrated into Apple SoC", isolated from the main processor and reachable only over a mailbox interface; sepOS is an L4 microkernel Apple ships and updates [@apple-sep]. Every stage of secure boot is signed by the same vendor that ships the operating system, and "secure boot begins in silicon and builds a chain of trust through software" [@apple-system]. The cadence is the iOS / iPadOS / macOS update cadence -- Apple-cadence -- because the same release pipeline ships everything from the Boot ROM update vehicle to the user-facing apps.

At the other endpoint sits Trusted Firmware-A on Armv7-A and Armv8-A platforms. TF-A is the reference secure-world software stack with a Secure Monitor at Exception Level 3 [@tfa-home]. The Trusted Board Boot feature implements Arm's TBBR-CLIENT specification (DEN0006D): "The Trusted Board Boot (TBB) feature prevents malicious firmware from running on the platform by authenticating all firmware images up to and including the normal world bootloader" [@tfa-tbb]. The chain runs BL1 -> BL2 -> BL31 / BL32 -> BL33, anchored on a ROTPK (Root of Trust Public Key) fused per silicon family. Because TBBR is a specification rather than a single shipping product, the actual signing keys and update cadence are the OEM's choice. The silicon vendor sets the fuse policy; the platform vendor signs the boot images; the operating-system vendor sees a verified BL33 handoff and trusts whatever ROTPK the silicon was fused with. There is no monoculture, and there is no single update cadence -- which is exactly what makes the security guarantees uneven across Arm devices in practice.

Pluton sits between Apple and TF-A. Microsoft authors the firmware (vendor-monopoly trust anchor) on silicon Microsoft does not own (AMD, Intel, Qualcomm fabricate it) [@ms-pluton]. The contrast is sharpest at the firmware-update cadence. Apple-cadence ships everything as one. OEM-UEFI-capsule-cadence is what discrete TPMs and PCH-isolated fTPM/PTT firmware are stuck with -- which is why a known-bad fTPM firmware can take months to land on every customer device after Microsoft posts a fix. Windows-Update-cadence is what Pluton offers: a Microsoft-authored firmware update riding the same channel that ships kernel patches. The same axis -- who owns the trust anchor and on whose schedule it ships -- is the axis on which the article's main Pluton argument turns.

There are honest residual limits. Pluton is a TPM, not a verification chain; the rest of Secure Boot still runs in DXE-phase firmware that LogoFAIL can compromise. Adoption is non-universal -- as of 2026, Pluton ships on Microsoft Surface, AMD Ryzen 6000-9000/AI series, a subset of Intel Core Ultra (200V / Series 3) parts, and Qualcomm Snapdragon 8cx Gen 3 / X parts powering Copilot+ PCs, with many enterprise PCs still on discrete TPMs [@ms-pluton]. The OEM still owns PK and the firmware update path outside Pluton, so the dbx-revocation problem and the OEM-key-leak problem are unaddressed by Pluton alone. Attestation infrastructure -- Device Health Attestation, Intune device-health Conditional Access -- is still maturing, and the policies that consume attestation outcomes are still hand-rolled per organisation.

Pluton closes the cadence gap. It does not close the gap between patched and revoked -- nothing yet does, and that is the next decade's problem.

11. Practical guide, FAQ, and where the chain goes next

This is the part you do today, on whatever Windows machine is in front of you, before this article ages another year.

Verify Secure Boot state. Open an elevated PowerShell prompt and run Confirm-SecureBootUEFI. The cmdlet returns True only if Secure Boot is currently enforcing. msinfo32 shows BIOS Mode (UEFI vs Legacy) and Secure Boot State on its System Summary page. Get-SecureBootPolicy reveals which Secure Boot policy GUID is in force; the default Microsoft policy on a healthy modern install is {77fa9abd-0359-4d32-bd60-28f4e78f784b} (the Microsoft owner GUID for the canonical KEK/db/dbx variables) [@ms-secureboot-objects]. Get-Tpm and tpmtool getdeviceinformation confirm that the TPM is present, owned, and ready [@ms-trusted-boot, @ms-secure-boot-process].

Read the TPM event log. tpmtool gatherlogs collects the WBCL files into a working folder you can inspect; Get-WinEvent -LogName Microsoft-Windows-TPM-WMI exposes the boot and provisioning events. On a healthy boot, the WBCL and the live PCR state replay to the same digest; mismatch is the attestation signal a remote verifier looks for.

The following one-liner gathers the basic state in elevated PowerShell:

"" |
  Select-Object @{n='SecureBoot'; e={ Confirm-SecureBootUEFI }},
                @{n='SBPolicy';  e={ (Get-SecureBootPolicy).Publisher }},
                @{n='TPMReady';  e={ (Get-Tpm).TpmReady }},
                @{n='UEFI/BIOS'; e={ (Get-CimInstance Win32_BIOS).SMBIOSBIOSVersion }} |
  Format-List

If SecureBoot is False, your boot chain has no firmware-side allowlist. If TPMReady is False, BitLocker is sealing to nothing -- recovery-key escrow is your only protector.

Verify your Windows UEFI CA 2023 enrolment. KB5025885 is a phased deployment; the relevant deployment phase is recorded in the registry under HKLM\SYSTEM\CurrentControlSet\Control\Secureboot\AvailableUpdates (or the equivalent CSV in the support article) [@kb5025885]. The current UEFI db can be inspected with Get-SecureBootUEFI db and Format-SecureBootUEFI. The 2023 CA's certificate has subject CN Windows UEFI CA 2023. If you do not see it in db and you are running a Windows install that has been online during 2025-2026, the deployment programme has not reached your device; consult the KB article for the next steps.

Note: The 2011 CA expires in late June 2026. After that, signed-but-old bootloaders that depend on the 2011 CA will not validate without explicit dbx housekeeping. If your install media is older than May 2023 and you have not run a full set of cumulative updates, you may end up with a machine that boots today but cannot boot a future Windows recovery image. The fix is to apply the KB5025885 updates and verify the 2023 CA is enrolled before that deadline [@kb5025885].

Enable DRTM / System Guard Secure Launch where the silicon supports it. The control surfaces are:

MDM CSP: DeviceGuard/ConfigureSystemGuardLaunch.
Group Policy: Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security > Secure Launch Configuration.
Registry: HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\SystemGuard\Enabled = 1.

Verify via msinfo32: under System Summary the Virtualization-based Security Services Configured / Running line should include Secure Launch [@ms-system-guard].

Replace TPM-only BitLocker. After Bitpixie, TPM-only BitLocker is no longer a defensible default. Add a pre-boot PIN (manage-bde -protectors -add C: -tpmAndPin), a USB key, or use device encryption with pre-boot authentication [@neodyme-bitpixie, @syss-bitpixie].

{` // JavaScript analogue of the PowerShell one-liner above. The real cmdlets // query NV variables and the TPM driver directly; this just shows the shape // of what a remote attestation collector would assemble.

function healthCheck(state) { return { secureBoot: state.secureBoot === true, sbPolicyGuid: state.policyGuid ?? 'unknown', tpmReady: state.tpmReady === true, pcr7: state.pcr7, caEnrolled: state.dbCerts.includes('Windows UEFI CA 2023'), notes: [] }; }

const live = healthCheck({ secureBoot: true, policyGuid: '{77fa9abd-0359-4d32-bd60-28f4e78f784b}', tpmReady: true, pcr7: '0xab4c...', dbCerts: ['Microsoft Windows Production PCA 2011', 'Microsoft Corporation UEFI CA 2011', 'Windows UEFI CA 2023'] });

console.log(live); `}

No. Secure Boot defends the boot chain. Ransomware targets user data after the operating system is up and the user is logged in, so it sees a signed Windows kernel exactly as it should. The defences against ransomware are runtime: Defender, EDR, Controlled Folder Access, and offline backups. Secure Boot is a precondition for trusting the operating system that hosts those runtime defences, but it is not a runtime defence itself. Yes, via the Microsoft-signed `shim`. The maintenance burden: keep `shim` current under the Windows UEFI CA 2023 rollout (`shim-signed`, `shim-x64`, `mokutil` packages on most distributions) or your Linux install will lose its boot path when older `shim` builds are revoked. See `The shim escape hatch` Aside in §4 for the underlying mechanism [@sbat-shim]. Yes. Pluton replaces the TPM, not the signature-verification chain. Pluton is a cryptoprocessor: it implements TPM 2.0 on the CPU die, holds keys, performs `extend` operations, and signs attestations [@ms-pluton-as-tpm]. Secure Boot is the firmware-side `LoadImage()` allowlist check. The two rails are complementary, not substitutes -- Pluton makes Measured Boot's endpoint better; it does not replace Secure Boot's verifier. The 2011 CA is being revoked. You need a `shim` signed by the 2023 CA. Update from your distribution's secure-boot package (the canonical names are `shim-signed`, `shim-x64`, or `mokutil`). If your installation media is older than May 2023 and you have not run distribution updates, expect breakage somewhere between your next dbx update and the June 2026 expiry [@kb5025885, @sbat-shim]. Not as a default. After Bitpixie / CVE-2023-21563, TPM-only BitLocker can be defeated with a LAN cable and a keyboard on a Windows 11 install with Microsoft Account defaults. See `Replace TPM-only BitLocker` in Section 11 for the fix list [@neodyme-bitpixie]. Trusted Boot is *signature-policy enforcement*: `bootmgfw.efi` and `winload.efi` refuse to load any kernel-mode binary whose Authenticode hash or signer is not in the trusted-boot policy, and the kernel-mode `ci.dll` continues that enforcement after handoff. Measured Boot is *hash-into-PCR recording*: every binary that loads is also extended into a TPM PCR so a verifier (BitLocker locally, an attestation service remotely) can later prove what code ran. Trusted Boot stops bad code; Measured Boot records what code ran. They run in parallel, not in sequence [@ms-trusted-boot, @ms-secure-boot-process].

The chain is longer than it has ever been. It is not yet long enough.

The next article in this series picks up where userinit ends. Once Windows is running, the question shifts from which code loaded? to what does this device look like to a remote verifier right now? Device Health Attestation, runtime measurement of the running kernel and Secure Kernel, and Conditional Access decisions tied to attestation outcomes are the runtime continuation of everything we walked through here. Pluton on the boot chain feeds Pluton-rooted attestation at runtime. Secure Boot ends at the desktop. The runtime chain begins there.