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

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 ^[3]. 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 ^{[1] [3] [4]}. The affected platform generations spanned Tiger Lake, Alder Lake, and Raptor Lake ^[4]. Binarly published a per-device impact catalogue in their SupplyChainAttacks repository for triage by the affected vendors ^[5].

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.

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 ^[6]. 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 ^[7]. 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 ^[8].
• Bootkitty ^{[9] [10]}. 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 ^[11]; Liam O'Murchu's contemporaneous Symantec Threat Intelligence writeup is the source MITRE catalogues at ATT&CK ID S0001 as the canonical primary ^[12]. 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 ^[13].

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 ^[14]. 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 ^[15]) 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 ^[14] 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 ^[16], 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 ^[17]. 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" ^[17]. 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 ^{[18] [19]}. The Converged Security and Management Engine (CSME) brand name folded ME, TXE, and SPS into a single architectural label.

"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 ^[20]

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 ^[21]. The talk demonstrated unsigned-code execution in the CSME via the JTAG / Direct Connect Interface chain that became Intel security advisory INTEL-SA-00086 ^[22]. Intel's CSME security white paper postdates the disclosure and treats the same architecture from the vendor side ^[23]. 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 ^[24], 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 ^{[17] [25]}. 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 ^[24]. The first thing your CPU does is verify a manifest signed by Intel that tells it where the OEM's keys live.

Intel: Boot Guard, CSME, and the manifest chain#

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

1. The Boot Guard ACM loads into a protected region of CPU cache and executes inside the CPU package.
2. It reads the FPF for the OEM key hash and the active profile bits.
3. It pulls the Key Manifest (KM) from SPI and verifies the KM signature against the FPF-stored hash.
4. It pulls the Boot Policy Manifest (BPM) and verifies the BPM signature against the KM public key.
5. 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.
6. On a match, it transfers control to the IBB and the chain proceeds.
7. On a mismatch, it halts (profile 4 and profile 5) or extends PCR 0 with the measurement and continues (profile 3) ^[24].

The Bulygin BH EU 2018 reverse engineering remains the most readable primary on the actual code path ^[24].

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 ^[23]. Once stable, it exposes three optional services ^[23]:

• 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 ^[25]. 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.

Sources: ^{[18] [19]}.

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) ^{[18] [19]}.

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 ^{[28] [29] [17]}. 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 ^[33], 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 ^[17].

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 ^[25].

4.4 IBB verification and SEC phase#

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.

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 ^[34] 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.

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 ^[6]. 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.

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) ^[35].

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 ^[36]. 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.

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.

At the top of the chain, on a Pluton-equipped platform, Microsoft can ship Pluton firmware updates through Windows Update ^[38]. 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 ^[38].)

Below Pluton, SBAT denies entire classes of vulnerable shim binaries with one generation bump ^[37]. 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" ^[3]. The Register confirmed the affected platform generations as Tiger Lake, Alder Lake, and Raptor Lake ^[4]. Binarly's per-device catalogue lists the affected SKUs in detail ^[5].

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 ^[37]. 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 ^[2].

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

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) ^{[41] [2]}. The CVE was the underlying vulnerability that the BlackLotus bootkit had exploited via CVE-2022-21894 several months earlier ^{[7] [8]}. 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 ^[2]: 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 ^[42]. 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" ^[38].

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 ^{[38] [43]}. 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#

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#

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 ^[9].

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 ^{[46] [47] [48] [49]}.

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 ^[38]. 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 ^[42].

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#

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 ^{[25] [32]}.

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 ^[50]. Caliptra is "the specification, silicon logic, ROM and firmware for implementing a Root of Trust for Measurement (RTM) block inside an SoC" ^[51]. The full RTL is open at chipsalliance/caliptra-rtl ^[52] and the firmware at chipsalliance/caliptra-sw ^[53], 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.

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 ^{[54] [55]} -- originated by Bulygin and colleagues at CanSecWest 2014 ^[15] -- 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 ^{[56] [57]}, 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 ^{[1] [3] [4]}.

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 ^{[51] [50]}. Eclypsium's "Vulnerable Boot Guard implementations" series ^[58] 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#

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 ^{[22] [21]}.
• CVE-2020-8705. A Boot Guard ACM vulnerability in the S3-resume code path that Trammell Hudson wrote up ^{[61] [62]}.
• 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 ^[28], with open tooling at PSPReverse/amd-sp-glitch ^[31].
• 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 ^[29].

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 ^[58]. The structural fix -- per-batch keys, multi-signer trust anchors, hardware-bound signing services -- exists as Caliptra in specification ^[51] 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 ^[38] but has not publicly named the specific runtime. Community speculation around Tock OS ^[63] (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 ^{[35] [64] [37]}. 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 ^[36] are widely supported, but vendor-level attestation (Intel SGX DCAP ^[65], 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 ^[29], 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" ^[37]. 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#

The full CHIPSEC module catalogue is in the chipsec/modules directory of the project repository ^{[54] [55]}. 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.

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#

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

11. Frequently Asked Questions#

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.