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

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 ^[1]. 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 ^[2]. 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 ^[3]. Brain (Pakistan, 1986) ^[4] and Michelangelo (1991) ^[5] 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.

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 ^[6], 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 ^[7]. Mebroot (the malware family Sinowal/Torpig used) compiled in November 2007 according to early infection telemetry, weaponised the technique against actual victim populations ^[8]. By 2011, TDL-3 and TDL-4 had pushed the lineage into the millions of infected hosts ^[1].

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 ^{[9, 10]}. 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 Phoenix's own CBROM.EXE 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 ^[11], 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 four phases, per the TianoCore reference flow ^[12]:

• 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 ^[13]; AMD Platform Secure Boot performs the same role from the AMD Platform Security Processor (PSP), an ARM-based co-processor embedded on the SoC ^{[14, 15]}. 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 ^{[16, 13]}; the actual root-of-trust fuses live in the PCH ^[16], 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 ^{[16, 14]}. 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 ^[15], but PSB is a distinct firmware-signing flow that uses it ^[14]. ※ The Windows Hardware Compatibility Program codified UEFI 2.3.1 as the firmware floor for Windows 10 security features ^[17]. 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 ^{[16, 14]}. 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)" ^[16]. Boot Guard's OTP fuses are the canonical example of why hardware-rooted verification cannot have a software-only escape hatch ^{[16, 14]}. 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) ^[18] 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) ^{[19, 20, 21]}:

• 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.

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

1. 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 ^[22].
2. If the hash matches a hash in dbx, reject.
3. Else if the signer's certificate chains to a certificate in dbx, reject.
4. Else if the hash matches an entry in db, accept. Else if the signer chains to a certificate in db, accept.
5. Else, reject.

Microsoft's WHCP requires firmware components to be signed with at least RSA-2048 and SHA-256 ^[21]. 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 ^{[23, 21]}. 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" ^[23]. 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 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 ^[23]. 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 ^{[26, 27]}. 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" ^[27].

// 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.

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 ^[28]. 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 ^[29]. 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" ^[30]. 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 ^[31].

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 ^[28]

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

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.

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 ^[32]. The TPM 2.0 specification was finalised by the Trusted Computing Group on 9 April 2014 ^[33]. 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 ^[32]. The full TPM extend mechanics are covered in this article's TPM sibling; we do not redefine them here ^[34].

The PCR allocation, per the TCG PC Client Platform Firmware Profile, corroborated against the SySS Bitpixie writeup ^[32] and Microsoft Learn ^[35]:

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 ^{[32, 36]}. The full BitLocker key hierarchy is covered in this article's BitLocker sibling ^[37]; here we are placing PCR[7] in the chain.

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

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 ^{[13, 36]}. 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." ^[36]

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.

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 ^{[13, 36]}:

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

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

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 ^{[13, 36]}. 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.

import { createHash } from 'node:crypto';

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.

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 ^[38]. ELAM is itself a boot-start driver; the Microsoft documentation specifies the INF requirement plainly: "An ELAM Driver advertises its group as 'Early-Launch'" ^[39]. 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 ^{[38, 11]}. 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) ^{[39, 40]}. 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 ^[38].

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

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 ^[42]. 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 ^[43] if applicable, and authenticates the user. userinit.exe runs the logon scripts and launches explorer.exe ^[28]. 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.

The first row is operational, not architectural: PCR[7] becoming the canonical BitLocker seal target, somewhere between Windows 8.1 and Windows 10 1607 ^{[32, 36]}. 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 ^{[27, 26]}. 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 ^[42].

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 ^{[44, 45]}. Pluton is not yet ubiquitous, and its Secure Boot story is pending: as of 2026, Pluton ships as a TPM 2.0 implementation ^[46], 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.

ESPecter (ESET, October 2021) ^[47] 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) ^[48] 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 ^[49]; ESET writeup 1 March 2023) is the case that defines the modern era ^{[49, 50, 51]}. 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" ^[51]. 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 ^[52]. The NSA and CISA published a joint mitigation guide on 22 June 2023 ^[53]. 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 ^[49]

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 ^{[49, 52]}.

Bitpixie / CVE-2023-21563 ^{[54, 55, 56, 32]} 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" ^[54]. Bitpixie does not break Secure Boot. It exploits the same operational invariant -- old-but-signed binaries still validate -- in a different protection domain.

Bootkitty (ESET, 27 November 2024) ^[57] closes a symmetry. Twelve years after Andrea Allievi's September 2012 PoC -- the first UEFI bootkit designed for Windows 8 ^[58] -- 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 ^[59]. 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.

LogoFAIL (Binarly REsearch, Black Hat EU 2023; CVE-2023-39539, CVE-2023-40238, CVE-2023-5058; advisory BRLY-2023-006) ^{[60, 61, 62]} 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 ^[59].

Finally, the WinRE / ReAgent.xml downgrade family (CVE-2024-20666 and successors) is the smaller cousin of the bigger story ^[63]. 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 ^{[14, 13]}. 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 ^[14], 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 ^[64]. SBAT (Secure Boot Advanced Targeting), the partial answer in the rhboot/shim project ^[23], 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 ^{[65, 66]} as the source of truth for KEK, db, and dbx contents.

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

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 ^{[44, 34]}.

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 ^{[45, 46, 44]}. 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, not through OEM UEFI capsules, so there is no longer a multi-month gap between Microsoft fixing a Pluton bug and the fix landing on a customer device. The bus disappears: Pluton's interface is a SoC-internal mailbox, not LPC or SPI, 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 ^[45].

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

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 ^[45]. 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) ^[66]. Get-Tpm and tpmtool getdeviceinformation confirm that the TPM is present, owned, and ready ^{[28, 35]}.

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.

"" |
  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

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

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 ^{[72, 36]}.

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

// 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);

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.