Parag Mali - tag: pluton

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

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

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

1. Permanently Downgraded to a Weaker Trust Model

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Intel: Boot Guard, CSME, and the manifest chain

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1 Reset and microcode bootstrap

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

4.2 Intel ACM execution and AMD PSP first-stage boot

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

4.3 FPF and OEM-fuse policy read

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

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

4.4 IBB verification and SEC phase

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

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

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

4.5 PEI and DXE phases

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

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

4.6 DXE Secure Boot variable evaluation

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

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

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

4.7 Boot Device Selection and bootmgfw.efi

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

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

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

4.9 Hand-off to winload.efi

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

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

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

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

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

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

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

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

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

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

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

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

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

MSI 2023 as the worked example

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pluton's structural role in the modern chain

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

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

Silicon comparison

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

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

Bootkit comparison: same invariant, different break

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

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

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

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

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

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

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

Pluton's value proposition

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

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

The shift cuts two ways:

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

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

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

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

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

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

AMD PSB on EPYC versus Ryzen

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

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

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

Caliptra: the open multi-signer answer

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

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

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

8. Theoretical Limits: Where the Chain Cannot Reach

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

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

Limit 1 -- Physical SPI access bypasses everything above it

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

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

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

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

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

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

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

Limit 4 -- Thunderbolt SPI is a separate SPI region

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

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

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

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

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

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

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

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

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

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

9. Open Problems: What Is Still Being Researched

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

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

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

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

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

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

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

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

Three audiences. Three checklists. One decision tree.

For the procurement architect: the seven-question silicon checklist

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

For the firmware engineer: SBAT versus dbx revocation capacity

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

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

For the detection engineer: CHIPSEC modules per chain rung

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

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

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

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

The chain closes three threat classes:

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

The chain does not close three other classes:

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

Practitioner alternative stacks

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

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

11. Frequently Asked Questions

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

Closing thought

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

"The Vault is Solid. The Delivery Truck is Not." -- Microsoft Recall's Two-Year Re-Architecture from Plaintext SQLite to VBS Enclaves

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

In May 2024 Microsoft shipped Recall as a plaintext SQLite database guarded only by a SYSTEM-only filesystem ACL. Three independent researchers -- Kevin Beaumont, James Forshaw, and Alexander Hagenah -- broke it in four weeks. The September 27, 2024 re-architecture moved every sensitive operation into a VBS Enclave, sealed the master key with TPM 2.0, gated each access on a fresh Windows Hello biometric, and filtered credentials with Microsoft Purview Exact Data Match before persistence. It is the cleanest available case study of Pluton, VBS, the Secure Kernel, Hello ESS, and Purview composing into one feature. One seam remains: the non-enclave UI host that Hagenah's April 2026 TotalRecall Reloaded exploits, restating the original threat-model limit at a different layer.

1. The Script That Did Not Ship

On June 5, 2024 -- thirteen days before Microsoft Recall was scheduled to ship on Copilot+ PCs -- a Swiss security researcher named Alexander Hagenah pointed a fifty-line Python tool at the directory C:\Users\<user>\AppData\Local\CoreAIPlatform.00\UKP\ and pulled every screenshot Windows had taken of his desktop for the previous day in two seconds [@rec-19] [@rec-20]. The database was a plaintext SQLite file. The screenshots were plaintext PNGs. Microsoft Defender for Endpoint, monitoring an off-the-shelf information-stealer running in the same user context, took roughly ten minutes to react -- by which time the Recall data was gone [@rec-19] [@rec-15].

Hagenah called the tool TotalRecall and committed it to GitHub the same day [@rec-13]. His own description of what it did, as quoted by Malwarebytes Labs: "The database is unencrypted. It's all plain text. Pulling one day of snapshots took two seconds at most" [@rec-20]. His description of why he released it, as quoted by Help Net Security: "They should know it can be dangerous" [@rec-19].

This is the script that did not ship. Why it did not ship is the entire rest of this article.

Note: The code in the snippet below is the logic of a TotalRecall-style extractor against the May 20, 2024 Recall preview. It is a JavaScript transcription of a PowerShell or Python operation that would have worked against an unencrypted SQLite file in a known directory. The June 7, 2024 delay-and-recommit announcement [@rec-02] withdrew that design before broad release; the September 27, 2024 re-architecture [@rec-03] replaced it. The block exists to teach the historical failure, not to provide a runnable attack against the shipping product.

{` // Simulated extraction logic. Models the May 2024 Recall preview behaviour: // plaintext SQLite at a known user-profile path, plaintext PNGs alongside it. // The September 2024 re-architecture replaced both the storage format // and the trust model. This is a teaching example only.

const recallDir = String.raw`C:\Users\\AppData\Local\CoreAIPlatform.00\UKP`; const databaseFile = `${recallDir}\\ukg.db`; const imageStore = `${recallDir}\\ImageStore`;

// Step 1: Copy the SQLite file and the PNG cache out of the profile. // In the original preview, a same-user process could read both without // elevation, because the only protection was a SYSTEM-context filesystem ACL // that Forshaw demonstrated was bypassable from the user's own context. function exfiltrate() { copyRecurse(recallDir, '/tmp/recall_dump'); // Step 2: open the SQLite file with any client and select the OCR'd text. const ocr = openSqlite(databaseFile); return ocr.query('SELECT c1, c2 FROM WindowCaptureTextIndex_content'); }

// Step 3: every PNG in ImageStore is a snapshot of the desktop, named by // the integer key the SQLite row uses to join. No decryption needed in // the May 2024 preview. console.log('Recall data size:', exfiltrate().length, 'rows'); console.log('Time elapsed (Hagenah measurement): ~2 seconds'); console.log('Defender remediation latency (Beaumont measurement): ~10 minutes'); `}

The audit cast that turned the May 20 announcement into the June 7 retreat had three named protagonists. Kevin Beaumont, writing on his DoublePulsar blog on May 30, framed the threat model: Recall was a high-value secret store on a live, logged-on system, and the dominant live-system adversary was user-context malware, not offline disk theft [@rec-15] [@rec-19] [@rec-16]. James Forshaw, an active Google Project Zero researcher, published Working your way Around an ACL on June 3, demonstrating that the SYSTEM-only filesystem ACL Microsoft had relied on as a same-user isolation boundary was not in fact a boundary [@rec-14]. Hagenah's TotalRecall, posted June 5, turned Beaumont's framing and Forshaw's filesystem-ACL bypass into a runnable artifact [@rec-13] [@rec-19].

Each was load-bearing. Without any one of them, Microsoft's June 7 delay-and-recommit blog [@rec-02] could not have landed where it did, when it did.

What was Microsoft trying to do, that this script could undo?

2. The Four-Week Public Security Audit

Recall was supposed to be the marquee Copilot+ PC feature. Satya Nadella and Yusuf Mehdi previewed it at the Microsoft campus event on May 20, 2024, as one of three launch-exclusive AI experiences alongside Live Captions and Cocreator [@rec-01]. The hardware story was unusual: every Copilot+ PC would ship with Microsoft Pluton enabled by default, on Snapdragon X Elite or X Plus silicon, starting at $999, with broad GA scheduled for June 18 [@rec-01]. Recall would not appear on Intel or AMD Copilot+ PCs at launch, only on the Snapdragon silicon that defined the category.

Twenty-eight days later, the June 18 GA target was gone. Here is what happened in those four weeks.

An information-stealer is a class of malware whose purpose is to enumerate and exfiltrate browser-saved credentials, session cookies, password manager databases, cryptocurrency wallets, and other user-accessible secret stores from a logged-on Windows session. Modern variants (RedLine, Vidar, LummaC2) ship as commodity components in malware-as-a-service marketplaces. Beaumont's structural point about Recall was that adding a new high-value local store to the InfoStealer target list trivially extends an existing economic market; no novel attack capability is required.

May 30, 2024 -- Beaumont names the threat model

Kevin Beaumont's post on DoublePulsar opened with a sentence Microsoft never fully recovered from: "Recall enables threat actors to automate scraping everything you've ever looked at within seconds" [@rec-15] [@rec-19]. His structural point was that BitLocker addresses the wrong half of the threat model for a feature like Recall. BitLocker protects data at rest against an offline adversary who picks up a powered-off laptop; it does nothing against a logged-on user whose machine is running an information-stealer in the same session. Recall, by storing months of OCR'd screenshots in a user-readable directory, was not a target adjacent to the InfoStealer marketplace -- it was the new high-value target inside it.

Beaumont also published a measurement: in his test against Defender for Endpoint, the InfoStealer was detected, but automated remediation took roughly ten minutes to fire. By then his Recall extraction script had already finished [@rec-19] [@rec-15]. The asymmetry mattered. Defender's behavioural rules were calibrated against years of stealing browser cookies, not against the sudden appearance of a brand-new bulk-capture corpus that an attacker would race to exfiltrate first.

Recall enables threat actors to automate scraping everything you've ever looked at within seconds. -- Kevin Beaumont, DoublePulsar, May 30, 2024 [@rec-15] [@rec-19]

June 3, 2024 -- Forshaw publishes the ACL bypass

Three days later, James Forshaw of Google Project Zero published Working your way Around an ACL on Tyranid's Lair [@rec-14]. The post was not nominally about Recall; it was a methodological piece on how a same-user, non-elevated process could escalate to SYSTEM-context file access by impersonating SYSTEM-context services that handle user-supplied input. The worked example was C:\Program Files\WindowsApps, with a footnote linking to a Mastodon thread by Albacore noting that the Recall database directory had a structurally similar ACL.

Forshaw's epigrammatic conclusion -- "any privilege escalation (or non-security boundary cough) is sufficient to leak the information" -- captured the structural critique [@rec-14]. The asterisks around non-security boundary pointed at the MSRC servicing criteria [@rec-11]: Microsoft's own published policy says that UAC and admin-to-kernel transitions are not security boundaries. If those are not boundaries, and the SYSTEM-only filesystem ACL on the Recall directory was the only thing standing between a same-user process and the database, then there was no boundary at all.

June 5, 2024 -- Hagenah commits TotalRecall

Hagenah's tool turned the framing into an artifact [@rec-13] [@rec-19] [@rec-20]. The first README, preserved on the Wayback Machine, characterised Recall as "a 'privacy nightmare'" and noted matter-of-factly that the database was an unencrypted SQLite file readable in two seconds [@rec-13] [@rec-20]. Hagenah's stated motive, via Help Net Security: "They should know it can be dangerous" [@rec-19]. The "they" in that sentence was both the Microsoft engineering team that built the original design and the broader user base about to receive it.

flowchart LR A["May 20
Nadella + Mehdi
Copilot+ launch
Recall previewed"] --> B["May 30
Beaumont
threat-model framing"] B --> C["June 3
Forshaw
SYSTEM ACL bypass"] C --> D["June 5
Hagenah
TotalRecall PoC"] D --> E["June 7
Davuluri
delay + recommit"] E --> F["June 13
Recall removed
from June 18 GA"]

June 7, 2024 -- Davuluri retreats and recommits

Pavan Davuluri -- promoted to President of Windows + Devices on March 26, 2024 -- published the delay-and-recommit blog on June 7 [@rec-02].Wired's coverage of the same announcement referred to Davuluri as "Microsoft's corporate vice president for Windows and devices" [@rec-16]. That was his prior title; the President of Windows + Devices appointment had been announced ten weeks earlier. Most outlets had not yet updated their style sheets, which is the small reason you may have seen two different titles in the same week's coverage. Three commitments anchored the post: Recall would be opt-in at setup rather than on by default ("If you don't proactively choose to turn it on, it will be off by default"); Hello Enhanced Sign-in Security would gate access to stored snapshots; and decryption would happen "just in time," only when the user authenticated [@rec-02].

The Insider rollout was promised, then slipped on August 21 and again on October 31, before finally landing in November. These three properties did not yet have a mechanism. The mechanism would arrive on September 27. But the commitment came first, in plain English, on June 7 -- and it was the commitment that bought the engineering team the time to design the architecture that would honour it.

Three commitments without a mechanism. What was the mechanism going to be?

3. What the Original Recall Design Was Trying

Microsoft did not ship Recall in May 2024 because they thought encryption was unnecessary. They shipped it because they thought the protections they already had were sufficient. Four assumptions. Each one was load-bearing, and each one was wrong.

Before naming them, it is worth crediting what the original design got right, because that commitment survived the re-architecture intact. The data flow was on-device only. Snapshots, OCR'd text, and the local semantic index never traversed the Microsoft Diagnostic Data telemetry pipeline; nothing left the device by design [@rec-01]. That property is preserved in the Generation 3 architecture [@rec-03] and is reiterated in the IT administrator documentation [@rec-08]. The original engineering team did not get the privacy framing wrong as a category. They got the isolation framing wrong.

BitLocker is the Windows full-volume encryption feature. Its threat model is offline disk theft: an adversary who removes a powered-off laptop's storage and tries to read its contents on another machine encounters AES-XTS-encrypted blocks instead of plaintext files. BitLocker is transparent when the device is powered on and the user is logged in; it does not authenticate any individual file access against the running operating system. Beaumont's structural point in §2 was that BitLocker's threat model and Recall's threat model do not overlap: Recall's adversary is a process running in the live, logged-on session. The Data Protection API is the Windows user-mode interface for protecting per-user secrets with a key derived from the user's logon credentials. Browsers historically used DPAPI to protect saved-credential databases; the well-known weakness is that any process running as the user can call `CryptUnprotectData` against the same files and get plaintext back. DPAPI did *not* appear in the original Recall design -- the pre-audit framing that imagined Recall as "DPAPI used incorrectly" was a misreading. The actual original Recall stored a plaintext SQLite file under filesystem ACLs alone, as Hagenah's tool demonstrated [@rec-20] [@rec-19]. The September 2024 re-architecture also does not use DPAPI; it uses TPM-sealed master keys released to a VBS Enclave on Hello ESS authentication [@rec-03].

Assumption 1: The SYSTEM-only filesystem ACL is a same-user isolation boundary

The directory C:\Users\<user>\AppData\Local\CoreAIPlatform.00\UKP\ was protected by an ACL that permitted SYSTEM to read and write, and denied the logged-on user direct access. The original design treated this as an isolation boundary between user-context code and the Recall database. Forshaw's June 3 post refuted this directly [@rec-14]: a same-user process can obtain SYSTEM-context file access by impersonating a SYSTEM-context service that handles user-supplied input. The technique is generic, well documented in the Tyranid's Lair archive, and predates Recall by years. Once Forshaw published the worked example, the original ACL stopped looking like a boundary and started looking like a speed bump.

Assumption 2: BitLocker-at-rest is sufficient because the live system is trusted for the logged-on user

The original team assumed that an attacker against Recall data would necessarily be either (a) an offline adversary with physical possession of the powered-off disk -- defeated by BitLocker -- or (b) an attacker with administrator access -- out of scope per the MSRC servicing criteria [@rec-11]. Beaumont demolished this by pointing at a third class: an in-session, user-context InfoStealer that is already common, already on the InfoStealer-as-a-service price list, and trivially extensible to dump a new SQLite file [@rec-15] [@rec-19]. BitLocker's threat model and Recall's threat model did not overlap; assuming they did was the mistake.

Assumption 3: Defender's automated remediation will outrun InfoStealer exfiltration

Even granting the existence of in-session adversaries, the original assumption was that Defender for Endpoint's behavioural detection would catch them before they finished. Beaumont's measurement said otherwise: the InfoStealer was detected, but automated remediation took roughly ten minutes to land, by which point the exfiltration of a Recall snapshot directory had finished in two seconds [@rec-19] [@rec-15]. The asymmetry was not a Defender bug; it was a category problem. Defender's response is calibrated for the historical InfoStealer corpus (browser cookies, credential databases); a new bulk corpus introduces a race the existing rules were not tuned for.

Assumption 4: Same-user, administrator-level access is not a security boundary anyway

This last assumption is technically correct, per the MSRC servicing criteria [@rec-11]. UAC, admin-to-kernel, and same-user post-authentication are documented non-boundaries. The argument goes: if a feature is "in the user's trust boundary" -- any code running as the user can access it -- then any attacker who is already running as the user has by definition already won. The feature has nothing further to defend.

The trouble is that the demonstrated Recall attacks did not require admin. Beaumont's testing and Forshaw's ACL impersonation both operated from standard-user context [@rec-15] [@rec-14]. "Same-user attacks are out of scope" is a different statement from "attacks that succeed without elevation are out of scope," and the original Recall design conflated the two.The Malwarebytes coverage of Hagenah's tool described the attack as requiring "administrator rights" [@rec-20]. This was an overstatement -- Beaumont and Forshaw both established that admin was not required. Subsequent coverage in Help Net Security used the stricter framing [@rec-19].

Key idea: Same-user code is in the user's trust boundary unless the architecture explicitly authenticates per-access. A SYSTEM-only filesystem ACL is not authentication; it is access control under an assumption (no impersonation) that the Windows DACL model does not enforce in the user's favour. BitLocker is not authentication either; it is data-at-rest encryption with a key already released by the time the user is logged on. The original Recall design relied on both of these to act like per-access authentication, and neither one was built to do that.

If "same-user code is in the user's trust boundary" was the bug, what does an architecture look like that authenticates per-access?

4. From the June 7 Commitment to the September 27 Architecture

The June 7 retreat named three properties: opt-in, Hello-gated, just-in-time decrypted. The architecture that enforces those properties did not exist on June 7. It existed by September 27, was previewable on November 22, and shipped across Snapdragon, Intel, and AMD between April 25 and May 13, 2025. Here is the path between the commitment and the architecture.

Generation 0: The substrate that already existed

Before Recall, the VBS Enclave primitive was already running in production -- but in a corner of the Windows-server stack that desktop engineers rarely visited. SQL Server 2019 introduced Always Encrypted with secure enclaves on November 4, 2019, almost five years before the Recall preview [@rec-10]. The feature lets a database hold client-encrypted columns and still answer equality and range queries inside an enclave that is part of the sqlservr.exe process but isolated from the rest of it. The Microsoft Learn page for VBS Enclaves cross-links Always Encrypted as a sibling consumer of the primitive [@rec-06].

This matters for two reasons. First, the September 27 architecture did not require Microsoft to invent VBS Enclaves -- the primitive shipped in 2019 and had been stable in production for half a decade by the time Recall reached for it. Second, the original input to this article incorrectly imagined Recall as "the first VBS-enclave product outside the credential set"; the correct claim is narrower. Recall is the first VBS-enclave deployment in the Windows desktop shell to receive sustained adversarial review. SQL Server 2019 is the substrate precedent; Recall is the desktop-shell debut.

Microsoft Pluton is a security processor design that integrates root-of-trust functionality, including TPM 2.0 services, directly into the main system-on-chip rather than on a separate discrete chip on the motherboard. The integration matters because the LPC or SPI bus between a discrete TPM and the CPU is the attack surface used by bus-sniffing attacks; on a Pluton-equipped device that bus does not exist for the security-processor traffic. Microsoft publishes the chipset availability list: AMD Ryzen 6000, 7000, 8000, 9000 and Ryzen AI; Intel Core Ultra 200V, Series 3, Series 3 processors; Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series [@rec-24]. Pluton firmware updates ship through Windows Update. A TPM is a tamper-resistant cryptographic processor that holds keys which can be released to the operating system only when a set of preconditions (the values of platform configuration registers, the presence of an authenticated user, the result of an attestation) is met. TPM 2.0 is the version family in current shipment. Recall uses the TPM for *sealing* -- binding the Recall master key to the boot state of the machine and to the identity of the user, so the key cannot be released to a different OS instance or a different user even with full disk access.

Generation 1: The May 20, 2024 design

Already covered in §3. Four assumptions, all wrong; one runnable counter-example (Hagenah's TotalRecall); zero mechanism to make the assumptions right.

Generation 2: The June 7 commitment

The Davuluri blog of June 7 [@rec-02] was not an architecture; it was a set of properties the next architecture would have to enforce. Opt-in is a UX commitment; Hello-gated is a credential commitment; just-in-time decryption is a key-management commitment. Each one rules out a class of approach -- opt-in rules out silent default-on; Hello-gated rules out a key that can be read without biometric attestation; just-in-time rules out a long-lived plaintext cache. None of them, taken alone, prescribes a specific design.

Generation 3: The September 27, 2024 architecture

This is the load-bearing announcement. Davuluri's blog [@rec-03] and David Weston's companion SecurityWeek interview [@rec-17] together describe four security and privacy design principles and five architectural components.

The four principles, drawn from Davuluri's blog [@rec-03]:

The user is always in control. Recall is opt-in at setup, with Hello enrolment required before any snapshot capture.
Sensitive data in Recall is always encrypted, and keys are protected. The blog specifies that encryption keys are bound to the TPM, tied to the user's Hello Enhanced Sign-in Security identity, and can only be used by operations inside a VBS Enclave.
Recall services that operate on snapshots and associated data are isolated. Snapshot processing, OCR, semantic embedding, and the sensitive-content filter all run inside the enclave; the on-disk database holds only ciphertext.
Users are present and intentional about the use of Recall. Hello ESS with anti-hammering and rate-limiting governs each authorisation; PIN fallback is permitted only after Hello has been set up.

The five components: Secure Settings, Semantic Index, Snapshot Store, Recall UI, and Snapshot Service [@rec-03]. Davuluri's architecture diagram labels four of them as inside the trust boundary and one of them -- Recall UI -- as explicitly outside it. The line is verbatim: "Recall components such as the Recall UI operate outside the VBS Enclaves and are untrusted in this architecture." That line is the seam §8 will return to.

It's now fully encrypted, and tied to the user's physical presence. -- David Weston, CVP Enterprise and OS Security, in conversation with Ryan Naraine [@rec-17]

The composition is not novel cryptography. The novelty is the layering: VBS Enclaves (Generation 0 substrate), TPM-2.0 key sealing (a primitive Windows has shipped since 2012), Hello ESS (an attestation primitive cataloged on Microsoft Learn since the Windows 11 launch [@rec-25]), and Microsoft Purview Exact Data Match filtering (a content-classification primitive previously seen in the Microsoft Purview enterprise product) compose into a single user-facing feature. Each layer was already production-stable; the September 27 design wires them together.

First observable build and broad rollout

The first observable build of Generation 3 was Insider Dev Channel Build 26120.2415 on Snapdragon Copilot+ PCs, KB5046723, released November 22, 2024 [@rec-04] [@rec-18]. The first-run experience in that build asks the user to opt in to saving snapshots and to enrol Windows Hello [@rec-04]. Build 26120.2510 (December 6, 2024) extended Insider preview to AMD and Intel Copilot+ PCs. GA across all three silicon vendors landed in the April 25, 2025 Windows Experience Blog announcement [@rec-05], with broad rollout in the May 13, 2025 Patch Tuesday cycle [@rec-21]. The IT-admin manageability surface -- AllowRecallEnablement, DisableAIDataAnalysis, snapshot-retention policy, disk-allocation policy, per-app exclusion list -- is documented in Manage Recall on Microsoft Learn [@rec-08].

flowchart TD G0["Gen 0 (Nov 4, 2019)
SQL Server 2019
Always Encrypted with secure enclaves
(VBS Enclave substrate precedent)"] G1["Gen 1 (May 20, 2024)
Plaintext SQLite
SYSTEM-only filesystem ACL
(Did not ship)"] G2["Gen 2 (June 7, 2024)
Opt-in commitment
Hello-gated commitment
Just-in-time decryption
(Commitment, no architecture)"] G3["Gen 3 (Sept 27, 2024)
VBS Enclave + TPM-sealed
Hello ESS + Purview EDM
(Architecture)"] G4["Gen 4 (Apr 25 - May 13, 2025)
GA on Snapdragon, Intel, AMD
Intune surface matured"] G5["Gen 5 (April 2026)
TotalRecall Reloaded
AIXHost.exe DLL injection
(UI seam disclosed)"] G0 --> G1 G1 -- "Plaintext SQLite + filesystem ACL broken in 4 weeks" --> G2 G2 -- "Commitment needs a mechanism" --> G3 G3 -- "Cryptographic chain holds; shipped to GA" --> G4 G4 -- "UI host outside enclave by design" --> G5

The structural takeaway is this. Composing three primitives Microsoft had already shipped -- VBS Enclaves, TPM 2.0 sealing, and Hello ESS -- plus a fourth (Purview EDM filtering) yielded the September 27 architecture that enforces the three June 7 properties. None of the four primitives is new in 2024; the application of all four to a personal-context store running in the desktop shell is.

If "VBS Enclave + TPM-sealed key + Hello ESS" is the answer, what does the inside of the enclave actually do?

5. Inside the Enclave: VBS as the Load-Bearing Primitive

Microsoft's own September 27 architecture diagram draws five boxes. One of them is labelled untrusted. Here is what the other four do, and why the untrusted one matters.

A Virtualization-based Security (VBS) Enclave is, in Microsoft's own words on the Learn page that defines the primitive, "a software-based trusted execution environment inside the address space of a host application" [@rec-06]. Concretely, it is a sub-region of a normal user-mode (VTL0) process that is promoted to VTL1 by the Secure Kernel. Code inside the enclave can see its own memory and the bytes the host explicitly passes in across the enclave boundary; the host process cannot see plaintext inside the enclave, and neither can the rest of the operating system, including the kernel and any administrator. The primitive requires VBS and HVCI to be enabled, and Windows 11 Build 26100.2314 or later [@rec-06]. The Windows hypervisor partition that hosts VBS divides each running guest into two virtual trust levels: VTL0 (normal user mode and kernel) and VTL1 (Isolated User Mode and the Secure Kernel). The Secure Kernel is a minimal, signed component that runs in VTL1; it is what enforces the isolation guarantee between VTL0 and VTL1. Code in VTL0 cannot read VTL1 memory; the hypervisor enforces this at the second-level page table. The VBS Enclave primitive uses VTL1 as the substrate for the enclave sub-region. Enhanced Sign-in Security, per the canonical Microsoft Learn definition, "provides an additional level of security to biometric data with the use of specialized hardware and software components. Virtualization Based Security (VBS) and Trusted Platform Module 2.0 are used to isolate and protect user's authentication data, and to secure the data communication channel" [@rec-25]. The face-matching algorithm runs in VBS; the sensor-to-algorithm path is an isolated, certificate-authenticated channel. ESS-capable IR cameras and presence sensors are a hardware prerequisite; absent ESS hardware, Recall degrades to a PIN/password fallback.

The five components

Snapshot Service is a Protected Process Light (PPL) that captures the screen at approximately 5-second intervals and feeds the raw frames into the enclave. PPL means the Snapshot Service is signed at a level the rest of user mode cannot inject into. Plaintext frames and per-snapshot keys do not live in the Snapshot Service's address space; they cross into the enclave immediately on capture.
VBS Enclave is the trust boundary. Inside it: OCR over the raw frame; semantic vector embedding for search; sensitive-content filtering via the Microsoft Purview Exact Data Match libraries; per-snapshot key derivation from a TPM-sealed master; AES-256-GCM authenticated encryption of the snapshot and the embedding. Plaintext OCR output never crosses the enclave boundary.
Snapshot Store is the on-disk database of AES-256-GCM-encrypted per-snapshot blobs and encrypted embeddings. No process -- not even the Snapshot Service that wrote the file, not the kernel, not an administrator -- can decrypt the blobs without going back through the enclave with a Hello-authenticated session grant [@rec-03].
Semantic Index is the query path over the encrypted embeddings. A user query traverses the enclave so that the plaintext embedding (and the plaintext OCR text it points at) never leaves the trust boundary.
Recall User Experience (UI) runs outside the enclave. Microsoft's architecture diagram labels it untrusted. The UI receives only data the enclave has authorised for the current session, after Hello ESS, with a timeout, with anti-hammering and rate-limiting on the authorisation window [@rec-03].

AES-256-GCM is the Galois/Counter Mode of operation for AES with a 256-bit key, specified by NIST SP 800-38D [@rec-26]. It is an authenticated encryption with associated data (AEAD) primitive: each ciphertext carries an authentication tag computed over the ciphertext and the associated data, and decryption fails if the tag does not verify. Recall uses AES-256-GCM per snapshot, with a per-snapshot key derived inside the enclave. The published architecture identifies AES-256-GCM as the primitive but does not document the key derivation function or the per-snapshot nonce scheme. Purview EDM is a content-classification primitive from the Microsoft Purview enterprise data-loss-prevention product family. It matches text against high-precision patterns: structured credentials, national-identifier formats (US Social Security Numbers, EU identifier formats), payment card numbers under Luhn checksum. In Recall, the EDM library runs inside the enclave on the OCR output, *before* the per-snapshot encryption step. Matches are excluded from the persistent record; the screenshot of a credit-card form has the card number stripped from the OCR text and (per Weston's framing in SecurityWeek) is treated as a sensitive class that does not enter the snapshot store [@rec-17]. flowchart TD SS["Snapshot Service
PPL, VTL0
captures every ~5s"] ENC["VBS Enclave (VTL1 sub-region)
OCR + embedding
Purview EDM filter
per-snapshot key derivation
AES-256-GCM encrypt"] STORE["Snapshot Store
on-disk
AES-256-GCM ciphertext only"] IDX["Semantic Index
encrypted embeddings"] UI["Recall UI
(VTL0, UNTRUSTED in architecture)"] HELLO["Hello ESS
per-access biometric"] TPM["TPM 2.0
sealed master key"] SS --> ENC TPM --> ENC HELLO --> ENC ENC --> STORE ENC --> IDX STORE --> ENC IDX --> ENC ENC -- "post-auth release" --> UI

The per-snapshot key chain

Davuluri's blog specifies the chain but does not publish either the key derivation function used to expand the TPM-sealed master into a per-snapshot key, or the per-snapshot nonce scheme fed into AES-256-GCM. The pseudocode below reconstructs the structure from the published primitives. Microsoft has not published the literal KDF or nonce scheme; this is the shape of the computation, not the verbatim source.

Reconstructed sketch of the enclave-side write path. Microsoft has published the primitives (TPM 2.0 sealing, Hello ESS gating, VBS Enclave isolation, AES-256-GCM per snapshot, Purview EDM filtering) but has NOT published the literal KDF or nonce scheme. This is a structural reconstruction for teaching purposes.

def enclave_write_snapshot(raw_frame, snapshot_id): # Step 1: in-enclave OCR over the raw screen capture. ocr_text = enclave_ocr(raw_frame)

# Step 2: Purview EDM filter strips known-sensitive patterns
# (credentials, national IDs, PAN) BEFORE persistence.
filtered_text = purview_edm_filter(ocr_text)

# Step 3: semantic embedding for the search index.
embedding = enclave_embed(filtered_text)

# Step 4: derive a per-snapshot key from the TPM-sealed master.
# The master was released into the enclave on Hello ESS authentication.
snapshot_key = kdf(master_key_in_enclave,
                   context=b"recall-snapshot",
                   salt=snapshot_id)

# Step 5: AES-256-GCM authenticated encryption with a fresh nonce.
nonce = derive_nonce(snapshot_id)
aad   = serialize_metadata(snapshot_id, timestamp=now())
ciphertext, tag = aes_256_gcm_encrypt(
    snapshot_key,
    nonce,
    plaintext=concat(raw_frame, filtered_text, embedding),
    aad=aad,
)

# Step 6: persistent write. Nothing plaintext crosses the enclave boundary.
snapshot_store.put(snapshot_id, ciphertext, tag, nonce, aad)

The Hello ESS layer plugs in at step 4: the TPM-sealed master is released into the enclave only on a fresh, ESS-attested authentication, and the release path uses the certificate-authenticated sensor-to-VBS channel described on the Hello ESS Learn page [@rec-25]. Failed authentication trips the standard TPM anti-hammer lockout. PIN fallback is permitted only after Hello has been set up.

sequenceDiagram participant User participant Sensor as Hello ESS sensor participant SK as Secure Kernel (VTL1) participant TPM as TPM 2.0 participant Encl as Recall VBS Enclave (VTL1) participant Store as Snapshot Store User->>Sensor: present face / fingerprint Sensor->>SK: ESS-authenticated biometric attestation SK->>TPM: request key release on attested context TPM->>SK: sealed master key (released to VTL1 only) SK->>Encl: hand master key into enclave Encl->>Encl: derive per-snapshot key, AES-256-GCM encrypt Encl->>Store: ciphertext + AEAD tag + nonce Microsoft's documentation distinguishes two patterns that share the same VTL1 substrate. A *VBS Enclave* is a sub-region of a VTL0 host process that is promoted to VTL1 by the Secure Kernel [@rec-06]. An *[IUM Trustlet](/blog/vbs-trustlets-what-actually-runs-in-the-secure-kernel/)* (like LsaIso, the Credential Guard worker) is a full Isolated User Mode process that runs wholly in VTL1. Both rely on the same hypervisor partition and the same Secure Kernel. The terminology matters because the September 27 architecture blog [@rec-03] and the developer-facing Tech Community explainer [@rec-07] both use *VBS Enclave* throughout for Recall, distinct from LsaIso. The pre-audit framing that called Recall "a new IUM trustlet" was a category mistake; the architecture is a sub-region-of-host-process enclave, not a full trustlet process. Both patterns are governed by the MSRC security boundary policy [@rec-11], which lists VBS as a boundary against the kernel and against administrative users. VBS Enclaves are not new -- SQL Server 2019 *Always Encrypted with secure enclaves* established the substrate roughly five years before Recall (see §4 Generation 0). What Recall contributes is not the substrate but the deployment context: a personal-context store on the desktop shell, with a UX that puts the trust boundary in front of consumers and an adversarial review history (Hagenah, Beaumont, Forshaw) that no SQL Server feature has attracted. flowchart LR subgraph VBS_Encl["VBS Enclave pattern (Recall)"] H["Host process
(VTL0, e.g. Snapshot Service)"] --- E["Enclave sub-region
(VTL1)"] end subgraph IUM["IUM Trustlet pattern (LsaIso / Credential Guard)"] L["Trustlet process
(entirely in VTL1)"] end SK["Secure Kernel (VTL1)"] HV["Hypervisor partition"] VBS_Encl --> SK IUM --> SK SK --> HV

Davuluri's September 27 blog adds two transparency commitments that bear on how much of this architecture an outside reviewer can verify. First, Microsoft's internal MORSE team (Microsoft Offensive Research and Security Engineering) ran a penetration test of the Generation 3 design before disclosure [@rec-03]. Second, an unnamed third-party security vendor performed an independent review. Neither report is public. §9 will return to this transparency gap.

Key idea: The cryptographic boundary in Generation 3 is above the filesystem. A process with full filesystem access reads only AES-256-GCM ciphertext. A kernel-mode caller reads only ciphertext. An administrator reads only ciphertext. The boundary is at the enclave, not at the file. This is qualitatively different from "add encryption to the SQLite file" and is the reason the Generation 3 design closes the four Generation 1 failures rather than merely patching them.

If the cryptographic chain holds against the kernel and against administrators, where can it ship?

6. Where Recall Ships in May 2026

The post-September-2024 Recall is no longer a preview. Here is the silicon it runs on, the policies an IT admin sees, and the exclusion surfaces a user can configure.

Shipping silicon

The chipset matrix is documented on the Microsoft Pluton Learn page [@rec-24] and corroborated by the GA announcement [@rec-05]. The pattern is consistent: every Copilot+ PC carries TPM 2.0 services, but the attachment of those services varies by silicon vendor.

Silicon family	Security processor	Typical TPM attachment
Qualcomm Snapdragon X Elite / X Plus	Pluton (integrated)	TPM 2.0 services delivered by Pluton on-die
Intel Core Ultra 200V (Lunar Lake), Series 3, Series 3	Pluton (integrated, where present) and discrete TPM 2.0	Discrete TPM 2.0 plus Pluton-equivalent integration
AMD Ryzen AI 300 series and Ryzen 6000-9000	AMD Pluton Security Processor	Pluton-equipped SKUs; some retain discrete TPM 2.0

PPL is the Windows process-protection level that gates which processes are permitted to inject code into, debug, or read the memory of a given target process. A PPL process is signed at a specific signer level; only processes signed at an equal-or-higher level can interact with its address space using the privileged debug or memory-access APIs. The Recall *Snapshot Service* is a PPL at a signer level the rest of user mode cannot reach. The *Recall UI* (covered in §8) is not a PPL, and that distinction is the architectural seam Hagenah's April 2026 disclosure exploits.

The Pluton-versus-discrete-TPM trade-off is small but real. A Pluton-integrated TPM has no off-die bus carrying the security-processor traffic that an attacker can sniff with a logic analyser; the integration is in-package. A discrete TPM has a documented bus-sniffing attack surface that the Secured-core PC requirement set (HVCI, System Guard Secure Launch, Kernel DMA Protection) is designed to mitigate but does not eliminate.The bus-sniffing attack is not specific to Recall; it is a general TPM-attachment concern that applies to BitLocker, Credential Guard, and any other TPM-sealed key. Recall inherits both the threat and the mitigation set from the platform.

For most Copilot+ PCs in 2026, the practical difference is small. The architectural correctness of the September 27 design does not depend on the choice.

The management surface

The IT-admin management surface is documented in Manage Recall on Microsoft Learn [@rec-08]. The defaults differ between consumer and managed devices: on a managed device, "Recall is disabled and removed" by default, and an explicit Intune policy is required to allow enrolment. The relevant Intune Settings Catalog entries are:

AllowRecallEnablement -- the explicit consent gate for any organisation that wants Recall to be available on its managed fleet. Threat model addressed: unintended consumer-default opt-in on managed devices; without this policy explicitly set to "allowed," the Manage Recall page's managed-device default ("disabled and removed") stands.
DisableAIDataAnalysis -- the Group Policy gating surface for Copilot+ AI features. Threat model addressed: organisations that want a single switch to keep all on-device AI processing (Recall, Click to Do, future shell features) off the fleet, rather than enumerating each feature individually.
Snapshot-retention and storage-allocation policies -- data-minimisation controls for the per-device snapshot corpus. Threat model addressed: bounding the maximum size of any single exfiltration window in the event a future UI-host weakness is found; fewer snapshots and shorter retention reduce the corpus exposed to a successful post-authentication extraction.
Per-app exclusion list -- per-window snapshot exclusion for applications the operator designates. Threat model addressed: high-value secrets surfaced by the password manager, the corporate VPN client, and similar sensitive UIs that should never enter the snapshot corpus regardless of how strong the storage encryption is.

Microsoft Purview Endpoint DLP adds a parallel policy surface for window-level snapshot exclusion of any application handling regulated data [@rec-08]. Group Policy parity exists for the same surfaces, for organisations that have not yet adopted Intune.Intune management of Recall was not a 2026 debut. The Manage Recall documentation was published alongside the Insider preview in late 2024 and matured through the April-May 2025 GA cycle. The 2026 work is stabilisation, not introduction.

User-facing surfaces

End users encounter Recall through a small number of touchpoints documented in the Insider preview blog [@rec-04] and the developer integration page [@rec-09]. The keyboard shortcut Win+J launches the Recall UI. The Out-Of-Box Experience asks the user to opt in to saving snapshots and to enrol Windows Hello before any capture begins. The per-app exclusion list is reachable from Settings. Storage allocation defaults are configurable, with a documented audit path through the Manage Recall policy reference.

Note: On a managed-device pilot, deploy the AllowRecallEnablement Intune policy before the OOBE flow begins on the device. If the policy lands after the user has completed OOBE, you leave a small window in which the user could opt in under the consumer default. Pre-deploying the policy makes the managed-device default (Recall disabled) authoritative from first boot.

Recall is the on-device-only Copilot+ feature, on a defined silicon set, with a defined management surface. Who else ships in this space, and how do their architectures compare?

7. Competing Approaches Under the Same UX Label

Three other architectures ship a search-your-past-screen or near-adjacent UX in the 2024-2026 window. Each made a different choice about where the trust boundary lives.

Rewind.ai (macOS, 2022 to present)

Rewind.ai is the closest architectural predecessor to the May 2024 Recall design. It captures the user's macOS screen, OCRs the captures, and stores them locally in an SQLCipher-encrypted SQLite database, with the database key held in the macOS Keychain [@rec-28] [@rec-29] [@rec-30]. There is no per-query biometric prompt; there is no Secure Enclave gating on each access. Architecturally, Rewind relies on macOS sandboxing and FileVault for the surrounding protection.The vendor security page at rewind.ai/security resolves to a domain-parking template as of May 2026, so this architectural description is INFERRED_DETAIL drawn from the Nudge Security third-party profile [@rec-28] and the SQLCipher canonical pages [@rec-29] [@rec-30] rather than a vendor-published spec.

SQLCipher uses AES-256-CBC per page with a per-page random IV and HMAC-SHA512, deriving the key from a passphrase via PBKDF2-HMAC-SHA512 with 256,000 default iterations [@rec-30]. That is reasonable file-encryption; it is not per-access authentication. A same-user process that can read the SQLCipher key out of Keychain has plaintext access to every screen capture the user has ever taken -- structurally the same condition that broke the May 2024 Recall design, on a different operating system with a different sandbox model.

Apple Intelligence Personal Context + Private Cloud Compute (2024 to present)

Apple's Personal Context personalisation is not a search-your-past-screen product. It is structured-app-data personalisation: messages, mail, calendar, photo metadata, and similar surfaces. The on-device tier runs in the Apple Silicon Secure Enclave. The off-device tier -- Private Cloud Compute -- carries a binary-transparency-style commitment that the cloud nodes process personal data only inside a hardened OS image whose source code Apple publishes for outside review [@rec-27]. The PCC architecture is included in this comparison not because it is a Recall analogue (it isn't), but because it shows what Apple has chosen to ship at the adjacent problem class: structured data personalisation, not screen-history.

Consumer cloud-capture devices (Limitless, Plaud, and similar)

Consumer cloud-capture devices invert the trust model. The capture happens on a dedicated wearable or microphone; the processing happens on a vendor's cloud tier; the storage lives in the vendor's account model with end-to-end encrypted upload and vendor-side AES-256-GCM at rest. This is architecturally the opposite of Recall: on-device-only is replaced by on-vendor-cloud, and the trust boundary is at the vendor's perimeter rather than at the user's silicon. The internals of any specific vendor's stack are not in the scope-mandated source set; the entry exists to establish the existence of the cloud-tier alternative, not to certify any specific vendor's claim.

The eight-dimension matrix

Architecture	On-device only	Hardware-rooted master	TEE-isolated compute	Per-access biometric	Pre-persistence filter	TEE-isolated UI plane	KDF/nonce documented	CVE record
Recall Gen 1 (May 2024, did not ship)	Yes	No	No	No	No	No	N/A	Pre-release
Recall Gen 3+4 (Sept 2024 - May 2026)	Yes	Yes (TPM 2.0, Pluton where available)	Yes (VBS Enclave)	Yes (Hello ESS)	Yes (Purview EDM)	No (UI explicitly untrusted)	Partial	No CVE through May 2026
Rewind.ai (macOS)	Yes	Keychain-rooted	Limited	No	No	No	N/A	N/A
Apple Personal Context + PCC	Hybrid	Yes (Secure Enclave)	Yes (Secure Enclave / PCC)	Yes	Apple-managed	Apple-managed	Partial	N/A
Consumer cloud-capture	No	Vendor cloud	Vendor cloud	Vendor flow	Vendor flow	Vendor flow	Not public	N/A
SQL Server 2019 AE w/ enclaves	Server-side	Yes (TPM-attested)	Yes (VBS Enclave)	N/A	N/A	N/A	Yes (documented)	Patched as needed

Recall Generation 3+4 is the only design in the surveyed set that checks five of the six "ideal" properties: on-device-only data flow, hardware-rooted master key, TEE-isolated sensitive compute, per-access biometric authentication, and pre-persistence sensitive-content filtering. The sixth ideal property -- TEE-isolated plaintext delivery to the UI plane -- is the architectural seam §8 explores.

flowchart LR A["On-device only
YES"] B["Hardware-rooted master
YES"] C["TEE-isolated compute
YES"] D["Per-access biometric
YES"] E["Pre-persistence filter
YES"] F["TEE-isolated UI plane
NO -- UI is explicitly untrusted"] A --> G((Recall Gen 3+4)) B --> G C --> G D --> G E --> G F -. "the seam" .-> G

Five of six properties. What does the missing sixth cost?

8. What the VBS Enclave Model Cannot Do

Microsoft's September 27, 2024 architecture is the strongest design Windows has shipped for an on-device personal-context store. It is not the strongest design that is theoretically possible -- and it is honest about which classes of attack it does not address. Here are five.

8.1 The UI host runs outside the enclave

This is the load-bearing limit. Davuluri's blog states it directly: "Recall components such as the Recall UI operate outside the VBS Enclaves and are untrusted in this architecture" [@rec-03]. The architecture diagram labels the UI box untrusted. The blog says this in September 2024, eighteen months before anyone publishes an exploit for it. The seam is documented.

In April 2026, Alexander Hagenah released TotalRecall Reloaded against the Generation 3+4 design [@rec-12]. The tool has two files: totalrecall.exe, an injector, and totalrecall_payload.dll, the payload. The injector locates the AIXHost.exe UI host via CreateToolhelp32Snapshot, allocates memory in the target with VirtualAllocEx, writes the path of the payload DLL with WriteProcessMemory, and spawns a remote thread pointing at LoadLibraryW. Once loaded, the payload reads decrypted Recall data out of the AIXHost.exe address space, where the enclave has just delivered it after the user's legitimate Hello authentication [@rec-12] [@rec-22].

Hagenah's verbatim characterisation, from the README: "No admin required. Standard user. No kernel exploit. No crypto bypass. Just COM calls." [@rec-12]. The tool ships three execution modes -- --launch (start AIXHost.exe and inject), --stealth (operate without UI signals), and --wait (attach to a future legitimate AIXHost.exe instance) [@rec-12]. The --stealth mode patches a function called DiscardDataAccess inside a DLL referred to as Baker.dll, which would otherwise discard the decrypted snapshot data on UI dismissal.The Baker.dll DiscardDataAccess patch is a reverse-engineering detail rather than a load-bearing architectural point, but it illustrates the surface area available to an injected payload inside the UI host's address space. Anything the UI process can do to a memory region, an injected DLL can do too.

The vault is solid. The delivery truck is not. -- Alexander Hagenah, TotalRecall Reloaded README, April 2026 [@rec-12]

The disclosure timeline is in the public record. Hagenah submitted a full disclosure to the Microsoft Security Response Center on March 6, 2026, including source code and build instructions [@rec-23]. Microsoft opened a case nine days later and closed it on April 3, 2026 with the determination that the behaviour "operates within the current, documented security design of Recall" [@rec-23]. The public release of the tool followed.

Note: Per iTnews's coverage of the disclosure, Microsoft's MSRC response after a month of review was that the demonstrated behaviour "operates within the current, documented security design of Recall" [@rec-23]. The phrasing is precise. The September 27, 2024 architecture blog [@rec-03] publishes that the UI host is outside the enclave; the MSRC servicing criteria [@rec-11] publish that same-user post-authentication code is not a security boundary. Hagenah demonstrated what "untrusted in this architecture" means in practice; MSRC confirmed the demonstration is consistent with the published model. Reasonable readers may disagree on whether the published model is the right model; the present article does not take a side and leaves that judgment to the reader.

sequenceDiagram participant User participant Inj as totalrecall.exe (standard user) participant AIX as AIXHost.exe (UI host, VTL0) participant Hello as Hello ESS / VBS Enclave participant Pay as totalrecall_payload.dll User->>AIX: Win+J launches Recall UI AIX->>Hello: request snapshot data User->>Hello: present biometric Hello->>AIX: deliver decrypted snapshot to address space Inj->>AIX: CreateToolhelp32Snapshot, locate process Inj->>AIX: VirtualAllocEx, write payload path Inj->>AIX: WriteProcessMemory with payload DLL path Inj->>AIX: CreateRemoteThread targeting LoadLibraryW AIX->>Pay: LoadLibraryW loads the payload DLL Pay->>AIX: read decrypted data from same address space Pay-->>Inj: exfiltrate plaintext snapshots AppContainer is the Windows process-isolation primitive that restricts a process's access to filesystem, registry, network, and inter-process surfaces to an explicit capability list declared at process launch. Universal Windows Platform applications and modern packaged applications launch inside an AppContainer by default; the kernel enforces the capability set on every access to a securable object. A Generation 6 Recall UI launched inside an AppContainer would not be able to load arbitrary user-supplied DLLs into its address space, because the AppContainer's capability set would not include the broad inter-process token-and-memory-access capabilities that Hagenah's injector relies on (`OpenProcess` for `PROCESS_VM_WRITE` and `PROCESS_CREATE_THREAD` against an out-of-container target are gated by the AppContainer's integrity level and capability set).

Key idea: The Generation 3 cryptographic chain holds -- as §5 established, a process with full filesystem access, a kernel-mode caller, and an administrator all read only ciphertext. The architectural seam is at the plaintext-delivery boundary -- the UI host, by Microsoft's own published architecture, is explicitly outside the enclave. Closing this seam would require a Generation 6 design that combines a high-signer Protected Process Light for the UI host, AppContainer with capability-restricted code-loading, and WDAC-enforced code integrity for the UI process tree. No such Microsoft commitment exists as of May 2026.

The deeper observation is one of recurrence. The Generation 1 failure was "same-user code is in the user's trust boundary, and the architecture relied on a filesystem ACL rather than per-access authentication." The Generation 5 disclosure is "same-user code is in the user's trust boundary, and the architecture relied on the UI host being a normal user-mode process." Different layer; same threat-model limit, restated.

8.2 Rubber-hose against an authenticated user

No per-access authentication scheme can defeat a coerced legitimate user. If the user is physically compelled to authenticate with Hello and then operate the UI, the architecture authorises a release into the UI plane that the coercer can read off the screen, off a screenshot, or off a redirected output device. The September 27 design explicitly does not address this threat class, and no plausible Generation N design within the same UX category can. The control here is procedural -- duress codes, panic gestures, or a separate "do not authorise" PIN -- rather than cryptographic.

8.3 NPU and GPU side channels

The VBS Enclave is the trust boundary for CPU-side computation. The Neural Processing Unit that drives Recall's semantic embedding is not in the enclave; neither is the integrated GPU. Side-channel attacks on AI accelerator memory hierarchies are unstudied territory in the published Copilot+ PC literature as of May 2026. There is no public proof of a Recall-specific NPU side channel; there is also no published assurance that one does not exist. This is "unknown unknown" territory, which is honest to state and dangerous to pretend has been ruled out.

8.4 OCR model integrity

The local OCR model loads from disk; the code inside the enclave reads and uses the weights. Microsoft has not publicly committed to a signed-weights verification step for the OCR model at enclave load. An attacker with administrator access could in principle substitute poisoned weights -- weights that deliberately mis-OCR specific credential formats so that the Purview EDM filter does not catch them, thereby smuggling sensitive plaintext through the filter and into the persistent store. Admin compromise is an out-of-scope class per the MSRC servicing criteria [@rec-11], but the OCR-integrity story would be more legible if the enclave verified a signature on the model file at load time.

8.5 Substrate compromise

A Secure Boot bypass, a Secure Kernel vulnerability, or a hypervisor escape takes down VBS itself, not Recall specifically. Saar Amar and Daniel King's Black Hat USA 2020 Breaking VSM by Attacking SecureKernel [@rec-32] remains the canonical historical treatment of the SK attack surface; the substrate has been hardened in response and is not proven secure. Recall inherits whatever the substrate's residual risk is in any given month. Patching is by way of the normal Windows servicing cadence.

Microsoft, by its own published servicing criteria, accepts each of these limits as architectural choices, not defects. What does the public record not tell us, that an independent reviewer would need to know?

9. Where the Public Record Runs Out

Five things the September 27 blog does not say, and one structural question it raises that the next five years of Windows shell features will answer.

9.1 The KDF and nonce scheme are not public

Davuluri's blog [@rec-03] specifies that each snapshot is encrypted with a per-snapshot key derived from a TPM-sealed master, and that the AEAD primitive is AES-256-GCM. It does not publish the key derivation function, the per-snapshot nonce derivation, or the associated-data inputs to GCM. The §5 pseudocode is a structural reconstruction; the literal source is in aeon.dll (or equivalent) and is not documented. The practical consequence is that third-party formal cryptographic review of the per-snapshot construction is foreclosed. MORSE's internal penetration test and the unnamed third-party security vendor's review [@rec-03] were performed against the literal implementation; both reports are non-public.

9.2 On-device OCR model integrity

The OCR model loads from disk and runs inside the enclave. There is no public Microsoft commitment that the enclave verifies a signature on the model weights at load time. The §8 OCR-integrity attack -- admin substitutes poisoned weights to defeat Purview EDM -- is bounded by the admin-is-out-of-scope MSRC policy [@rec-11], but a verified-load step would tighten the story.

9.3 InPrivate / password-field pause signal forgery

Davuluri's blog mentions that Recall pauses snapshot capture during InPrivate browsing and in password fields [@rec-03]. The signalling API by which the browser or the credential UI tells the Snapshot Service to pause is not fully documented. Whether a malicious browser extension can suppress legitimate pauses (forcing a snapshot of an InPrivate page) or spuriously trigger them (denial-of-service against legitimate snapshot capture) is unstudied in the public record.

9.4 The authorisation-window timeout is not exposed by policy

The Intune ADMX template documented in Manage Recall [@rec-08] exposes AllowRecallEnablement, DisableAIDataAnalysis, snapshot retention, storage allocation, and the per-app exclusion list. It does not, as of May 2026, expose the authorisation-window timeout as a configurable policy. An enterprise that wants to require re-authentication every N minutes during a Recall session does not have a Microsoft-supported knob for it.

9.5 The pattern question

This is the structural one. Microsoft has now shipped a VBS-enclave-backed feature in the desktop shell and has open-sourced the developer-facing SDK at microsoft/VbsEnclaveTooling [@rec-31]. The repository ships a code generator and a NuGet SDK, requires Windows 11 24H2 Build 26100.3916 or later, and supports C++17 and C++20 in the host with C++20 and Rust 1.88+ in the enclave [@rec-31].The SDK lowers the barrier to building a VBS Enclave dramatically. A developer who wants to put a small piece of sensitive computation (credential handling, secrets storage, on-device LLM context) inside an enclave no longer has to reverse-engineer Recall's implementation; they can write against a documented API.

The forward question is whether other desktop-shell features adopt the same pattern. Encrypted clipboard history, encrypted recent-files, on-device LLM context windows, the password manager Edge currently keeps in user-mode RAM -- each is a candidate. Hagenah's AIXHost.exe class suggests the pattern, naively applied, repeats the same UI-host weakness for every consumer. A VBS-Enclave-backed clipboard with a normal user-mode UI host inherits the same seam.

Microsoft's internal Offensive Research and Security Engineering team ran a penetration test against the Generation 3 architecture before the September 27 announcement [@rec-03]. An unnamed third-party security vendor performed an independent review. Neither report is public. The September 27 blog cites their existence to establish that adversarial review happened; it does not cite findings, methodology, or scope. This is not a criticism so much as a public-trust framing: the residual confidence a reader can place in the architecture is gated on the credibility of two reports they cannot read. Hagenah's April 2026 disclosure is the first publicly verifiable adversarial review of the UI surface; it found exactly what the architecture diagram already warned about. That coincidence is reassuring about the *honesty* of the published model; it does not by itself certify any property the published model does not cover.

Microsoft is not going to fix the AIXHost.exe class in 2026. What can a Copilot+ PC operator actually do with the shipping Recall today?

10. Deploying Recall Safely

Six knobs, in order. Setting them in this order turns the September 2024 architecture into a deployable enterprise posture.

Procurement. Pluton-or-discrete-TPM-2.0 hardware plus ESS-capable biometric sensor (IR camera plus presence sensor, or equivalent). Without ESS-capable biometrics, the Hello-gated architecture degrades to a PIN or password fallback, which is weaker than the architecture intends [@rec-25] [@rec-24].
Policy enablement. Deploy the Intune AllowRecallEnablement policy explicitly. The Microsoft Learn Manage Recall page states that "By default, Recall is disabled and removed on managed devices" [@rec-08]; the consumer OOBE default is opt-in but applies only to unmanaged devices. The managed-device default is authoritative once policy is in force, so deploy first, then provision.
Data minimisation. Deploy the snapshot-retention and disk-allocation policies from the Manage Recall policy reference [@rec-08]. Fewer snapshots and shorter retention reduce the maximum size of any single exfiltration window.
Sensitive-app exclusion. Enable the Microsoft Purview Endpoint DLP integration for window-level snapshot exclusion of any application handling regulated data (PHI, PCI, PII), and populate the per-app exclusion list with the local password manager, the corporate VPN client, and any other surfaces with high-value secrets [@rec-08]. This is the operator-controlled complement to the in-enclave Purview EDM content filter.
Defence-in-depth for the AIXHost.exe class. Deploy Smart App Control plus a Windows Defender Application Control (WDAC) policy to deny untrusted DLL loading on the device. DLL injection requires a process to load the payload; a WDAC policy with User-Mode Code Integrity (UMCI) enabled blocks the load of any DLL -- including Hagenah's payload -- that does not match a signer or hash allow-list in the policy. The LoadLibraryW call still executes; the load fails because the code-integrity check rejects the unsigned payload. None of these are in the Recall architecture; they are platform-level controls the operator must enable.
Audit and monitoring. Existing InfoStealer behaviour rules in Microsoft Defender for Endpoint will flag bulk reads of the Recall directory as high-confidence indicators. The point worth being precise about here: these are the pre-existing InfoStealer behaviour rules, not a Recall-specific signature; they fire on the access pattern (rapid enumeration of a personal-data directory) rather than on the file format. Configure Defender and your SIEM to alert on the directory.

Note: A tempting deployment "fix" is to disable VBS entirely as a way to prevent the Snapshot Service from running. This is a net security regression. VBS is the substrate for Credential Guard, HVCI, the Hello ESS algorithm isolation, and the Recall enclave itself. Disabling VBS eliminates the protection the Generation 3 architecture provides while leaving the desktop attack surface open. If the goal is to prevent Recall from running, use AllowRecallEnablement or DisableAIDataAnalysis instead.

The list of things not to bother doing: manual AES-256-GCM on the SQLite file (the enclave already does this); manual scrubbing of the Recall directory on a schedule (the retention policy already does this); writing a custom Defender signature for the Recall directory (existing InfoStealer behaviour rules already cover the access pattern); relying on the OOBE opt-in default for an enterprise pilot (that default applies to unmanaged devices only).

{` // Conceptual audit. The real script needs PowerShell on Windows; // this is the logic an operator's audit cmdlet would implement.

type DevicePosture = { pluton_present: boolean; tpm_2_0_present: boolean; hello_ess_enrolled: boolean; smart_app_control: "on" | "off" | "evaluation"; wdac_policy: "enforced" | "audit" | "none"; allow_recall_enablement: "allowed" | "disabled" | "not-set"; retention_days: number; defender_directory_alert: boolean; };

function auditRecallPosture(d: DevicePosture): string[] { const findings: string[] = [];

if (!d.tpm_2_0_present) findings.push("FAIL: no TPM 2.0; sealing path unavailable."); if (!d.pluton_present) findings.push("INFO: discrete TPM 2.0; bus-sniffing residual risk."); if (!d.hello_ess_enrolled) findings.push("FAIL: Hello ESS not enrolled; per-access biometric degraded to PIN."); if (d.smart_app_control === "off") findings.push("WARN: Smart App Control off; AIXHost.exe injection class wide open."); if (d.wdac_policy !== "enforced") findings.push("WARN: WDAC not in enforcement mode; LoadLibraryW gating absent."); if (d.allow_recall_enablement === "not-set") findings.push("WARN: AllowRecallEnablement not set; OOBE default may apply."); if (d.retention_days > 30) findings.push("INFO: retention >30 days; consider tightening for high-risk roles."); if (!d.defender_directory_alert) findings.push("WARN: Defender directory-enumeration alert not configured.");

return findings.length ? findings : ["OK: posture matches Gen 3+4 deployment guide."]; } `}

If you have gotten this far, you have the questions a reader walks in with answered. Here are the questions a reader walks out with.

11. Frequently Asked Questions

No. The September 27, 2024 architecture blog [@rec-03] and the IT-admin *Manage Recall* documentation [@rec-08] both state that snapshots, OCR text, and the semantic index are processed and stored entirely on-device. The Microsoft Diagnostic Data telemetry pipeline does not carry snapshot data. This is the one property the original May 2024 design got right, and it survived the re-architecture intact. No. Session-replay tools record interactive sessions for product analytics and ship the recording to a vendor cloud. Screen recording for accessibility (e.g., screen readers, magnification) operates on the live frame and does not persist a corpus. Compliance archiving (e.g., legal-hold mailbox archives) is a server-side, vendor-managed retention surface. Recall is on-device, personal, search-indexed over OCR text and embeddings, and gated on Hello biometric. The architectural lineage and the threat model differ for each. Yes, on a discrete TPM 2.0 SKU. The Microsoft Pluton chipset list [@rec-24] enumerates the Pluton-equipped silicon; Copilot+ PCs that are not on that list satisfy the Recall hardware requirements via a discrete TPM 2.0. The trade-off is the bus-sniffing surface discussed in §6: a Pluton-integrated TPM has no off-die bus to sniff for the security-processor traffic. The architectural correctness of the September 27 design does not depend on the choice; only the bus-sniffing residual risk does. Different threat models. BitLocker's threat model is offline disk theft: an adversary with the powered-off laptop in hand. The May 2024 Recall design borrowed BitLocker's "data at rest is encrypted" framing without absorbing that the dominant Recall adversary is a logged-on session adversary (an InfoStealer running as the user), against which BitLocker has nothing to say. Microsoft did not delay BitLocker because the original 2007 BitLocker matched the threat model it claimed to address; they delayed Recall because the original 2024 Recall did not. No, as of May 2026. The Hagenah AIXHost.exe class disclosed in April 2026 [@rec-12] [@rec-22] [@rec-23] was reported to MSRC on March 6, 2026; Microsoft closed the case on April 3, 2026 with the determination that the behaviour "operates within the current, documented security design of Recall" [@rec-23]. That determination is consistent with the published MSRC servicing criteria [@rec-11], which do not list same-user post-authentication as a security boundary. No CVE was assigned. No. The on-device NPU is required for the semantic-embedding step, and the Copilot+ hardware baseline (Pluton or discrete TPM 2.0 plus an NPU at a minimum throughput tier plus an ESS-capable biometric sensor) is a hard prerequisite [@rec-09] [@rec-04]. There is no CPU-only fallback for the embedding pipeline, and the on-device-only data flow forecloses a cloud fallback by design. No. As covered in §5, a VBS Enclave is a sub-region of a VTL0 host process that is promoted to VTL1 by the Secure Kernel [@rec-06]. An IUM trustlet (e.g., LsaIso, which backs Credential Guard) is a full Isolated User Mode process that runs wholly in VTL1. Both rely on the same hypervisor partition and Secure Kernel substrate, and the MSRC servicing criteria treat both under the VBS boundary policy [@rec-11], but the patterns are architecturally distinct. Microsoft's own documentation uses "VBS Enclave" terminology for the Recall case throughout [@rec-03] [@rec-06] [@rec-07]. Click to Do is a separate Copilot+ feature with a separate but partially overlapping privacy story; the November 22, 2024 Insider blog [@rec-04] bundles the two opt-in flows in the same first-run experience. Click to Do operates on the *current* screen rather than a history of past screens, and it does not maintain a persistent corpus. The bundling is a UX choice, not an architectural sharing of the snapshot store. No, even as administrator. The Snapshot Store holds AES-256-GCM ciphertext; the per-snapshot keys are derivable only inside the enclave; the master is sealed by the TPM and released to the enclave only on a fresh Hello attestation. An administrator with full filesystem access to the snapshot directory reads ciphertext [@rec-03] [@rec-11]. The Hagenah AIXHost.exe class [@rec-12] is *post-authentication* extraction from the UI host's address space, not an administrator-side read of the encrypted data. The cryptographic chain holds against admin; the seam is at the UI plane.

The arc this article walks -- a vendor ships, an audit lands, the vendor re-architects, an audit finds a seam, the vendor confirms the seam was in the published model -- is what the security feedback loop looks like when it works as designed. Naming each phase is what lets a reader recognise the same loop the next time a major Windows feature ships. The architecture diagram that ships with the next personal-data feature out of Redmond will, if the pattern holds, label its UI host the way Davuluri's labels the Recall UI: as untrusted, in writing, in advance. The reader who has walked this far should know to look for that label, and to evaluate the feature on whether the architecture names its seam rather than hiding it.

On a Copilot+ PC, the following PowerShell cmdlets (run as administrator) give you the device-side view: `Get-Tpm` for TPM 2.0 presence and Pluton attestation; `Get-CimInstance -Namespace root\cimv2\Security\MicrosoftTpm -ClassName Win32_Tpm` for detailed TPM state; `Get-LocalUser | Where-Object Enabled` plus the Hello enrolment surface in Settings for Hello ESS state; `Get-MpComputerStatus` for Defender status; and the Intune device-status portal for `AllowRecallEnablement` and related policies [@rec-08]. The §10 audit-script logic above describes the cross-check structure.

Apple Secure Enclave vs Microsoft Pluton: Two Roads to Hardware Root of Trust

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

**Apple Secure Enclave and Microsoft Pluton solve the same problem -- keeping your keys, biometrics, and disk-encryption secrets safe even when the operating system is compromised -- by way of two different silicon strategies.** Apple gives the SEP its own physical CPU core, its own L4-derived microkernel (sepOS), and a mailbox API that no app can bypass. Microsoft drops Pluton onto the SoC die as a TPM 2.0-compatible subsystem patched through Windows Update. The differences shape everything downstream: who can patch the firmware, what attacks remain in scope, and which APIs developers actually call. This article walks through the architectures, the API surfaces, the published attacks (checkm8, LPC sniffing, faulTPM), and the cross-platform standards (FIDO2/WebAuthn) that paper over the divide.

1. The bus that taught everyone a lesson

In 2021, a researcher at Pulse Security wired a forty-dollar FPGA to the LPC bus of a Microsoft Surface Pro 3 and a Lenovo laptop, captured a handful of bytes as the machines powered on, and pulled the BitLocker Volume Master Key out of the air. Then they decrypted the drives. They wrote the whole thing up, with photos of the soldering and an open-source sniffer named lpc_sniffer_tpm (Pulse Security: Sniff, there leaks my BitLocker key [@pulse-tpm-sniff]).

The hardware was working exactly as designed.

That is what makes the story interesting. The Trusted Platform Module released the disk-encryption key the moment the boot configuration matched its sealed policy. It then handed the key, in cleartext, to the CPU over a physical wire on the motherboard. Anyone who could touch that wire could read the key. The chip, the spec, the OS -- all of them did precisely what the standard required. The threat model just never accounted for somebody putting probes on a laptop.

This is the problem hardware-rooted security has spent twenty years trying to dig itself out of. If you trust software, malware wins. If you trust software-plus-discrete-TPM, the bus wins. If you trust software-plus-firmware-TPM, the host operating system's privileged-mode bugs win. Every layer you add closes one class of attack and opens another.

Key idea: Hardware roots of trust exist because no purely software-defined boundary can survive an attacker who runs code at the same privilege level you do. The only way out is to put the secrets somewhere your main CPU literally cannot read.

Apple and Microsoft both reached the same conclusion roughly a decade apart, and built almost opposite answers. Apple shipped the Secure Enclave Processor (SEP) with the A7 chip in the iPhone 5s in September 2013 [@apple-sep-chapter] -- a dedicated ARM core inside the application SoC, running its own microkernel, talking to the rest of the phone through a hardware mailbox. Microsoft announced Pluton in November 2020 [@ms-pluton-announce], but had been shipping Pluton-class silicon since the original Xbox One in 2013 [@ms-pluton-learn]; the Windows version is an on-die security subsystem that pretends to be a TPM 2.0 chip and accepts firmware updates over Windows Update.

Both companies looked at the same threat -- a curious adversary with a screwdriver, an OS-level rootkit, or a $40 logic analyzer -- and decided the answer was to move the keys off the bus. They just disagreed about where to put them.

A piece of silicon that the rest of a system anchors its security claims to. Keys generated inside the RoT never leave; measurements taken by the RoT are signed by it; software running outside the RoT cannot rewrite the RoT's behavior. The "root" is the part the rest of the trust chain reduces down to. A cryptoprocessor specified by the Trusted Computing Group. TPM 2.0 -- the current version, published in 2014 and revised since [@tcg-tpm2] -- defines Platform Configuration Registers (PCRs), an Endorsement Key burned at manufacture, key creation and sealing primitives, and the `TPM2_Quote` command for remote attestation. A TPM can be discrete (its own chip), firmware (running inside another security subsystem), or virtual.

This article is the comparison nobody quite writes, partly because both vendors prefer to talk about themselves and partly because the technologies look superficially similar. They are not. The architectures differ. The threat models differ. The patch channels differ. The developer APIs differ enough that the same security goal -- "store this key so nothing but the user's biometric can use it" -- produces wildly different code on each side. By the end of this you should know which one is in your device, why it is there, what it actually defends against, and where the academic literature has already poked holes.

flowchart LR subgraph Discrete["Discrete TPM (sniffable bus)"] CPU1[CPU] -- LPC/SPI --> TPM[Discrete TPM chip] end subgraph SEP["Apple SEP (separate core)"] AP[Application Processor] -- mailbox --> SEPCore[SEP core + sepOS] end subgraph Pluton["Microsoft Pluton (on-die subsystem)"] CPU2[CPU] -- on-die fabric --> PlutonSub[Pluton subsystem] end

The journey from "trust the OS" to "trust the silicon that even the OS cannot read" is the story of the last fifteen years of platform security. The Surface Pro 3 attack is what happens when you do half of it. Apple's and Microsoft's answers are what it looks like when you do all of it -- in two opposite ways.

2. Apple's answer: a small computer inside your phone

The Apple Secure Enclave Processor is a separate physical CPU core, on the same die as the application processor, with its own memory, its own boot ROM, its own operating system, and its own random number generator. Apple's own framing in the Platform Security Guide [@apple-sep-chapter] is that the SEP "provides the foundation for the secure generation and storage of the keys necessary for encrypting data at rest." That is what it does. How it does it is what is interesting.

2.1 What sits on the die

Inside an A-series or M-series SoC, the SEP is a distinct cluster. According to Apple's published architecture, it includes (Apple Platform Security: Secure Enclave [@apple-sep-chapter]):

A dedicated processor core (not a SMT thread, not a shared core) running at a lower clock than the application cores.
A Memory Protection Engine (MPE) that encrypts every cache line going to or from SEP-owned DRAM.
A True Random Number Generator (TRNG) seeded by silicon noise.
A hardware AES engine and a Public Key Accelerator (PKA) for ECC and RSA.
A boot ROM masked in silicon at fabrication time.
From A13 onward, a relationship with an external Secure Storage Component (SSC) [@apple-ssc] that provides monotonic counters and replay-protected non-volatile storage.

The lower clock speed is not an accident. Apple explicitly notes that the SEP "is designed to operate efficiently at a lower clock speed that helps to protect it against clock and power attacks" (Apple Platform Security [@apple-sep-chapter]). Side-channel-resistance starts at the timing budget.

Apple's dedicated security coprocessor, introduced in the A7 SoC in September 2013 [@apple-a-series]. Each Apple-designed SoC since contains one SEP. It runs `sepOS`, an Apple customization of the L4 microkernel, and exposes its services only via a tightly defined mailbox interface from the application processor. The operating system the SEP runs. Apple describes it as "an Apple-customized version of the L4 microkernel" (Apple Platform Security: Secure Enclave [@apple-sep-chapter]). It is independent of iOS, iPadOS, or macOS, ships in the same firmware bundle as those operating systems, and is signed by Apple. The microkernel design constrains the trusted computing base and forces cross-service communication through IPC.

2.2 The boot chain, in order

When you press the power button, two CPUs come up at once. The application processor begins executing its boot ROM, and the SEP begins executing its own. They are independent boot processes that meet later, after both sides have verified their own firmware.

sequenceDiagram participant AP as Application Processor participant SEP as Secure Enclave Processor participant ROM as SEP Boot ROM (mask) participant Flash as System Storage Note over AP,SEP: Reset AP->>AP: Execute AP Boot ROM SEP->>ROM: Execute SEP Boot ROM ROM->>Flash: Load sepOS image ROM->>ROM: Verify signature against Apple root key alt Signature valid ROM->>SEP: Launch sepOS SEP->>SEP: Initialize MPE, derive UID-tangled keys else Signature invalid ROM->>SEP: Halt end AP-->>SEP: Mailbox handshake SEP-->>AP: Available services advertised

The SEP boot ROM is mask ROM. That phrase carries weight. It means the bits were etched into the silicon at fabrication and cannot be rewritten. Apple cannot patch the SEP boot ROM with a software update, even if Apple wants to. This is a feature -- nobody else can patch it either -- and a liability. We will return to it when we discuss checkm8.

After the SEP boot ROM verifies and launches sepOS, the SEP holds two values fused into the silicon at manufacture: a Unique ID (UID) and a Group ID (GID). The UID is per-device. The GID is per-product-family. Both are kept inside the SEP and never appear outside it. Keys derived from the UID are tangled to the specific piece of silicon; you cannot lift the wrapped key, move it to another phone, and unwrap it. The chip is physically the wrap-and-unwrap oracle.The UID is also why factory-reset really does erase your data. The data-protection key hierarchy roots at a key derived from the UID and a per-file random; rotate the right intermediate and every wrapped file becomes unrecoverable noise.

2.3 The Memory Protection Engine

The SEP's RAM is, physically, in the same DRAM module as everything else. A naive design would let the application processor read it. The MPE prevents that. Every cache line bound for SEP memory is encrypted with AES in XEX mode (a tweakable mode similar to disk-encryption XTS) and authenticated with a CMAC tag. The tweak includes the physical address, so an attacker cannot relocate ciphertext to a different location and have it still verify (Apple Platform Security: Secure Enclave [@apple-sep-chapter]).

Starting with the A11 SoC, the MPE added an anti-replay value per protected block, with the anti-replay tree rooted in dedicated on-die SRAM. The threat that introduces is: an attacker who can capture the encrypted DRAM contents at time T1 and overwrite the DRAM with that snapshot at time T2 -- a "store, rewind, replay" attack. Tree-rooted anti-replay defeats it because the root in SRAM does not match the old leaves the attacker re-injected.

The tweakable XEX construction has the property that two cache lines containing the same plaintext at different addresses produce different ciphertext, which prevents the pattern-leakage you get from ECB-style encryption. CMAC adds a 128-bit integrity tag.

From the A14 and M1 generation onward, the MPE handles two ephemeral keys: one for SEP-private data and one for data shared with the Secure Neural Engine (used during Face ID matching). The keys are regenerated at every reset, so even capturing the DRAM ciphertext across a reboot leaks nothing.

2.4 The Secure Storage Component

Anti-hammering -- the property that a passcode-guessing attacker is rate-limited and eventually locked out -- requires reliable monotonic state that the attacker cannot rewind. Mask ROM and on-die SRAM are not enough on their own because power loss erases SRAM. From the A13 SoC onward, Apple solves this by adding a separate chip on the logic board: the Secure Storage Component (SSC) [@apple-ssc].

The SSC is small, tamper-resistant, and only the SEP can talk to it. It stores monotonic counters and entropy values that the SEP uses to bind authenticated storage to wall-clock state. If you steal the phone, dump the encrypted blobs, "rewind" by overwriting the flash with an earlier copy, and try to brute-force the passcode again, the SSC's counters no longer match. Anti-hammering survives the rewind.

Note: A monotonic counter sounds easy until you remember that an attacker with the physical device can pull power at any instant, including in the middle of an increment. The SSC has to atomically commit counter updates while also defending against deliberate transient brown-outs. This is the kind of thing that takes a dedicated tamper-resistant chip rather than a software loop.

2.5 The mailbox API

Userspace apps never touch the SEP directly. The application processor reaches it through a hardware mailbox -- a small ring of registers and shared memory that defines the entire API surface from AP to SEP. The kernel exposes higher-level services on top: Touch ID and Face ID matching, Keychain entries flagged with kSecAttrTokenIDSecureEnclave [@apple-keychain], Data Protection class keys, App Attest signing, and so on.

The constraint is severe. The SEP exposes a fixed set of operations. No app, and no part of the OS, can ask the SEP to do something the firmware did not already implement. Compromise of the AP-side kernel does not produce an arbitrary-code-execution primitive on the SEP. It produces, at most, the ability to call SEP services from a hostile place -- and those services still require user authentication (FaceID, TouchID, passcode) before they release sensitive operations.This is the dual of the TPM 2.0 design philosophy. A TPM defines a wide command set in its spec; the firmware implements that command set; software calls those commands. The SEP defines a narrow service set bespoke to Apple's products; everything else is rejected.

Note: The SEP is not a generic crypto coprocessor. It is a small fixed-purpose computer that knows how to do exactly the operations Apple's platforms need, and nothing else. Its security comes from being deliberately less programmable than a TPM.

If you had to summarize what Apple built in one sentence: they put a second computer in the phone, gave it the keys, gave it a lock on its own door, and left a slot for messages to slide through. That is the design.

3. Microsoft's answer: kill the bus, keep the standard

Apple had the luxury of designing the application processor and the security processor together. Microsoft does not. Microsoft sells software that runs on AMD, Intel, and Qualcomm silicon, on chassis from Dell, HP, Lenovo, Acer, Asus, Microsoft itself, and a long tail of others. The discrete TPM 2.0 standard fixes a contract between Windows and a piece of trusted hardware that any vendor can implement. Pluton's job was to keep that contract while removing the parts that did not survive contact with reality.

The first part of reality Pluton kills is the bus.

3.1 The Xbox lineage

Microsoft did not invent Pluton for Windows. The architecture started in the original Xbox One, shipping in 2013 [@ms-pluton-learn], where it served as the security subsystem that prevented modchipping and verified the boot chain. The same architecture was extended to the Azure Sphere MT3620 microcontroller in 2018 [@ms-pluton-learn], aimed at IoT devices. The Windows variant -- the one most people mean when they say "Pluton" -- was announced in November 2020 [@ms-pluton-announce].

The first shipping Windows silicon containing Pluton was the AMD Ryzen 6000 series ("Rembrandt") in January 2022. Qualcomm Snapdragon 8cx Gen 3 and the Snapdragon X family followed in 2023-2024. Intel's first Pluton-bearing CPU was Core Ultra Series 2 ("Lunar Lake") in late 2024. As of the current Microsoft documentation, the supported matrix is "AMD Ryzen 6000/7000/8000/9000 and Ryzen AI Series; Intel Core Ultra 200V Series, Ultra Series 3; Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series" (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]).This is a deployment claim. Pluton's presence on these CPUs is documented by the silicon vendors and Microsoft. Whether Pluton is enabled by default on a given laptop varies by OEM. Practitioners verifying real fleets need to confirm via Windows' Device Manager and tpm.msc whether the active TPM advertises the Microsoft Pluton manufacturer ID rather than a discrete vendor.

3.2 What sits on the die

Pluton is a security subsystem placed inside the SoC, not on a separate chip on the motherboard. That single architectural decision eliminates the LPC/SPI bus that defeats discrete TPMs. Microsoft's framing in the announcement post: the design targets attacks "where an attacker can steal or temporarily gain physical access to a PC ... on the communication channel between the CPU and TPM" (Microsoft Security Blog [@ms-pluton-announce]).

Microsoft-authored security subsystem integrated into the SoC die of supported AMD, Intel, and Qualcomm processors. Pluton presents a TPM 2.0 interface to Windows but adds firmware-update via Windows Update and capsule, on-die placement (no external bus to sniff), and a Microsoft-maintained codebase that Microsoft describes as "Rust-based" from 2024 onward [@ms-pluton-learn] on AMD and Intel platforms. Microsoft's name for keys that are "never exposed outside the protected hardware, even to the Pluton firmware itself" (Microsoft Security Blog, 2020 [@ms-pluton-announce]). Conceptually equivalent to Apple's UID-tangled keys: a hardware boundary that even the firmware running on top cannot cross.

Inside the die, Pluton runs its own small processor (the vendors do not publish the ISA in customer-facing docs), with its own ROM, on-die RAM, hardware crypto engines, and a hardware-confined key store. It exchanges messages with the host through a mailbox interface analogous to SEP's, but the higher-level wire protocol it speaks back to the host is TPM 2.0.

3.3 TPM 2.0 as the personality, not the limit

Pluton implements the TPM 2.0 command set. That means BitLocker, Windows Hello, Credential Guard, System Guard, Measured Boot, and Device Health Attestation all work against Pluton with no modifications -- they think they are talking to a TPM 2.0 chip, and they are (Microsoft Pluton as TPM, Microsoft Learn [@ms-pluton-as-tpm]).

TPM 2.0 compatibility is the compromise that buys Microsoft adoption. The entire Windows security stack was already designed against the TCG TPM 2.0 wire protocol. Forcing it onto a new API would have required years of platform engineering. Forcing it onto a new API and getting OEMs to adopt the new chip would have required forever.

You could read the Pluton design as "TPM 2.0 with a software-update channel." That is mostly right and is how the documentation usually describes it. But Pluton also supports Pluton-specific paths beyond TPM 2.0 -- the Microsoft Learn documentation [@ms-pluton-learn] refers to Pluton-rooted credentials and attestation flows that ride alongside the TPM personality. The TPM interface is the lowest common denominator, not the ceiling. flowchart TD subgraph Windows["Windows OS"] BL[BitLocker] WH[Windows Hello] CG[Credential Guard] DHA[Device Health Attestation] end subgraph Pluton["Pluton subsystem on SoC"] TPMpers["TPM 2.0 personality -- (PCRs, EK, AK, Quote, Seal)"] MSrooted["Microsoft-rooted services -- (Pluton credentials, MS-signed firmware)"] end BL --> TPMpers WH --> TPMpers CG --> TPMpers DHA --> TPMpers DHA --> MSrooted WH --> MSrooted

3.4 The patch channel

This is the design feature Microsoft most emphasizes and where the philosophical break with Apple is most visible. Pluton firmware can be updated through two paths (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]):

UEFI capsule update. The Pluton firmware lives on the system's SPI flash and is loaded during early boot. A capsule update -- delivered via the same UEFI mechanism that updates BIOS -- can replace it.
Dynamic loading via Windows Update. Microsoft can ship a new Pluton firmware blob through Windows Update; the OS loader picks it up the next time the subsystem comes online.

Apple's update model is essentially the first path with a different label. The SEP firmware ships inside the iOS/macOS image bundle, signed by Apple, and is loaded at boot. There is no Windows-Update-style ambient channel separate from the OS image.

Patchable. By Microsoft. Through the channel users already trust. This is the single biggest practical advantage Pluton has over discrete TPMs, and the single biggest political problem.

The structure of this difference is what makes the Apple-vs-Microsoft comparison sharp. Apple controls the entire silicon, OS, and update channel. The patch path is fast because everything is one vendor. Microsoft does not control the silicon -- AMD, Intel, and Qualcomm do -- but they wrote the firmware, signed it, and route it through Windows Update. The patch path is fast because Microsoft has been delivering OS-level updates to a billion machines for a quarter century.

3.5 Rust as the firmware base

In 2024 Microsoft began shipping Pluton firmware on AMD and Intel with what the documentation calls "a Rust-based firmware foundation given the importance of memory safety" (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]). This is, as far as we can tell from primary sources, the most prominent shipping production use of Rust inside an x86 platform security subsystem. It addresses the most common class of TPM firmware bugs, which historically have been C memory-safety issues -- bounds errors, use-after-frees, integer overflows.

Note: Rust eliminates the spatial and temporal memory-safety bugs that dominate CVE counts in C-based firmware. It does not prevent logic bugs, side-channel leaks, or fault-injection vulnerabilities. The faulTPM work, discussed in Section 7, exploits the underlying voltage rail rather than firmware bugs -- and the same physics apply whether the firmware is in C or Rust.

If the SEP's design philosophy is "small fixed-purpose computer," the Pluton design philosophy is "in-die TPM 2.0 we can actually patch, written carefully enough that we will not have to patch it often." Two different bets about which property mattered most.

4. The tightly-coupled vs SoC-integrated trade-off

So far we have two architectures: SEP as a separate physical core, Pluton as an on-die subsystem. They sound different. They are different. But "separate core" and "on-die subsystem" both refuse the discrete-TPM design where the security chip is off the SoC and reachable over a motherboard bus. Why did both vendors converge there, and what is the trade-off between SEP-style and Pluton-style integration?

4.1 What both reject

The discrete TPM 2.0 model is the baseline. A separate chip, often a Nuvoton, Infineon, or ST device on the motherboard [@pulse-tpm-sniff], connected to the platform via LPC, SPI, or I²C. The TCG spec it implements is excellent. The physical placement is the problem.

Pulse Security's attack is the canonical demonstration. With lpc_sniffer_tpm on a $40 FPGA, they probed the LPC bus of a Surface Pro 3 as it booted, captured the bytes the TPM returned for the unsealed Volume Master Key, and used those bytes to decrypt the disk (Pulse Security: TPM Sniffing [@pulse-tpm-sniff]). The TPM was working correctly. The bus was the problem. There is a mitigation -- pre-boot PIN or USB key, so the VMK is bound to something not on the wire -- but the default BitLocker configuration on most enterprise hardware does not enable it.

The class of physical-access attacks in which an adversary attaches probes to the motherboard bus carrying TPM responses, captures the cleartext key material the TPM legitimately returns, and uses it directly. Defended against by either eliminating the external bus (Pluton, SEP) or by requiring authenticated/encrypted sessions plus pre-boot user authentication (TPM 2.0 parameter encryption, BitLocker TPM+PIN).

Both SEP and Pluton refuse to expose that bus. The keys never appear on an external wire. That is the structural property both architectures buy by being on the SoC.

4.2 Tightly-coupled (SEP) vs subsystem-on-die (Pluton)

After agreeing on "no external bus," the two diverge sharply on what "on the SoC" should look like.

flowchart TD subgraph SEPDie["Apple SoC (A14, M1, M2, etc.)"] SEPCore["SEP core -- own voltage -- own clock -- own ROM"] MPE["Memory Protection Engine"] APCore["Application processor cores"] SEPCore -- mailbox --> APCore SEPCore --> MPE end subgraph PlutonDie["AMD/Intel/Qualcomm SoC"] PSub["Pluton subsystem -- (may share voltage rail -- with security die area)"] PSP["Vendor security subsystem -- (AMD PSP / Intel CSME)"] Cores["Application cores"] PSub -- on-die fabric --> Cores PSub -.runs on top of.-> PSP end

The SEP is a separate physical core with its own clock, its own voltage rail, and crucially no shared microarchitecture with the application processor. That last point matters because the family of cross-thread, cross-core, and frequency-scaling side channels -- Meltdown, Spectre, Foreshadow, Hertzbleed, and their cousins -- generally requires the attacker code to be co-resident on the same physical pipeline or share a microarchitectural resource. The SEP simply does not share execution resources with potentially hostile code on the application cores (Apple Platform Security: Secure Enclave Processor [@apple-sep-chapter]).

Pluton-on-AMD is implemented inside the AMD Platform Security Processor environment. Pluton-on-Intel is implemented inside Intel's Converged Security and Management Engine. These are pre-existing vendor security subsystems Microsoft layered Pluton atop. The Pluton subsystem is logically separate, with its own firmware and its own key store. Whether it has a fully separate physical voltage rail and clock domain from the application cores is not something the public documentation states clearly, and the answer almost certainly varies by silicon partner.This is a place where the comparison is hardest to make crisply. Apple has a single answer because Apple makes one SoC family. Microsoft has three answers because Pluton lives inside whatever security subsystem AMD, Intel, or Qualcomm already provide. The detail-level guarantees vary.

4.3 The SGX cautionary tale

There is a third design point worth flagging because both vendors implicitly chose against it: putting the trusted execution environment inside the application CPU cores themselves. Intel SGX, introduced in 2015 [@intel-sgx], did exactly that. Enclaves were memory regions with hardware access control inside the same cores running ordinary software.

SGX was a beautiful idea and an academic catastrophe. Foreshadow, ZombieLoad, SgxPectre, Plundervolt, and a long sequence of related attacks reused the side-channel-rich microarchitecture of modern Intel cores to leak enclave contents. Intel deprecated SGX on most consumer processors in 2022 [@intel-sgx-deprecation], retaining it on server SKUs for confidential computing scenarios where the threat model is different.

The lesson is something both Apple and Microsoft seem to have absorbed: a trusted execution environment that shares any microarchitectural state with the workloads it must protect from is structurally compromised, because microarchitecture is too rich and too leaky to perfectly isolate. The SEP rejects this by living on its own core. Pluton rejects it by living in a separate subsystem.

Arm TrustZone, introduced in Arm v7 around 2008 [@arm-trustzone], pioneered the "secure world / normal world" split inside a single core. TrustZone is closer to SGX than it is to SEP or Pluton in this respect: secure world and normal world share the same physical pipeline. TrustZone influenced both SEP and Pluton in the sense that "you need a separate execution environment for security code" became table stakes; both companies then moved that environment off the application core entirely.

4.4 The trade-off in one sentence

A dedicated core (SEP) maximises side-channel resistance and minimises attack surface, at the cost of vendor proprietary lock-in and zero portability. An on-die subsystem (Pluton) preserves the TPM 2.0 standard, ships on three silicon vendors, and inherits the security guarantees of the underlying vendor security subsystem -- whose history, as we will see, is less reassuring than Apple's monopoly on its own silicon.

Key idea: SEP wins on isolation. Pluton wins on portability. Neither wins on both. The choice you make at the SoC level constrains every API, every patch path, and every threat-model claim downstream.

5. The APIs developers actually call

Architectures are interesting. What ships in production code is what determines whether developers use these things correctly. The API surfaces are wildly different, and the difference matters.

5.1 Apple: SecKey, App Attest, LocalAuthentication

On Apple platforms, the SEP is exposed through a handful of frameworks. The most common entry point is SecKey in the Security framework, with key attributes that bind the key to the SEP:

kSecAttrTokenIDSecureEnclave makes the key SEP-resident.
kSecAttrAccessControl with LAContext adds biometric or passcode gating.
kSecAttrIsPermanent puts it in the Keychain [@apple-keychain].

The key itself never leaves the SEP. The application receives an opaque handle. Asking the framework to sign a message turns into a mailbox call to the SEP, which evaluates the access-control policy (e.g., "the user must FaceID-authenticate within the last five seconds") and either signs or refuses.

{` // This is a conceptual model of what happens when iOS code asks the SEP // to sign a message with a key whose private half lives inside the SEP. // The real code is Swift + Security.framework; this JS captures the logic.

function generateSEPKey(accessControl) { // SEP generates the keypair internally const priv = sepRandomBytes(32); // never leaves SEP const pub = ecP256ScalarMul(priv, BASE_G); const blob = aesKeyWrap(sepUIDDerivedKey, priv); return { publicKey: pub, handle: opaque(blob), policy: accessControl }; }

const k = generateSEPKey({ requireBiometric: true }); console.log("Public key returned to the app:", k.publicKey); console.log("Private key location: inside SEP, never accessible to app code"); `}

Beyond SecKey, the SEP underpins:

LocalAuthentication -- Face ID / Touch ID matching happens inside the SEP. The biometric template never leaves the SEP, and the application is only told yes/no.
DeviceCheck and App Attest -- documented in the Apple Platform Security Guide [@apple-platform-security]. App Attest gives each app installation a SEP-rooted asymmetric key whose certificate chains to Apple's CA, letting servers verify that a sign-up came from a genuine app on a genuine Apple device.
Data Protection / FileVault -- per-file class keys are wrapped under SEP-held intermediate keys.
Apple Pay -- payment credentials are SEP-resident and gated on biometric/passcode authentication.

Apple's hardware-backed app integrity service [@apple-platform-security]. Each install of each app receives a unique SEP-resident key whose attestation certificate, signed by Apple, lets a back-end server verify that the request originates from a non-tampered installation. The closest cross-platform analogue is Google Play Integrity API; the closest discrete-TPM analogue is TPM 2.0 attestation, but App Attest is more strongly bound to the specific app installation.

5.2 Microsoft: TBS, NCrypt, Pluton-rooted credentials

On Windows, the TPM 2.0 personality means Pluton is reached through the same APIs as any TPM:

TPM Base Services (TBS) -- the low-level Win32 API for sending TPM 2.0 commands.
CNG (Cryptography Next Generation) with NCrypt and the Microsoft Platform Crypto Provider -- the higher-level key API that asks "store this key in the TPM, gated on the user's PIN."
BCryptDecrypt / BCryptSignHash as the in-process crypto API on top.

The DPAPI key-protection model -- file/blob protection rooted in user logon credentials -- has a CNG variant documented as CNG DPAPI [@ms-cng-dpapi] that integrates with TPM-rooted hierarchies. Above that sit the consumer-facing systems: BitLocker for disk encryption [@ms-bitlocker], Windows Hello for credential storage, Credential Guard for isolating LSA secrets in a virtualization-based security enclave, and Microsoft Entra ID conditional access for cloud sign-in.

The TCG TPM 2.0 Library Specification [@tcg-tpm2] defines the command set, object hierarchy, and key-handling semantics of TPM 2.0 chips. Commands include `TPM2_CreatePrimary`, `TPM2_Create`, `TPM2_Load`, `TPM2_Seal`, `TPM2_Unseal`, `TPM2_Quote`, and `TPM2_Certify`. Both discrete TPMs and Pluton implement this command set. flowchart LR subgraph Apple["Apple application stack"] App[App] --> Sec["Security.framework -- (SecKey, SecAccessControl)"] App --> LA["LocalAuthentication -- (LAContext)"] App --> DC["DeviceCheck / App Attest"] Sec --> Mailbox[SEP mailbox] LA --> Mailbox DC --> Mailbox Mailbox --> SEPSvc[SEP services] end subgraph MS["Windows application stack"] WApp[App] --> NCrypt["CNG / NCrypt"] WApp --> Hello["Windows Hello"] WApp --> Entra["Entra ID / Health Attestation"] NCrypt --> TBS["TPM Base Services"] Hello --> TBS Entra --> TBS TBS --> Pluton["Pluton (TPM 2.0 personality)"] Entra --> PlutonMS["Pluton MS-rooted services"] end

5.3 What the API shape tells you

The SEP API forces every call into the small set of operations the SEP firmware implements. There is no TPM2_PolicyLocality(2) equivalent or TPM2_PolicyOR combinator on the SEP. You ask for a key, you ask for a signature, you ask for a biometric match, and that is mostly the surface. From a developer's point of view, the SEP feels like a very small set of well-defined building blocks.

The TPM 2.0 API, by contrast, is enormous. There are several hundred commands. The TPM has policy expressions, sessions, hierarchies (storage, endorsement, platform, owner), and a half-dozen attestation primitives. This expressiveness was the right call for an open standard -- the TCG had to accommodate every conceivable use case across two decades. It also means that "wrote TPM 2.0 code correctly" is a measurable engineering skill rather than a default.

Note: On Apple platforms, prefer kSecAttrTokenIDSecureEnclave with kSecAccessControl rather than rolling your own key handling. On Windows, prefer CNG with Microsoft Platform Crypto Provider over raw TBS unless you specifically need a TPM command not exposed by CNG. Both vendors put their good defaults in the higher-level APIs.

5.4 A note on what is not exposed

Neither platform exposes the device's per-silicon root key to applications. On Apple, the UID is sealed inside the SEP; on Microsoft, the Pluton Endorsement Key is unique per chip but applications interact only with the AKs (Attestation Keys) derived from it. This is deliberate: per-device permanent keys, if exposed, enable cross-service tracking. The exposed primitives are either per-app/per-installation (App Attest), per-session (TPM2_Quote with a fresh AK), or ephemeral (a freshly-generated SEP key).

That choice maps to a privacy property we will pick up in the next section: how each platform answers "prove this is a real device" without becoming "track this specific user across every service."

6. Identity, attestation, and the privacy problem

The deepest difference between Apple and Microsoft is not architectural. It is the answer each one gives to a question that sounds simple: what does it mean to prove a device is real?

6.1 Why attestation is hard

A naive answer is: burn a unique identifier into every chip and have the chip sign messages with the corresponding private key. That works for proof. It also creates a per-device pseudonym that every service can recognise and correlate. The naive answer is a surveillance disaster.

A better answer keeps the unforgeability of "this signature came from a real device" and adds an unlinkability property: the signature does not identify which device, only that it is genuine. This is what cryptographers call anonymous attestation, and the canonical construction is DAA.

A class of cryptographic protocols that let a hardware token sign messages in a way that proves it belongs to a group of legitimate devices without revealing *which* device. Introduced by Brickell, Camenisch, and Chen in 2004 [@brickell-2004-daa] as part of the TPM 1.2 specification work, with the elliptic-curve variant ECDAA standardized for TPM 2.0. See the Wikipedia overview [@daa-wikipedia] for the protocol skeleton.

The mathematics of DAA rests on group signatures with selective linkability. A device runs the join protocol once with a group issuer (the "Privacy CA" or analogous authority) and receives a credential. It can then prove, via a Camenisch-Lysyanskaya-style signature of knowledge, that it holds such a credential without revealing which one. With ECDAA, the join and signing operations are roughly the cost of a couple of elliptic-curve multiplications.

The privacy property comes with caveats. Verifiers can opt into "basename" linkability, where signatures from the same device addressed to the same service are linkable -- letting a service recognise a returning user without letting it correlate across services. The math has been deployed in TPM 2.0 since the 2014 spec.

6.2 The Microsoft path: TPM 2.0 attestation plus Microsoft-rooted services

Pluton inherits TPM 2.0's attestation primitives. The standard flow:

Generate an Attestation Key (AK) inside the TPM, with a private half that never leaves.
Certify the AK to a Privacy CA (or via ECDAA) using the Endorsement Key.
Hash the boot configuration into Platform Configuration Registers (PCRs) during measured boot.
Have the relying party send a fresh nonce.
Issue TPM2_Quote(AK, PCR_mask, qualifying_data=nonce).
Send the quote, the AK certificate, and the boot event log to the relying party.
The relying party replays the event log, checks that the replayed PCRs match the quoted ones, validates the AK certificate chain, and validates the signature.

attest(nonce, pcr_mask):
    AK = TPM2_Create(parent=EK, type=signing)
    AK_cert = privacy_CA.certify(AK_pub, EK_cert)    # or ECDAA group sig
    quote = TPM2_Quote(AK, pcr_mask, qualifying_data=nonce)
    return (quote, AK_cert, event_log)

verify(quote, AK_cert, event_log, expected_pcrs):
    assert privacy_CA.verify(AK_cert)
    assert ECDSA_verify(AK_cert.pub, quote.sig, quote.body)
    assert quote.qualifying_data == nonce
    assert replay_log(event_log) == quote.pcrs == expected_pcrs

That covers raw TPM 2.0. Microsoft layers on top a service called Device Health Attestation that does the verifier work as a cloud service, supplying Reference Integrity Manifests for known-good Microsoft-signed boot states. Microsoft Entra ID conditional access policies can then refuse sign-in to devices whose Pluton-signed health attestation does not match an expected baseline (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]).The interesting privacy property here is that ECDAA-grade unlinkability is available through TPM 2.0, but Microsoft's deployed services tend to use Privacy-CA-style flows where the AK certificate is well-defined and reusable. Whether a given Microsoft attestation flow is anonymous-unlinkable or pseudonymous-linkable is a per-service detail rather than a platform property.

6.3 The Apple path: rooted in Apple's CA, scoped per app

Apple's DeviceCheck and App Attest [@apple-platform-security] take a different approach. App Attest gives each installation of each app a unique SEP-resident key. The corresponding attestation certificate chains to Apple's CA. Apps prove integrity to their own back-end servers by having the server send a nonce, the SEP signing the nonce with the per-install key, and Apple's CA chain validating that the key was issued on a genuine Apple device.

The privacy property is scoped differently from DAA. The key is per-installation, which means uninstalling and reinstalling the app generates a new key with no link to the old one. Across different apps on the same device, the keys are independent -- so two apps cannot collude with their respective back-ends to detect they are on the same phone. The trade-off: there is no formal anonymity within a group; the key is identifiable to its single installation, but that installation is fresh each install.

DeviceCheck is older and weaker. It gives an app a two-bit value the developer can set per device, retrievable on future runs. It is fraud-signal infrastructure, not cryptographic proof.

DAA is a group-signature scheme; Apple's App Attest is a per-installation public-key scheme certified by Apple. They are not the same primitive. DAA gives "I am in this group of devices" without revealing which device. App Attest gives "I am this specific installation, and Apple says it is genuine." The privacy distinction matters when the threat is correlation across services rather than correlation within a single service.

6.4 Where the two converge: FIDO2/WebAuthn

Both platforms expose their hardware-backed credentials through a single cross-platform standard: FIDO2/WebAuthn. When a browser asks "create a credential bound to this origin, hardware-resident if possible," the underlying operating system asks SEP or Pluton to generate the key. The resulting public-key credential, signed by the device's attestation key, is what the relying party verifies (FIDO Alliance [@fido-alliance]).

sequenceDiagram participant Browser participant OS as OS Authenticator participant HW as SEP or Pluton participant RP as Relying Party RP->>Browser: Challenge nonce, RP ID Browser->>OS: navigator.credentials.create() OS->>HW: Generate key bound to RP ID + user gesture HW-->>OS: Public key + attestation OS-->>Browser: Public key + signed attestation Browser->>RP: Registration response Note over RP: Stores public key RP->>Browser: Authentication challenge Browser->>OS: navigator.credentials.get() OS->>HW: Sign challenge (user gesture) HW-->>OS: Signature OS-->>Browser: Assertion Browser->>RP: Authentication response RP->>RP: Verify signature with stored pubkey

FIDO2/WebAuthn is the most boring and most important fact about modern hardware roots of trust: from the application's point of view, you no longer need to know whether you are talking to SEP or Pluton or a discrete TPM. The same JavaScript runs on all of them. We will return to FIDO2 in Section 8.

Note: Attestation is where Apple and Microsoft diverge most sharply on privacy philosophy. Microsoft uses TPM 2.0 with anonymous-group cryptography available but not always deployed. Apple uses per-installation keys rooted at Apple's CA. FIDO2/WebAuthn is the layer where both meet the developer at the door.

7. What has actually broken

Architecture is a story you tell about a system. Attacks are the system's reply. Both SEP and Pluton have a public attack history; reading it carefully is the fastest way to understand the real threat model rather than the marketing one.

7.1 checkm8 and the unpatchable boot ROM

In late 2019, the researcher axi0mX published ipwndfu [@ipwndfu], an exploit against a use-after-free in the SecureROM USB DFU stack of Apple SoCs from A5 through A11. The advisory carries CVE-2019-8900 [@nvd-checkm8] and CERT/CC VU#941987 [@cert-checkm8]. Because SecureROM is mask ROM -- etched into the silicon, immutable -- Apple cannot patch it. The only mitigation was new silicon. A12 and later are immune; earlier devices are permanently affected.

What checkm8 buys an attacker is application-processor code execution at boot time, on a device they have physical access to. That is significant. It enables forensically sound extraction tooling -- the Elcomsoft writeup walks through exactly which iPhone models and iOS versions are supported [@elcomsoft-checkm8]. It also covers the Apple T2 chip used in 2018-2020 Intel Macs [@apple-a-series], which is built on the same A10-family silicon.

But checkm8 does not, by itself, break SEP secrets. The SEP is still gated by the device passcode and the data-protection class keys. An attacker with checkm8 can run code on the AP, but they still need the passcode to unlock the user's protected data (CERT/CC VU#941987 [@cert-checkm8]). The forensic value of checkm8 comes from being able to brute-force passcodes more effectively, capture keyboard state, and access classes of data not bound to a passcode -- not from extracting SEP-held keys directly.

Note: If your organization still has 2018-2020 Intel Macs (T2-bearing) in service, they remain physical-access-attackable. The exploit is mature, the tooling is public, and the silicon will never be patched. For high-value users, retire T2 hardware in favor of Apple Silicon Macs (M1 and later, which use A14-derived SoCs immune to checkm8) (Elcomsoft: using checkm8 [@elcomsoft-checkm8]).

The Pangu team's "Blackbird" SEPROM exploit, presented at MOSEC 2019, reportedly compromised SEPROM on A10/A10X devices. Apple has not published a detailed advisory for that work and the original presentation materials are not in the verified-sources list, so we mention it only by way of acknowledging that even SEP boot ROMs have a finite security lifetime. The architectural point stands: any unpatchable ROM becomes a permanent liability when a bug is found in it.

7.2 LPC sniffing and discrete TPMs

We opened with this attack and it deserves a second pass in the context of Pluton's design. The Pulse Security writeup [@pulse-tpm-sniff] demonstrates extraction of the BitLocker Volume Master Key from a Microsoft Surface Pro 3 (TPM 2.0) and a Lenovo laptop (TPM 1.2) using a $40 FPGA on the LPC bus. The attack requires physical access for under an hour and modest soldering skill.

This is the textbook case where Pluton is structurally better than discrete TPMs: there is no external bus to sniff because the security subsystem lives on the SoC die. The same attack against a Pluton-enabled CPU is not just hard, it is geometrically impossible. There is no bus to attach probes to.

That is not the same as "Pluton is unattackable" -- it just means this specific attack class is closed.

7.3 faulTPM and the AMD PSP

The most consequential publication on Pluton-adjacent silicon is Werling, Buhren, Jacob, and Seifert's 2023 USENIX WOOT paper "faulTPM" [@faultpm]. The attack: voltage fault injection against AMD's Platform Security Processor (PSP), the TEE on which AMD's fTPM runs, on Zen 2 and Zen 3 CPUs. The result: full extraction of the fTPM key derivation seed. With that seed, the attackers decrypted all sealed objects regardless of PCR policy or anti-hammering, and recovered the BitLocker VMK on a Lenovo Ideapad. The reproducible attack code is PSPReverse/ftpm_attack on GitHub [@faultpm-repo].

Several careful observations:

The published attack targets non-Pluton AMD fTPM. Pluton-on-AMD is a separate code path; faulTPM as published does not directly extract Pluton state.
Pluton-on-AMD runs in the PSP environment. The underlying TEE that faulTPM compromises is the same TEE Pluton-on-AMD rides on. Whether the additional hardening Pluton adds is sufficient to defeat fault injection at the PSP level is an open empirical question.
There is no published voltage-glitch attack against Microsoft Pluton specifically as of May 2026 in the verified sources surveyed. Absence of evidence is not evidence of absence; serious researchers are reportedly working on it.

A physical attack class in which the attacker briefly reduces or perturbs the supply voltage to a target chip at a precisely timed moment, causing it to mis-execute an instruction in a controlled way. With sufficient practice, VFI can be used to skip authentication checks, leak intermediate values, or corrupt key derivation. Defenses include redundant voltage sensors, double-execution of sensitive operations, and physically separating the voltage domain of the security subsystem -- mitigations Apple alludes to for SEP and Microsoft alludes to for Pluton, but neither vendor publishes a complete defensive model. If your adversary is a state-level laboratory with \$50K of equipment and a few hours of physical access, no commodity hardware root of trust on the market today is fully resistant to fault injection. The realistic question is "how much does extracting the key cost, and is that cost above the value of what is protected?" For consumer threat models, faulTPM is exotic; for high-value enterprise or dissident use cases, it is in scope.

7.4 What is not known to be broken

Modern SEP (A14+/M-series) has no publicly disclosed extraction attack as of the May 2026 verified sources reviewed. The combination of dedicated core, MPE with anti-replay, lower clock, and SSC-backed replay protection has held up. This is consistent with -- but does not prove -- the architectural claim that the dedicated-core design closes the side-channel and co-execution attack surface.

Pluton with the 2024+ Rust firmware foundation has no publicly disclosed direct extraction attack. The faulTPM family of attacks remains an open concern at the PSP layer; the LPC bus class is closed by design; firmware bugs are reduced (not eliminated) by the move to memory-safe code.

flowchart TD A["Attack class"] --> B{"Discrete TPM"} A --> C{"AMD fTPM"} A --> D{"Pluton"} A --> E{"Apple SEP A14+"} B --> B1["LPC sniffing: yes (Pulse Security)"] B --> B2["Firmware bug: rare patches"] C --> C1["faulTPM: full extraction"] C --> C2["Patches: BIOS only"] D --> D1["LPC sniffing: not applicable"] D --> D2["faulTPM-like on PSP: open"] D --> D3["Patches: Windows Update + capsule"] E --> E1["checkm8 on A5-A11: AP code exec"] E --> E2["Direct SEP extraction A14+: none public"] E --> E3["Patches: iOS/macOS update, mask ROM never"]

The honest summary is that as you move from discrete TPMs to fTPMs to Pluton to SEP, the attack surface shrinks but the residual attacks get more expensive rather than disappearing. The faulTPM line is still the academic state of the art in showing this.

8. Cross-platform standards: the layer where the divide gets papered over

If you are a web developer in 2026 and a user asks "how do I sign into your site with my Touch ID or my Windows Hello fingerprint?" the answer is the same in either case: WebAuthn. The standard does not care which hardware root of trust the OS happens to expose underneath.

8.1 FIDO2/WebAuthn as the lingua franca

The FIDO Alliance [@fido-alliance] defines the protocols. WebAuthn is the W3C JavaScript API; CTAP (Client to Authenticator Protocol) is the underlying transport between the browser/OS and the authenticator. The authenticator can be a USB security key, a phone, a built-in platform authenticator backed by SEP or Pluton, or something else entirely. The relying party sees the same registration and authentication ceremony in all cases.

The handful of properties WebAuthn guarantees -- origin binding, user gesture, fresh signature per challenge -- are independent of the silicon underneath. The handful of properties it does not try to guarantee -- "is this device freshly compromised by a kernel rootkit" -- are not fixable at the protocol layer either; that is what attestation extensions are for.

8.2 Where attestation extensions vary

WebAuthn defines optional attestation extensions that let a relying party request a hardware-backed proof that the authenticator is genuine. Apple's attestation through WebAuthn rides on App Attest infrastructure; Microsoft's rides on TPM 2.0 attestation. The receipts differ in format and certificate chain, but the higher-level question "does the public key come from genuine hardware" gets answered on both platforms.

For most relying parties, the cross-platform truth is simpler than the underlying mechanics: ask for a hardware-backed credential, accept the WebAuthn response, validate the signature, and let the platform handle what kind of silicon was involved.

WebAuthn looks like it should be the climax of the article. From an architecture perspective, it is the anticlimax. The whole point is that, at the application layer, SEP and Pluton are interchangeable. That is what the standard is for. The differences resurface only when you care about device-class attestation or about the privacy property of the attestation key -- both of which are extension-level concerns rather than core-protocol concerns.

8.3 TPM 2.0 as the other lingua franca

TPM 2.0 itself plays this role in non-web contexts. Enterprise tools that need to attest a device's boot state -- Microsoft Entra ID conditional access, MDM compliance evaluators, Linux remote attestation frameworks -- speak TPM 2.0. Pluton exposes the TPM 2.0 wire protocol, so these tools work unchanged (Microsoft Pluton as TPM, Microsoft Learn [@ms-pluton-as-tpm]).

Linux on Apple Silicon (Asahi) currently cannot use SEP for analogous attestation; Apple does not expose the SEP to non-Apple operating systems, and there is no TPM 2.0 emulation. This is a real gap for users who want Apple hardware with a non-Apple OS.

8.4 The Android third corner

This article is about Apple vs Microsoft, but a complete picture must mention that Android has its own hardware root of trust story rooted in Trusty/TEE-style designs on ARM TrustZone plus discrete StrongBox elements on Pixel-class hardware. Cross-platform mobile development frequently abstracts SEP and Android StrongBox under a common interface (e.g., React Native's keychain modules), and the privacy and attestation properties of the two systems are not identical but rhyme. Google Play Integrity API plays the role App Attest plays on iOS.

Note: At the application layer, the right question is not "SEP or Pluton" but "are you using WebAuthn or TPM 2.0 or App Attest at the right point in the trust path." The platform-specific differences sit beneath those interfaces, and the standards are explicitly designed to be the place developers can stop caring.

9. Deployment dynamics: who ships what, where, when

The two industries have different shapes, and that shapes the deployment story.

9.1 Apple: vertical integration, total reach

Every shipping Apple device since the iPhone 5s contains a SEP, by virtue of every shipping Apple SoC containing one. That includes (Apple Platform Security: Secure Enclave [@apple-sep-chapter]):

iPhone 5s and later (A7+)
iPad Air and later
Apple Watch Series 1 and later
Apple TV HD and later
HomePod and HomePod mini
Apple Vision Pro
All Apple Silicon Macs (M1, M2, M3, M4 families)
All Intel Macs from 2018 to 2020 (via the T2 chip)

There is no SKU differentiation. There is no "Pro vs Air" split on whether security hardware is present. You buy a current-generation Apple device, you get the SEP. This is the upside of vertical integration: deployment by default.

The downside is that nothing else gets the SEP. Linux on Apple Silicon -- the Asahi Linux project -- cannot use the SEP for keychain operations, FileVault wrapping, or attestation. Apple does not expose the SEP outside of macOS, iOS, iPadOS, watchOS, tvOS, and visionOS. The hardware is universal in Apple's product line and absent everywhere else.

9.2 Microsoft: open multivendor, opt-in adoption

Pluton ships in silicon Microsoft does not make. That changes the deployment story in two ways:

Vendor availability. As of the current Microsoft documentation [@ms-pluton-learn], Pluton is present in AMD Ryzen 6000 and later, Intel Core Ultra Series 2 and later, and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series. Anything older still uses discrete TPM 2.0 or vendor fTPM.
OEM enablement. The chip can be physically present and disabled in UEFI. Microsoft has been pushing OEMs to ship Pluton enabled by default on Copilot+ PCs, but the universe of laptops is heterogeneous, and the practitioner answer is "check tpm.msc to see what manufacturer ID is reported."

Default-enabled-on-shipping-hardware is documented for Surface Laptop 7 and Surface Pro 11 Copilot+ PCs. Various Lenovo ThinkPad Z, Dell Latitude, and HP EliteBook configurations follow (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]). On other devices Pluton may be present but disabled in firmware, falling back to discrete TPM or vendor fTPM.This is a deployment claim that ages quickly. The shipping matrix shifts every six to twelve months as new SoCs come to market and OEMs rev their UEFI defaults. The verification workflow is the same regardless: Get-PnpDevice and tpm.msc on the actual hardware tell you what is active.

9.3 The patch-channel difference, made concrete

Apple ships SEP firmware inside its OS update. When the user installs iOS 19.4 or macOS 16.2, the bundle includes a new sepOS image; the device verifies and loads it during the next boot (Apple Platform Security [@apple-platform-security]).

Microsoft ships Pluton firmware through Windows Update and UEFI capsules. The OS-driven path lets Microsoft push a firmware refresh to billions of machines without OEM cooperation. The capsule path covers the case where the firmware is needed during early boot before Windows itself is in control.

Discrete TPMs occupy the third position: firmware updates exist but require an OEM-issued utility that few users ever run. This is why most enterprise TPMs in the field run firmware from 2020 or earlier.

Note: A serious bug in a discrete TPM chip is, in practice, never fully fixed because the patch never reaches the bulk of deployed devices. A serious bug in Pluton can be patched globally inside a Patch Tuesday cycle. A serious bug in SEP can be patched globally inside an iOS/macOS minor release. The same bug class produces three different incident-response time scales.

9.4 The economic and political layer

Apple controls every step from sand to support page. The benefit is consistency. The cost is that Apple decides what the SEP can and cannot do, with no externally visible audit, and the customer cannot verify the firmware. For the Apple-customer market, that has not been a deal-breaker.

Microsoft controls the Pluton firmware. The benefit is that one team's engineering effort propagates across three silicon vendors and thousands of OEM SKUs. The cost is that the OS update channel and the security update channel collapse into one Microsoft-controlled flow. Critics describe this as platform lock-in; supporters describe it as the only way to actually patch the silicon at scale. Both readings have evidence behind them.

The same patch channel that protects users from unpatched silicon bugs is the patch channel a hypothetical compelled-update scenario would use. There is no commodity product that gives the device owner an independent veto on root-of-trust firmware updates.

This is a real open problem, not a fictional one. The Trusted Computing Group has a notion of "owner-authorized" TPM hierarchies; Azure Sphere uses a three-key model in which device owner, vendor, and Microsoft all hold signing capabilities for different scopes. Nothing in the commodity consumer space has yet shipped a model where the device owner can veto a vendor-signed firmware update on the security subsystem.

10. Where this goes next

The honest answer is that the immediate future is more of the same with three new pressures.

10.1 Post-quantum migration

The cryptographic primitives currently rooted in both platforms -- ECDSA P-256 in the SEP, RSA-2048 and ECDSA in TPM 2.0 -- are not post-quantum-safe. NIST standardized ML-KEM and ML-DSA in FIPS 203 and FIPS 204 in 2024 (the NIST publication URLs are outside our verified-source set, so this paragraph states the timeline at the policy level only). Migrating hardware-fused attestation roots to post-quantum schemes is genuinely hard because the silicon-burned UID-equivalent keys are baked at fabrication time and cannot easily be replaced.

The likely path: hardware retains agility at the wrapping layer (the unique chip key) while the attestation key types evolve. TPM 2.0 already supports algorithm agility in the spec, which is the kind of foresight you only appreciate a decade after it was added. SEP's key wrapping is bespoke; Apple has not published a PQC migration plan in the verified sources reviewed.

This is a place where the comparison gets uncertain. Both vendors will need to migrate. Neither has shipped a primary post-quantum-rooted attestation flow in their public 2026 documentation as far as we can verify.

10.2 Confidential computing convergence

The same silicon technologies that build SEP and Pluton are now powering confidential computing -- AMD SEV-SNP, Intel TDX, ARM CCA. These extend the "untrusted host kernel" threat model from disk encryption and credential storage to entire virtual machines. The trust roots of confidential computing currently live in the same chips' security subsystems: AMD's PSP holds SEV-SNP attestation keys; Intel's CSME, working with TDX, holds equivalent keys.

Pluton-on-Intel and Pluton-on-AMD will likely inherit responsibilities here as Microsoft consolidates more of the security subsystem under the Pluton name. Apple has not publicly signaled equivalent ambitions for SEP on the server -- Apple's server presence is mostly internal.

10.3 The AI agent identity problem

This is the next decade's question. When your laptop runs an autonomous AI agent that signs cloud API requests on your behalf, what attests to the agent's identity? The current architectures attest to the device and to user gestures, not to the agent. There is no shipping primitive in either SEP or Pluton that says "this signature came from agent X running on device Y, gated by user policy Z that the user actually consented to."

A defensible reading is that both vendors are moving slowly toward agent-bound credentials, but neither has published a clean primitive. This is an open design space. We mark it as a place to watch rather than a place where shipping products have answers.

There is no shipping commodity hardware root of trust with simultaneously: post-quantum attestation, owner-vetoable updates, independently audited firmware, and agent identity. There may not be one for a decade. The current architectures -- SEP and Pluton -- are the strongest commodity options available, and they are still incomplete relative to the design space.

10.4 The convergence that probably will not happen

People periodically suggest that Apple should expose the SEP via TPM 2.0 for cross-platform compatibility, or that Microsoft should ship a dedicated security core like SEP. Neither is likely. Apple's value proposition rests on vertical integration; opening the SEP to non-Apple operating systems would dilute it. Microsoft's value proposition rests on multi-vendor compatibility; mandating a SEP-style dedicated core would fragment their silicon partner relationships.

The structural diversity is here to stay. FIDO2/WebAuthn and TPM 2.0 are how the two systems will continue to interoperate without converging on a single hardware architecture. That is fine. It is even, arguably, good -- a monoculture would be worse for security than a duopoly with different threat-model trade-offs.

Key idea: The interesting question for the next decade is not whether Apple or Microsoft picks a different silicon strategy. It is whether the cross-platform standards layer -- WebAuthn, TPM 2.0, FIDO2 -- evolves fast enough to expose new security primitives (post-quantum attestation, agent identity, owner-vetoable updates) before any one vendor ships proprietary equivalents.

11. Frequently asked questions

Pluton presents a TPM 2.0 personality to Windows -- so BitLocker, Windows Hello, Credential Guard, and TPM-aware enterprise tools work unchanged -- but it is also more than a TPM 2.0. It exposes Microsoft-rooted services beyond the TCG spec, accepts firmware updates through Windows Update rather than only OEM utilities, lives on the SoC die rather than the motherboard (closing the LPC sniffing attack class), and -- from 2024 -- runs a Rust-based firmware foundation on AMD and Intel platforms (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]). Two reasons. First, the SEP was designed before TPM 2.0 became the relevant cross-platform standard for Apple's product mix; SEP's API surface is bespoke to Apple's frameworks (`SecKey`, App Attest, LocalAuthentication, Keychain [@apple-keychain]). Second, exposing the SEP via TPM 2.0 would mean making the SEP usable from non-Apple operating systems on Apple hardware -- which is not how Apple ships its platforms. The SEP's lack of TPM 2.0 personality is a deliberate product decision, not a technical limitation. No -- not directly. Checkm8 (CVE-2019-8900) [@nvd-checkm8] exploits the SecureROM USB DFU stack on A5-A11 Apple SoCs and the T2 chip in 2018-2020 Intel Macs, giving an attacker with physical access application-processor code execution at boot. The SEP itself remains gated by the device passcode and the data-protection class keys (CERT/CC VU#941987 [@cert-checkm8]). The forensic value of checkm8 is the ability to mount passcode brute-force more effectively and access classes of data not bound to a passcode, not direct SEP-key extraction. Yes. The Pulse Security TPM-sniffing attack [@pulse-tpm-sniff] works because the discrete TPM returns the Volume Master Key over an external motherboard bus that an attacker can probe. Pluton lives on the SoC die; there is no external bus to attach probes to. The attack is structurally impossible against Pluton-rooted BitLocker. On laptops with discrete TPMs, the mitigation remains BitLocker with pre-boot PIN or USB key authentication. The published faulTPM attack [@faultpm] targets AMD's fTPM running in the AMD Platform Security Processor (PSP) on Zen 2 and Zen 3 CPUs, not Pluton specifically. However, Pluton-on-AMD is implemented atop the same PSP environment, so the underlying TEE is fault-attackable in principle. There is no publicly disclosed Pluton-targeted voltage-glitch attack as of May 2026 in the verified sources reviewed; whether Pluton's additional hardening blocks the fault-injection class is an open empirical question. For most purposes, no. FIDO2/WebAuthn [@fido-alliance] hides the difference at the API layer -- the same browser code talks to a SEP-backed credential on iOS/macOS and a Pluton-backed credential on Windows. You care about the difference when you need device-class attestation (Apple's App Attest vs Microsoft's Device Health Attestation), when privacy of the attestation key matters (Microsoft offers ECDAA-grade options via TPM 2.0; Apple offers per-installation keys), or when you need to support Linux on Apple Silicon (where neither path is available). Not in any current shipping commodity product. Apple devices ship SEP and no TPM 2.0; Windows devices ship Pluton, discrete TPM, or vendor fTPM but no SEP. The closest historical case is the Apple T2 chip in 2018-2020 Intel Macs [@apple-a-series]: the Mac ran macOS rooted at the T2 SEP, but if you booted Windows on the same hardware via Boot Camp, the T2 still provided the secure-boot anchor though Windows did not interact with it as a TPM.

12. Closing observation

There is a temptation, when comparing two designs as deeply considered as SEP and Pluton, to declare one the winner. Resist that temptation. The two architectures answer different questions for different markets, and the differences are exactly where each one shines. SEP is what you build when you own the silicon, the OS, and the patch channel. Pluton is what you build when you control the OS and the patch channel but need to ride on three other companies' silicon.

The closing observation worth keeping is the one Pulse Security demonstrated by accident: most hardware security failures are not failures of the math. They are failures of the physical placement and the patch flow. SEP and Pluton both close the historical bus-sniffing attack class. They both retain a slow channel for fault-injection research to chip away at. They both depend on the device owner trusting the vendor's signing infrastructure. The next big shift -- if it comes -- will probably be in who controls the patch channel, not in the silicon itself.

That is the bet to watch.

Direct Anonymous Attestation: The Zero-Knowledge Proof Already in Every TPM

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

**Direct Anonymous Attestation is the zero-knowledge proof your laptop already has -- and never uses.** Every TPM 2.0 specification since 2014 names a group-signature primitive called `TPM_ALG_ECDAA`, with a normative command pair (`TPM2_Commit`, `TPM2_Sign`) and a mandatory curve (`TPM_ECC_BN_P256`). A TPM with ECDAA enabled can prove "I am a genuine TPM whose endorsement key was certified by a known issuer" without revealing *which* TPM and without an online third party in the verification path. ISO/IEC 20008-2:2013 Mechanism 4 standardizes it. FIDO Alliance bound it to authenticator attestation in 2018. WebAuthn Level 1 registered ECDAA as an attestation type carried inside the `packed` and `tpm` attestation statement formats in March 2019. Three years later, WebAuthn Level 2 removed it entirely. The TCG PC Client Platform TPM Profile made `TPM_ALG_ECDAA` optional in February 2020. Microsoft Azure Attestation, Windows Health Attestation, AWS Nitro, Apple App Attest, and Google Play Integrity all use Privacy-CA-shaped broker flows instead. This article walks the thirty-year cryptographic lineage, the TPM 2.0 normative surface, the FIDO ECDAA failure, and the structural reasons Microsoft chose brokers over math.

1. A Billion Chips, Zero Verifiers

Every TPM 2.0 Library Specification published since 2014 names a zero-knowledge proof of knowledge. The algorithm identifier TPM_ALG_ECDAA (value 0x001A) appears in Part 2 (Structures). The command pair TPM2_Commit and TPM2_Sign appears in Part 3 (Commands). The mathematical construction appears in Part 1 Annex C.5. The mandatory curve is TPM_ECC_BN_P256 (0x0010), a 256-bit Barreto-Naehrig curve picked specifically because it admits the asymmetric pairings the protocol needs [@tpm-library-spec]. A conforming TPM 2.0 chip with ECDAA enabled can produce a signature that proves the chip is a genuine TPM whose endorsement key was certified by a known issuer -- without revealing which TPM, and without an online certificate authority sitting in the verification path. The cryptography is called Direct Anonymous Attestation, and the Wikipedia article notes that the construction is "implemented by both EPID 2.0 and the TPM 2.0 standard" [@wiki-daa].

Almost nobody uses it.

Microsoft Azure Attestation does not. Its public architecture document describes a certificate authority that ingests endorsement-key certificates and issues per-key JWTs with a special issuance policy [@azure-attestation]. The Windows Health Attestation Service does not. AWS Nitro Enclaves does not [@aws-nitro-attestation]. Apple App Attest does not [@apple-app-attest]. Google Play Integrity does not [@google-play-integrity]. WebAuthn Level 1 registered ECDAA as an attestation type carried inside the packed and tpm formats in March 2019; WebAuthn Level 2 in April 2021 removed it entirely [@webauthn-2]. The TCG PC Client Platform TPM Profile, the document that governs which TPM 2.0 algorithms an OEM must support to ship a Windows-class platform, made TPM_ALG_ECDAA and TPM_ALG_ECSCHNORR optional in v1.04 (February 2020) and has carried that designation through v1.07 RC1 (December 2025) [@tcg-ptp]. Microsoft Pluton's published surface, which enumerates the algorithms the security processor exposes through its TPM 2.0 personality, does not advertise ECDAA at all [@pluton].

The most thoroughly standardized hardware-anchored group-signature primitive in the history of platform security sits in firmware on a billion-plus machines and runs on almost none.

Why?

Key idea: Direct Anonymous Attestation solves the same problem as a Privacy-CA -- prove the TPM is genuine without disclosing which TPM -- by moving the trust assumption from operational (the broker promises not to log) to cryptographic (the math forbids the issuer from learning). The interesting question is not whether the cryptography works. It is why an industry that spent thirty years building the math chose, in production, the architecture the math was meant to replace.

This article walks the answer in four moves. Sections 2 through 5 reconstruct the cryptographic lineage: the Privacy-CA architecture DAA was invented against (TPM 1.1, 2003), the group-signature pre-history that made the construction possible (Chaum-van Heyst 1991 through Camenisch-Lysyanskaya 2004), the Brickell-Camenisch-Chen breakthrough at ACM CCS 2004, and the seven-year evolution to the elliptic-curve scheme TPM 2.0 actually ships (Chen-Page-Smart, CARDIS 2010). Sections 6 and 7 walk the normative surfaces: the TPM 2.0 ECDAA command surface and the ISO/IEC 20008-2 / 20009-2 standards. Sections 8 and 9 are case studies in non-deployment: FIDO's three-year experiment with ECDAA-in-WebAuthn, and Microsoft's two-decade commitment to broker-mediated attestation. Section 10 names the open problems -- post-quantum DAA, confidential computing, the One-TPM-to-Bind-Them-All fix that has not made it into TCG text. Section 11 closes with a role-keyed practical guide and an FAQ.

timeline title Direct Anonymous Attestation, 1991-2024 1991 : Chaum-van Heyst (EUROCRYPT) : Group signature defined 1997 : Camenisch-Stadler (CRYPTO) : Constant-size signatures 2000 : ACJT (CRYPTO) : Coalition resistance 2004 : Brickell-Camenisch-Chen (CCS) : Boneh-Boyen-Shacham short groupsigs 2005 : DAA-RSA added to TPM 1.2 rev 94 2007 : Brickell-Li EPID (WPES) : Signature-based revocation 2008 : Brickell-Chen-Li (TRUST) : First pairing DAA : CMS asymmetric DAA proposed 2010 : Chen-Li (IPL) : CMS proof flaw : Chen-Page-Smart (CARDIS) : The scheme TPM 2.0 ships 2013 : BFGSW (IJIS) : User-controlled linkability model : ISO/IEC 20008-2 / 20009-2 2014 : TPM 2.0 Library Spec : ECDAA in firmware 2015 : Smyth-Ryan-Chen : Retroactive BCC privacy bug 2018 : FIDO ECDAA v2.0 2019 : WebAuthn Level 1 : ecdaa attestation format 2020 : TCG PTP v1.04 : ECDAA made optional 2021 : WebAuthn Level 2 : ecdaa format removed 2024 : CoSNIZK : Lattice DAA at 38 kB

To answer the question of why, we have to start where every TPM attestation story does -- with the architecture DAA was invented to replace.

2. The Privacy-CA Trap (1999-2003)

TPM 1.1, originally published by the Trusted Computing Platform Alliance in 2002 and taken over in April 2003 by the Trusted Computing Group that replaced it [@wiki-tcg], had a privacy story. The story was a broker called the Privacy Certificate Authority. The story had a single load-bearing flaw, and the field spent the next two decades writing papers about it.

The mechanism, paraphrased from the Wikipedia summary that itself paraphrases the TCG spec, is five steps [@wiki-daa]:

A TPM manufacturer embeds a 2048-bit RSA Endorsement Key (EK) at the time the chip is provisioned, along with a certificate EKCert signed by the manufacturer [@wiki-tpm].
The platform generates a fresh Attestation Identity Key (AIK) inside the TPM.
The platform sends (EKCert, AIKpub, proof-of-binding) to a Privacy-CA.
The Privacy-CA validates the EK certificate, confirms the binding proof, and issues Cert(AIKpub) signed by the CA.
The platform uses the AIK to sign actual attestations -- platform configuration register quotes, boot logs, key-attestation certificates -- and presents Cert(AIKpub) to relying parties as proof that the AIK is TPM-resident.

The Endorsement Key is the long-lived, manufacturer-certified asymmetric key burned into the TPM at provisioning. Its public half is the chip's permanent cryptographic identity; its certificate, signed by the manufacturer, is the platform's proof that the chip is a real TPM. The Attestation Identity Key is a short-lived TPM-resident key generated for signing attestation outputs. Because the EK is uniquely identifying, the AIK exists to absorb attestation traffic on the EK's behalf: the EK certifies the AIK once (or once per Privacy-CA), and the AIK does the signing thereafter [@azure-attestation]. The broker introduced by the TCG in TPM 1.1 to separate the unique-by-design Endorsement Key from the per-attestation Attestation Identity Key. The Privacy-CA verifies the EK certificate, attests that the AIK is bound to a real TPM, and issues a certificate on the AIK that the platform then uses to sign quotes. The privacy property is operational, not cryptographic: the CA promises not to log the linkage between EK and AIK [@wiki-daa].

The architecture has three structural problems, and the Wikipedia summary of the original TPM 1.1 design makes the most uncomfortable one explicit: "privacy requirements may be violated if the privacy CA and verifier collude" [@wiki-daa]. The Privacy-CA can link AIKs to EKs. It promises not to. That promise is enforceable by audit, by legal contract, by reputation, and by the threat of a regulator finding out. It is not enforceable by mathematics.

The other two problems are availability and concentration. Wikipedia again, on the TPM 1.1 design: "the privacy CA must take part in every transaction" [@wiki-daa]. Every AIK certification is a synchronous network round-trip to a single CA. The CA is therefore a high-availability target, a high-value attack target, and a high-throughput service obligation for whoever decides to operate one. The FIDO Alliance, fifteen years later, wrote down the operational consequences of that obligation with surprising frankness in its ECDAA Algorithm v2.0 specification [@fido-ecdaa-v2]:

An alternative approach to 'group' keys is the use of individual keys combined with a Privacy-CA [TPMv1-2-Part1]. Translated to FIDO, this approach would require one Privacy-CA interaction for each Uauth key. This means relatively high load and high availability requirements for the Privacy-CA. Additionally the Privacy-CA aggregates sensitive information (i.e. knowing the relying parties the user interacts with). This might make the Privacy-CA an interesting attack target. -- FIDO ECDAA Algorithm v2.0 Implementation Draft, 2018

The FIDO document was written in 2018, but it is operating on a problem that was current in 2003. The Privacy-CA model concentrates the very identifiers it is supposed to anonymize. A regulator with a subpoena, an insider with a database query, or a successful attacker with persistent access can recover the linkage the CA promised to forget. In 2003 the TCG named the missing primitive -- a direct attestation scheme whose anonymity was guaranteed by math rather than a CA's promise -- and the cryptographic literature went to work on it.The privacy-advocate criticism of the TPM in the 2003-2005 window came from a small but well-placed group. Ross Anderson at Cambridge had been writing critical surveys of trusted computing since 2002, both in a continuously updated TCPA FAQ [@anderson-tcpa-faq] and in a PODC 2003 paper "Cryptography and Competition Policy -- Issues with Trusted Computing" [@anderson-tcpa-paper]. Seth Schoen and the Electronic Frontier Foundation published a 2003 white paper, "Trusted Computing: Promise and Risk," on the privacy implications of trusted-computing-class identifiers [@eff-schoen-2003]. European data-protection authorities had begun studying TCPA in the same window [@anderson-tcpa-faq]. The DAA construction was, by 2004, a research community answer to these criticisms more than it was a TCG product requirement.

The Privacy-CA architecture is still production architecture in 2026. Microsoft Azure Attestation runs a Privacy-CA in everything but name. Its public documentation describes a CA-mediated flow whose five-step shape mirrors the TPM 1.1 Privacy-CA almost line for line: "A certification authority (CA) establishes trust in the TPM either via EKPub or EKCert... The CA issues a certificate with a special issuance policy to denote that the key is now attested as protected by a TPM" [@azure-attestation]. The full verbatim Microsoft Learn quote is reproduced in §9, where it anchors the Windows case study.

The same pattern repeats across every hyperscaler. AWS Nitro Enclaves issues PKIX certificates rooted in AWS-operated CAs that bind enclave measurements to instance identifiers [@aws-nitro-attestation]. Apple App Attest issues per-app device identifiers from Apple-operated infrastructure [@apple-app-attest]. Google Play Integrity ships integrity verdicts signed by Google-operated infrastructure [@google-play-integrity]. In 2026 the operational descendants of TPM 1.1's Privacy-CA broker run the production attestation surface of every consumer-grade cloud platform.

By 2003 the field had a name for the missing primitive: a direct attestation scheme that delivered the Privacy-CA's anonymity property cryptographically rather than operationally. What followed was an academic lineage that had been quietly building, for a decade and a half, the primitives that lineage required.

3. The Pre-History: Group Signatures Before DAA (1991-2003)

Direct Anonymous Attestation was invented in 2004. The primitive it was built from was invented in 1991, in a paper that had nothing to do with TPMs.

David Chaum and Eugene van Heyst presented "Group Signatures" at EUROCRYPT 1991 [@chaum-vh-1991]. The construction was a curiosity: a digital signature scheme in which any one of n group members could sign on behalf of the group, the verifier could check that some member of the group signed, and a designated group manager could, given a signature, recover the identity of the signer. The use case Chaum and van Heyst had in mind was organizational: a company spokesperson signs press releases on behalf of the company; the CEO can, if necessary, recover which spokesperson signed which release.

A digital signature scheme in which any one of `n` group members can sign on behalf of the group such that (i) verifiers can confirm "some member of the group signed this message" using a single group public key, (ii) verifiers cannot determine which member signed, and (iii) a designated group manager, holding a trapdoor, can *open* any signature to recover the original signer. Chaum and van Heyst introduced the primitive in 1991; the next decade was about making the construction efficient enough to deploy [@wiki-group].

The 1991 construction had a fatal practical property: signature size was linear in the size of the group. A 10,000-member group meant a 10,000-component signature. For a primitive intended to handle organizational use cases at organizational scale, this was a non-starter. The next decade is a sequence of papers, each adding one property to the previous, each addressing the issue that made the previous unfit for deployment.

Jan Camenisch and Markus Stadler, at CRYPTO 1997, gave the field its first constant-size group signature -- signature length independent of the number of group members, suitable for groups of arbitrary size [@camenisch-stadler-1997]. Their construction relied on a particular kind of zero-knowledge proof of knowledge of a discrete logarithm whose form would, six years later, become the structural template for DAA's Sign protocol. The CS97 scheme had its own problems -- the security proof made strong assumptions, and the construction was vulnerable to "framing" attacks where a malicious group manager could forge signatures attributable to other members -- but the size barrier was broken.

Three years later, at CRYPTO 2000, Giuseppe Ateniese, Jan Camenisch, Marc Joye, and Gene Tsudik introduced what the field now calls the ACJT scheme [@acjt-2000]. The Springer abstract is unusually direct about what ACJT contributed: the paper "introduces a new provably secure group signature... proven secure and coalition-resistant under the strong RSA and the decisional Diffie-Hellman assumptions." The property that made ACJT important was coalition resistance -- a formal guarantee that no subset of k group members, no matter how large, could collude to produce a valid signature that did not open to one of them. ACJT's security proofs were the first in the group-signature literature to treat coalitions as a first-class threat model.Coalition resistance as a property predated ACJT, but coalition resistance as a formal property -- something proven against an adversary defined in a complexity-theoretic model -- did not. Camenisch and Michels in 1998, and several authors in between, had given coalition-resistance arguments that depended on heuristic assumptions about the underlying hash function or signature scheme [@camenisch-michels-1998]. ACJT 2000 gave the proof under the strong RSA assumption, which by 2000 was a well-understood number-theoretic conjecture that the cryptographic community treated as a load-bearing security primitive.

ACJT was the construction the DAA designers built on. The reason is in its protocol structure. The ACJT signer holds a signed credential on a secret membership value f. Signing a message means producing a non-interactive zero-knowledge proof of knowledge of (f, signature) satisfying the group manager's verification equation, bound to the message. The proof is constant-size; the verifier checks it against the group public key and learns only that some member signed.

Jan Camenisch and Anna Lysyanskaya, working in parallel, were building the other primitive DAA would need. Their EUROCRYPT 2001 paper introduced what the field now calls CL credentials -- a digital signature scheme with two unusual properties [@cl-2001]. First, a signer can issue a signature on a committed value Commit(f) without seeing f itself, so the holder of f ends up with a signature on something the signer never learned. Second, a holder of (f, signature) can prove possession of that pair in zero knowledge, revealing neither f nor the signature itself.

A digital signature scheme with two algorithmic protocols on top of the standard sign-and-verify pair. A *blind issuance* protocol lets a signer issue a signature on a value the signer cannot see (the holder commits to a value `f` and proves the commitment well-formed; the signer signs the commitment without learning `f`). A *proof-of-possession* protocol lets a holder of `(f, signature)` prove "I have a CL signature from this signer on some value" without revealing either the value or the signature. CL signatures are the primitive a DAA Issuer uses to issue the long-lived attestation credential the TPM keeps after the Join protocol [@cl-2001] [@cl-2004].

CL signatures gave the field a clean way to issue a member credential without the issuer ever learning the member's secret -- exactly the property a TPM needs when receiving a long-lived DAA credential from an issuer who, by design, must remain unable to recognize the TPM later. Camenisch and Lysyanskaya's CRYPTO 2004 paper extended the construction to bilinear pairings [@cl-2004], a generalization that would matter for the elliptic-curve DAA schemes of the next decade.

flowchart LR A["Chaum-van Heyst 1991
Primitive defined
Linear-size signatures"] --> B["Camenisch-Stadler 1997
Constant-size signatures"] B --> C["ACJT 2000
Coalition resistance
Strong RSA + DDH"] C --> D["Brickell-Camenisch-Chen 2004
DAA-RSA"] A --> E["Camenisch-Lysyanskaya 2001
Blind issuance
Proof of possession"] E --> D E --> F["Camenisch-Lysyanskaya 2004
CL on bilinear pairings"] F --> G["Chen-Page-Smart 2010
EC-DAA"]

A sibling lineage was building in parallel. Dan Boneh, Xavier Boyen, and Hovav Shacham presented "Short Group Signatures" at CRYPTO 2004 [@bbs-2004]. The BBS scheme used bilinear pairings to compress group signatures to a few hundred bytes -- signatures, in the abstract's words, "approximately the size of a standard RSA signature with the same security." BBS gave the W3C Verifiable Credentials community a primitive that descendants like BBS+ would later use for selective-disclosure credentials. BBS itself did not become the TPM construction. The DAA designers, working from ACJT and CL, took a different path.

By 2003 the primitives existed. The TPM community had the use case. The two communities had not yet met. In 2004, three authors at three different industrial labs made the introduction.

4. The Breakthrough: DAA-RSA (Brickell-Camenisch-Chen, CCS 2004)

The introduction happened at ACM CCS 2004. Ernie Brickell at Intel, Jan Camenisch at IBM Zurich, and Liqun Chen at HP Labs Bristol published "Direct Anonymous Attestation" [@bcc-2004]. The IACR ePrint abstract makes the structural contribution explicit:

Direct anonymous attestation can be seen as a group signature without the feature that a signature can be opened, i.e., the anonymity is not revocable. Moreover, DAA allows for pseudonyms, i.e., for each signature a user (in agreement with the recipient of the signature) can decide whether or not the signature should be linkable to another signature. DAA furthermore allows for detection of 'known' keys: if the DAA secret keys are extracted from a TPM and published, a verifier can detect that a signature was produced using these secret keys. -- BCC 2004 (IACR ePrint 2004/205)

Two design moves did the work, and naming them clearly is the first step in understanding why DAA solved the Privacy-CA problem.

The first move is a subtraction. Every prior group-signature scheme -- Chaum-van Heyst, Camenisch-Stadler, ACJT, BBS -- gave a designated group manager the power to open a signature and recover its signer. For a TPM attestation primitive, the opening capability is undesirable. An issuer who can open is morally a Privacy-CA: it has the linkage information the architecture is supposed to forget. BCC 2004 removes the opening capability entirely. No party can de-anonymize a signature -- not the issuer, not the verifier, not a coalition of either. The IACR ePrint 2004/205 abstract captures the consequence: DAA "can be seen as a group signature without the feature that a signature can be opened, i.e., the anonymity is not revocable" [@bcc-2004]. Once the credential is issued, the issuer has no cryptographic handle left to break the user's privacy.

A zero-knowledge attestation primitive in which a TPM holds a long-lived membership credential (the output of a one-time Join protocol with an Issuer) and can subsequently produce signatures that prove "the signing TPM holds a credential certified by this Issuer" without revealing which TPM signed and without an online third party in the verification path. No party -- not the Issuer, not the Verifier, not a coalition of either -- can de-anonymize a DAA signature. The construction first appeared in Brickell-Camenisch-Chen 2004 [@bcc-2004].

The second move is a substitution. Where prior schemes traced misbehaving signers by manager-controlled opening, DAA introduces a user-controlled linkability mechanism through what the BCC paper calls a basename-keyed pseudonym. The signing TPM holds a secret membership value f. The verifier supplies a basename bsn (a string the verifier picks per session, per relying party, or per global epoch). The TPM derives a pseudonym

$$N_V = \zeta^f \pmod \Gamma, \qquad \zeta = H_\Gamma(\text{bsn})$$

where H_Γ hashes the basename into a generator of a multiplicative group Γ. The pseudonym N_V has two structural properties. If the same verifier reuses the same bsn across sessions, signatures from the same TPM produce the same N_V, so the verifier can link them (and blacklist them if needed). If the verifier randomizes bsn per session, or sets bsn to the special value ⊥ indicating "no linkability," signatures from the same TPM produce different N_V values that are indistinguishable from random.

A DAA property in which the *verifier* chooses a basename `bsn` per session or per relying party. Signatures from the same TPM under the same basename produce the same pseudonym; signatures under different basenames produce pseudonyms indistinguishable from random. The TPM, not a group manager, controls which signatures are linkable to which others. The Bernhard-Fuchsbauer-Ghadafi-Smart-Warinschi 2013 paper gives the canonical formal model [@bfgsw-2013].

Together the subtraction and the substitution define the DAA contract. The Issuer issues a CL signature on the TPM's secret f during a one-time Join. The TPM thereafter holds the credential (f, A, e, v) -- the secret membership value plus the CL signature components. To sign a message m against a verifier-supplied basename bsn, the TPM:

Computes the pseudonym N_V = ζ^f mod Γ where ζ = H_Γ(bsn).
Randomizes the CL signature: picks a fresh w, computes T_1 = A · S^w mod n and T_2 = g^e · h^w mod n.
Produces a Fiat-Shamir non-interactive zero-knowledge proof of knowledge of (f, A, e, v, w) satisfying the CL verification equation

$$A^e \equiv Z / (R^f \cdot S^{v' + v''}) \pmod n,$$

binding the proof to the tuple (m, T_1, T_2, N_V).

A verifier checks the proof against the Issuer's public key. The verifier learns nothing about f, nothing about the TPM's identity, nothing about which CL signature was randomized -- and either gains a linkable pseudonym (if bsn was reused) or no linkability at all (if bsn was fresh).

The architectural picture, set against §2's Privacy-CA flow, makes the contrast vivid.

flowchart TD I["Issuer
(holds CL signing key)"] T["TPM
(holds secret f)"] V["Verifier
(holds Issuer pub key)"] I -.->|"one-time Join
CL signature on f
(blind, issuer never sees f)"| T T -->|"credential (f, A, e, v)
stored in TPM forever"| T T -->|"DAA-Sign(m, bsn)
= randomized credential + NIZK + N_V"| V V -->|"Verify against Issuer pub key
(no online interaction)"| V

This is the first aha. The reader entered §3 thinking "anonymity with manager-controlled traceability" was the goal of group signatures. They exit §4 understanding that for TPM attestation the goal is anonymity without any opener plus user-controlled, per-verifier linkability. The breakthrough is structurally a subtraction (remove the opener) plus a substitution (per-verifier basename pseudonyms in place of manager-controlled opening). It is not an addition.Eleven years after BCC 2004, Ben Smyth, Mark Ryan, and Liqun Chen ran a formal analysis of the original BCC construction and found a retroactive privacy bug [@smyth-ryan-chen-2015]. The bug allowed certain Issuer-coalition adversaries to link signatures across basenames in ways the original security argument had not anticipated. The bug was fixed in the 2008-2010 redesigns (specifically the BCL 2009 simplified-security-notions paper [@bcl-2009] and the CDL 2016 strong-Diffie-Hellman revisitation). The reader interested in why "we proved this in 2004" is not the same as "this is provably secure in 2026" should read SRC 2015 alongside the original BCC abstract.

On paper, the BCC 2004 construction solved the Privacy-CA trap. In practice, DAA-RSA was hard to ship. The CL signature in the original scheme used strong RSA moduli at 2048 bits. A single Sign operation took several seconds on the TPM 1.2 hardware of the time. The signature itself was approximately 2.5 kilobytes -- larger than the entire AIK signature output a Privacy-CA-mediated attestation produced. TPM 1.2 shipped DAA-RSA as an optional capability when revision 94 of the spec added it in 2005 [@tpm-library-spec]. Almost no platform integrator turned it on. The cryptography worked. The implementation budget did not.

The next decade was about making the construction small enough to deploy. The path was anything but straight.

5. The Evolution: From RSA-DAA to EC-DAA (2007-2013)

Six papers in seven years, two industrial branches, one dead end, one production scheme. Why was the EC-DAA story so much harder than it should have been?

The honest answer: the entire toolkit of pairing-based cryptography arrived at the same time the TPM industry needed it, and the field discovered in real time that not every choice of pairing was safe. The path from BCC 2004 to the construction the TPM 2.0 spec actually shipped runs through five waypoints, each addressing the problem the previous one created.

5.1 Brickell-Li 2007: EPID and signature-based revocation

In 2007 Ernie Brickell, now leading Intel's trusted-computing work, and Jiangtao Li published "Enhanced Privacy ID: A Direct Anonymous Attestation Scheme with Enhanced Revocation Capabilities" at WPES 2007 [@brickell-li-epid-2007]. The journal version appeared at IEEE TDSC in 2012 [@brickell-li-tdsc-2012]. The single feature EPID added was a revocation list called Sig-RL: a list of signatures the issuer wished to disavow. A verifier, given a signature σ and a Sig-RL containing entries σ_1, ..., σ_k, could prove that σ was not produced by the same TPM as any σ_i -- without learning the linking information itself.

EPID became Intel's production attestation primitive. Wikipedia records the deployment scale: "It has been incorporated in several Intel chipsets since 2008," and "at RSAC 2016 Intel disclosed that it has shipped over 2.4B EPID keys since 2008" [@wiki-epid]. EPID is what Intel SGX enclaves used to attest, before SGX attestation migrated to the vendor-CA DCAP architecture. EPID is what certain Intel-platform Widevine L1 implementations use to attest content-decryption modules. The Intel EPID SDK (the reference implementation) was eventually marked public-archive on GitHub [@epid-sdk]. The Wikipedia entry notes that the original EPID 2.0 specification was contributed by Intel into ISO/IEC 20008 and 20009 under royalty-free terms [@wiki-epid].

EPID is not exactly DAA. EPID is a DAA variant with the Sig-RL revocation layer added. The Chen-Page-Smart construction that TPM 2.0 actually ships is closer to BCC 2004 plus an elliptic-curve substrate; EPID 2.0 is closer to BCC 2004 plus EC plus Sig-RL plus Intel's specific basename and key-management conventions. The two converge at the cryptographic core and diverge at the deployment surface.

5.2 Brickell-Chen-Li 2008: the first pairing-based DAA

At the TRUST 2008 conference, Ernie Brickell, Liqun Chen, and Jiangtao Li published "A New Direct Anonymous Attestation Scheme from Bilinear Maps" -- the first DAA scheme constructed over bilinear pairings instead of strong RSA [@bcl-2008]. Signature size dropped by an order of magnitude relative to BCC 2004, from roughly 2.5 kilobytes to a few hundred bytes [@bcl-2008]. TPM-side sign time, on hardware that supported elliptic-curve arithmetic, came down from seconds to fractions of a second [@bcl-2008]. The construction used symmetric (Type-1) pairings -- pairings where the two input groups G_1 and G_2 are the same -- which the implementation community would, two or three years later, decide were too inefficient for production TPM hardware.

A function `e : G_1 × G_2 -> G_T` on three elliptic-curve subgroups satisfying *bilinearity* (for all integers `a, b` and points `P ∈ G_1, Q ∈ G_2`, `e(aP, bQ) = e(P, Q)^(ab)`) and *non-degeneracy*. Type-3 (asymmetric) pairings, in which `G_1 ≠ G_2` and no efficient homomorphism is known between them, are the production pairing for TPM 2.0 ECDAA because they admit faster implementations and tighter security reductions than Type-1 (symmetric) pairings. The Chen-Page-Smart 2010 construction is built on Type-3 pairings over Barreto-Naehrig curves [@cps-2010].

5.3 Chen-Morrissey-Smart 2008: the asymmetric proposal and its proof flaw

Pairing 2008 hosted the next move. Liqun Chen, Paul Morrissey, and Nigel Smart published "Pairings in Trusted Computing" [@cms-pairing-2008], proposing a DAA scheme on asymmetric Type-3 pairings -- the kind that admit Barreto-Naehrig curves and the speed-ups TPM hardware needed. The same authors published a companion ProvSec 2008 paper "On Proofs of Security for DAA Schemes" providing the security argument [@cms-provsec-2008].

Two years later, in Information Processing Letters, Liqun Chen and Jiangtao Li published "A note on the Chen-Morrissey-Smart Direct Anonymous Attestation scheme" [@chen-li-2010] showing that the CMS asymmetric-pairing construction had a flawed proof. The cryptographic intuition was correct; the proof technique used an assumption that did not hold in the asymmetric-pairing setting the construction relied on.The Chen-Morrissey-Smart episode is, in 2026, one of the most cited proof-flaw stories in pairing-based cryptography precisely because the construction was simple and the flaw was subtle. The mathematical content of the scheme was salvageable. The security argument was not. The lesson the field took away -- a proof in the symmetric-pairing model does not transfer to the asymmetric-pairing model without a separate argument -- has been a load-bearing convention in cryptographic publishing since.

5.4 Chen-Page-Smart 2010: the scheme TPM 2.0 actually ships

The fix arrived at CARDIS 2010 in Passau in April 2010 [@cardis-book]. Liqun Chen, Dan Page, and Nigel Smart published "On the Design and Implementation of an Efficient DAA Scheme" [@cps-2010] [@cps-2010-eprint], proposing an asymmetric-pairing DAA over Barreto-Naehrig curves with a Sign protocol split between the TPM and the host. The TPM, in the new design, performed only the cryptographic operations that absolutely required custody of the secret f: it produced commitment points and computed a Schnorr-style response over those commitments. The host -- a comparatively powerful general-purpose CPU sitting in front of the TPM -- composed the Fiat-Shamir challenge, performed the pairing computations, and assembled the final signature.

The Chen-Page-Smart construction is the scheme TPM 2.0 actually ships. The Wikipedia DAA article makes the attribution direct, in a sentence that is itself the most-cited single primary-source extract in this article:

Chen, Page, and Smart proposed a new elliptic curve cryptography scheme using Barreto-Naehrig curves. This scheme is implemented by both EPID 2.0 and the TPM 2.0 standard. -- Wikipedia, *Direct Anonymous Attestation* [@wiki-daa] A family of pairing-friendly elliptic curves with embedding degree 12, parameterized by an integer `u` to admit Type-3 pairings whose arithmetic is fast enough for resource-constrained devices [@bn-2006]. The curve identifier `TPM_ECC_BN_P256` (`0x0010`) is the specific 256-bit instance the TPM 2.0 Library Specification mandates for ECDAA, picked because of its pairing-friendly structure rather than as a NIST P-256 equivalent.

Six years after CPS 2010, Taechan Kim and Razvan Barbulescu (CRYPTO 2016) published "Extended Tower Number Field Sieve: A New Complexity for the Medium Prime Case," giving an improved sieve attack against pairing-friendly elliptic curves at the 256-bit BN level. The improvement dropped the practical security of BN-256 from roughly 128 bits to roughly 100 bits [@kim-barbulescu-2016]. The TCG normative text for TPM 2.0 ECDAA did not, as of late 2025, change the mandatory curve in response. This is the kind of cryptographic technical debt that lives quietly in deployed systems for a decade -- specs do not migrate on the same calendar as research moves.

5.5 BFGSW 2013 and SRC 2015: the formal closure

The cryptographic engineering of EC-DAA was done by 2010. What the field still owed itself was a clean security model: one definition of "secure DAA" that captured the user-controlled-linkability property and the TPM/host split, against which any candidate scheme could be evaluated.

In 2013 David Bernhard, Georg Fuchsbauer, Essam Ghadafi, Nigel Smart, and Bogdan Warinschi published "Anonymous attestation with user-controlled linkability" in the International Journal of Information Security [@bfgsw-2013] [@bfgsw-2013-eprint]. The BFGSW paper formalized the user-controlled-linkability property the BCC 2004 abstract had described in prose, introduced a clean separation of "pre-DAA signing" (TPM-side operations) from "DAA signing" (TPM + host composition), and proved the security of a representative construction in the resulting model.

In 2015, Ben Smyth, Mark Ryan, and Liqun Chen published the retroactive analysis that closed the BCC 2004 privacy bug [@smyth-ryan-chen-2015]. By 2015 the cryptography was, formally, settled.

In 2016 Jan Camenisch, Manu Drijvers, and Anja Lehmann revisited the construction at TRUST 2016 in "Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited" [@cdl-2016] [@cdl-2016-eprint], giving a tighter security argument under the q-SDH assumption and providing a fix for a Diffie-Hellman-oracle issue in the TPM 2.0 ECDAA interface that "One TPM to Bind Them All" would document in 2017 [@one-tpm-2017]. The CDL16 scheme is what most modern DAA library code references as the canonical construction.

flowchart LR BCC["BCC 2004
RSA-DAA
TPM 1.2"] --> BL["Brickell-Li 2007
EPID + Sig-RL
Intel SGX / Widevine"] BCC --> BCL["BCL 2008
Type-1 pairing DAA"] BCL --> CMS["CMS 2008
Asymmetric pairing
(broken by CL 2010)"] BCL --> CPS["CPS 2010
Type-3 BN-curve DAA
TPM 2.0 ECDAA"] CPS --> BFGSW["BFGSW 2013
Formal user-controlled
linkability model"] BFGSW --> CDL["CDL 2016
q-SDH revisitation
Canonical modern DAA"] BCC --> SRC["SRC 2015
Retroactive BCC
privacy bug"]

By 2013 the cryptography was complete. The standards organizations took the construction and made it official -- in two different specifications, on two parallel tracks.

6. The TPM 2.0 ECDAA Surface (2014-Present)

If you own a Windows laptop with a TPM 2.0, this section is the part of the chip you have never used. What does the spec actually say?

The TPM 2.0 Library Specification, the canonical document published by the Trusted Computing Group, is a four-part normative reference [@tpm-library-spec]. Part 1 (Architecture) describes the threat model and the mathematical primitives. Part 2 (Structures) defines the data types every TPM command accepts and returns. Part 3 (Commands) defines the commands themselves. Part 4 (Supporting Routines) gives a reference C implementation. The ECDAA surface lives across all four parts.

An algorithm identifier defined in TPM 2.0 Library Specification Part 2 and selectable from any `TPMT_SIG_SCHEME` field. A signing key tagged with `TPM_ALG_ECDAA` produces signatures using the Chen-Page-Smart 2010 elliptic-curve DAA construction. The same algorithm identifier appears in any signature-scheme negotiation point in the TPM 2.0 command surface [@tpm-library-spec]. The 256-bit Barreto-Naehrig curve identifier the TPM 2.0 Library Specification mandates for any ECDAA-capable signing key. BN-P256 is *not* NIST P-256: it is a pairing-friendly curve with embedding degree 12 whose group structure admits the Type-3 pairings the DAA verification equation requires. Implementations that confuse the two will produce signatures that verify against the wrong group. The command pair defined in TPM 2.0 Library Specification Part 3 that implements the Chen-Page-Smart 2010 split-protocol structure. `TPM2_Commit(keyHandle, P1, s2, y2)` returns commitment points `(K, L, E)` plus a `counter`. The host then computes the Fiat-Shamir challenge `c` over the message and the commitment points. `TPM2_Sign(keyHandle, digest, scheme=TPM_ALG_ECDAA, validation)` returns the Schnorr-style response `s = r + c·f mod p`. The host assembles the final signature from the commitment points, the challenge, and the response [@tpm-library-spec].

The protocol split matters. The TPM, in the CPS 2010 construction, holds the secret f and must perform exactly two cryptographic operations on it: produce a freshly randomized commitment to f (via TPM2_Commit), and produce a Schnorr response that proves knowledge of f modulo the verifier's challenge (via TPM2_Sign). Everything else -- the pairing computations, the curve arithmetic in G_T, the Fiat-Shamir hash, the final signature assembly -- happens on the host CPU. This is the only reason the construction is practical on a TPM. A monolithic Sign that did pairing arithmetic inside the chip would be unshippable; the split offloads the expensive operations onto silicon that has them for free.

Note: The most common implementer mistake when working with TPM 2.0 ECDAA for the first time is to reuse the NIST P-256 ECDSA code path with the curve identifier swapped. The two curves share a bit length and a hash function and otherwise nothing. BN-P256 has a pairing-friendly group structure with embedding degree 12; NIST P-256 does not admit efficient pairings at all. Signatures produced by ECDSA over NIST P-256 will not verify against an ECDAA verifier expecting BN-P256, and the converse is true. The pairing requirement is what forces the BN curve choice; treat BN-P256 as a separate primitive with a separate code path.

The Join protocol -- the one-time exchange between the Issuer and the TPM that produces the long-lived credential -- piggybacks on a TPM 2.0 command pair already present in every Windows attestation flow: TPM2_MakeCredential and TPM2_ActivateCredential [@tpm-library-spec]. The Issuer wraps the DAA credential under an encryption key derived from the TPM's Endorsement Key, ensuring that only the legitimate TPM (the one that holds the EK private key) can decrypt the credential and bind it to its internal f.The choice of TPM2_ActivateCredential as the Join anchor is convenient. The same primitive that TPM 2.0 attestation-key certification flows use for AIK-binding gets reused for DAA-credential binding. An OEM that supports TPM2_ActivateCredential for ordinary AIK enrollment already has 80% of the firmware path the Join protocol needs. The difference is in what the Issuer ships back -- a per-TPM AIK certificate in the AIK case, an Issuer-randomized CL credential in the DAA case.

Part 1 Annex C.5 contains the informative mathematical description -- the actual ECDAA verification equation, the basename-pseudonym derivation, the proof-of-knowledge template. Part 3 contains the normative command definitions. An implementer who reads only the Part 3 command definitions without reading Annex C.5 will have correct byte-buffer-level semantics and no idea what the protocol is computing; an implementer who reads only Annex C.5 without the normative command definitions will have correct math and the wrong API.

The implementation surface, gathered into one place:

Artifact	Identifier / location	Source
Algorithm selector	`TPM_ALG_ECDAA = 0x001A`	TPM 2.0 Library Specification Part 2 [@tpm-library-spec]
Mandatory curve	`TPM_ECC_BN_P256 = 0x0010`	Part 2 [@tpm-library-spec]
First-round command	`TPM2_Commit(keyHandle, P1, s2, y2) -> (K, L, E, counter)`	Part 3 [@tpm-library-spec]
Second-round command	`TPM2_Sign(keyHandle, digest, scheme=TPM_ALG_ECDAA, validation) -> signature`	Part 3 [@tpm-library-spec]
Join anchor	`TPM2_MakeCredential` / `TPM2_ActivateCredential`	Part 3 [@tpm-library-spec]
Math description	Part 1 Annex C.5 (informative)	Part 1 [@tpm-library-spec]
Optionality status	Optional since PTP v1.04 (Feb 2020); carried through v1.07 RC1 (Dec 2025)	TCG PC Client Platform TPM Profile changelog [@tcg-ptp]

sequenceDiagram participant V as Verifier participant H as Host (CPU) participant T as TPM V->>H: send basename bsn H->>T: TPM2_Commit(keyHandle, P1, s2, y2) T-->>H: (K, L, E, counter) H->>H: compute c = H(K, L, E, message, bsn) H->>T: TPM2_Sign(keyHandle, digest=c, scheme=ECDAA) T-->>H: response s = r + c*f mod p H->>H: assemble signature (K, L, E, c, s) H->>V: ECDAA signature V->>V: verify pairing equation

The TCG published the TPM 2.0 Library Specification in 2014. From 2014 through early 2020, the PC Client Platform TPM Profile -- the document that says "to ship a TPM 2.0 in a PC-class device, these algorithms must be present" -- listed TPM_ALG_ECDAA as mandatory-if-the-platform-supports-elliptic-curve-cryptography. In v1.04 (released February 2020) the TCG PTP working group made a quiet but consequential change. The changelog records the line verbatim: "Made TPM_ALG_ECDAA and TPM_ALG_ECSCHNORR optional." The same designation has carried through v1.06 RC1 (January 2025) and v1.07 RC1 (December 2025) [@tcg-ptp]. After February 2020, an OEM can ship a Windows-class TPM 2.0 platform that does not implement ECDAA at all and remain conformant.

Note: The Trusted Computing Group's resource pages (trustedcomputinggroup.org/resource/tpm-library-specification/ and trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/) reject non-browser User-Agents at the HTTP layer. This is a long-standing anti-bot policy. Citations in this article to the TPM 2.0 Library Specification and to the PC Client Platform TPM Profile point to the canonical URLs but are flagged in the verified-source registry as UNVERIFIED_FETCH; the verbatim changelog text was extracted under primary-source rules during the Stage 0a focus-premise audit and is the audit-of-record for the optionality claim. The downstream accuracy and fact-check stages of this pipeline carry the same caveat forward.

The Pluton question is the second hedge. Microsoft Pluton is the security processor Microsoft has been shipping in successive Windows-class platforms since AMD's Ryzen 6000 in 2022, in AMD Ryzen 7040 (Phoenix) in 2023, in Qualcomm Snapdragon X Elite in 2024, and in Intel Core Ultra (Meteor Lake, December 2023; Lunar Lake, September 2024) and successive Intel Core Ultra generations. Pluton exposes a TPM 2.0 personality. The Microsoft Learn documentation page enumerates the cryptographic algorithms the processor exposes and the platform-security primitives it implements [@pluton].

The page contains zero occurrences of ECDAA or TPM_ALG_ECDAA. The honest framing here is not "Pluton does not implement ECDAA" -- the documentation neither confirms nor denies it -- but "Pluton's published surface does not advertise ECDAA." That is the hedged statement this article carries from its opening to its FAQ.

The runnable demonstration below is educational -- Microsoft ships no BCryptDirectAnonymousAttestation, no NCryptDaaSign, no Windows API at all that exposes ECDAA from a user-mode application. The code shows the logic an admin or platform engineer would follow when probing a TPM's reported algorithm set, not a working call against any shipping Windows API.

{` // Logic only. Microsoft ships no Windows API that surfaces TPM_ALG_ECDAA. // In practice an admin would parse the output of Get-TpmEndorsementKeyInfo // or use a vendor-specific tool to inspect the TPM's algorithm capability table. const TPM_ALG_ECDAA = 0x001A; const TPM_ECC_BN_P256 = 0x0010;

function probeECDAA(tpmAlgList, tpmEccCurveList) { const hasECDAA = tpmAlgList.includes(TPM_ALG_ECDAA); const hasBN256 = tpmEccCurveList.includes(TPM_ECC_BN_P256); if (!hasECDAA) return 'no ECDAA: chip omits algorithm 0x001A'; if (!hasBN256) return 'ECDAA without BN-P256: nominally compliant, practically unusable'; return 'ECDAA + BN-P256 present (Join still requires Issuer infrastructure)'; }

// Example: a Pluton-class chip whose published surface does not advertise ECDAA. const plutonLike = [0x0001 /* RSA /, 0x0008 / SHA-256 /, 0x0023 / ECDSA /]; console.log(probeECDAA(plutonLike, [0x0003 / NIST P-256 */])); // -> "no ECDAA: chip omits algorithm 0x001A"

// Example: a discrete Infineon SLB9670 TPM 2.0 (vendor docs list ECDAA + BN-P256). const discreteTpm = [0x0001, 0x0008, 0x0023, TPM_ALG_ECDAA]; console.log(probeECDAA(discreteTpm, [0x0003, TPM_ECC_BN_P256])); // -> "ECDAA + BN-P256 present (Join still requires Issuer infrastructure)" `}

The spec was written. The chips shipped. The TCG was satisfied. So why does no one verify ECDAA signatures?

7. The Standards Bridge: ISO/IEC 20008 and 20009

There is a difference between a TCG specification section number and an ISO/IEC mechanism identifier. The difference is the price of admission to a Common Criteria protection profile and to most government procurement contracts.

ISO/IEC 20008 is the international-standards anchor for anonymous digital signatures. It comes in three parts. Part 1 ("General") sets the framework and terminology [@iso-20008-1]. Part 2 ("Mechanisms using a group public key") catalogues the specific anonymous-signature schemes the international community has standardized -- and Mechanism 4 is the EPID-derived elliptic-curve DAA construction that aligns with the TPM 2.0 ECDAA surface [@iso-20008-2]. Part 3 ("Mechanisms using multiple public keys") catalogues a different family of schemes that is not the focus of this article.

The international-standards series titled "Information technology -- Security techniques -- Anonymous digital signatures." Part 1 (general framework) and Part 2 (mechanisms using a group public key) were both published in 2013. Mechanism 4 in Part 2 standardizes EPID-derived elliptic-curve DAA. ISO/IEC 20008 is the bibliographic anchor cited by Common Criteria protection profiles, FIPS 140-3 module-validation evidence, and government procurement specifications that need to reference a *named, internationally agreed* anonymous-signature mechanism rather than a vendor-specific construction [@iso-20008-2].

A note on the title. Earlier drafts of this article carried the title of ISO/IEC 20008-2 as "anonymous signatures with message recovery." That phrasing belongs to a different standard, ISO/IEC 9796. The verified ISO catalogue title for 20008-2 is, verbatim, "Information technology -- Security techniques -- Anonymous digital signatures -- Part 2: Mechanisms using a group public key" [@iso-20008-2].

ISO/IEC 20009 is the companion standard for authentication. Where 20008 standardizes signatures, 20009 standardizes the challenge-response protocols that wrap signatures into entity-authentication exchanges. Part 2 ("Mechanisms based on signatures using a group public key") is where TPM-style attestation lives in ISO terminology [@iso-20009-2]. A FIDO authenticator or a TPM-backed Kerberos client that performs an attested authentication is, in ISO-speak, executing a 20009-2 mechanism that wraps a 20008-2 signature.

Intel held patents on the EPID construction. In contributing the EPID 2.0 algorithm to ISO/IEC 20008 and 20009, Intel made the underlying intellectual property available under royalty-free (RAND-Z) terms. The Wikipedia EPID article records the contribution and notes that EPID "complies with international standards ISO/IEC 20008 / 20009" [@wiki-epid]. The licensing structure mattered: it is what made the construction acceptable to the FIDO Alliance, to the TCG for the TPM 2.0 ECDAA surface, and to the European procurement community whose conformance regimes treat royalty-bearing cryptographic primitives differently from royalty-free ones. Exact licensing-event dates are not directly indexed in publicly fetchable Intel materials; this paragraph is inference-grade reconstruction from the Wikipedia citation chain.

The procurement reason ISO standardization mattered is structural. A Common Criteria Protection Profile cannot, in the general case, reference a TCG specification section number. It can reference an ISO mechanism identifier. The Federal Information Processing Standards 140-3 evidence package for a cryptographic module must, in many cases, demonstrate that the cryptographic primitives the module implements are members of an internationally recognized standard family. The European Cyber Resilience Act, drafted in 2024 and applicable in stages from 2027 onward, treats compliance with a recognized international standard as one of the routes to a presumption of conformity. ISO/IEC 20008-2 Mechanism 4 is the door TPM 2.0 ECDAA walks through to be admissible in those regimes.

Standardization was complete by 2014. Cryptographic primitive: CPS 2010. Security model: BFGSW 2013. ISO mechanism: 20008-2 Mechanism 4. TPM normative surface: TPM_ALG_ECDAA, TPM_ECC_BN_P256, TPM2_Commit, TPM2_Sign. Every box was checked. The next question -- the one the standardization community could not answer on its own -- was whether anyone would write a verifier.

8. The FIDO Bet That Failed (2017-2021)

In 2018, the FIDO Alliance bet that ECDAA was the missing privacy story for WebAuthn. Three years later, W3C took the bet off the table.

The bet was not casual. FIDO had a real problem. WebAuthn authenticators -- the YubiKey hardware tokens, the Microsoft Hello platform authenticators, the Touch ID and Face ID modules -- need to attest that they are genuine hardware. The attestation surface FIDO Alliance had inherited from U2F was Basic Attestation: every authenticator in a manufacturing batch of 100,000 or more units shared one attestation key [@fido-cert-levels], so a relying party that checked the attestation learned only "this is one of 100,000-plus YubiKey 5 NFCs," not which device specifically. The cohort-size rule gave Basic Attestation a workable operational privacy property. But there was an architectural fork in the road for an organization that wanted cryptographic attestation privacy without the cohort-key fan-out problem.

FIDO Alliance picked the cryptographic fork. The FIDO ECDAA Algorithm v2.0 specification was published as an Implementation Draft on February 27, 2018 [@fido-ecdaa-v2]. The document is the most carefully written specification of the DAA contract from a deployment perspective; the editor was Rolf Lindemann at Nok Nok Labs. The motivation section we have already quoted in §2 names the Privacy-CA failure mode in unusually direct terms.

WebAuthn Level 1 reached W3C Recommendation status on March 4, 2019 [@webauthn-1]. Section 8 defined six attestation statement formats by fmt identifier: packed, tpm, android-key, android-safetynet, fido-u2f, and none. ECDAA was not a separate format; the WebAuthn-1 §6.4.4 attestation-type list (Basic, Self, AttCA, ECDAA, None) carried ECDAA as an attestation type supported within the packed and tpm formats. An independent verification of the live HTML returns 63 occurrences of the string "ecdaa" in the Level 1 Recommendation -- ECDAA had its own type identifier, its own signing logic, and its own verification procedure embedded inside the two formats that mattered [@webauthn-1].

WebAuthn Level 2 reached W3C Recommendation status on April 8, 2021 [@webauthn-2] [@wiki-webauthn]. The same independent verification against the live Level 2 HTML returns zero occurrences of "ecdaa." Every reference -- the type identifier, the signing rules, the verifier procedure that the packed and tpm formats invoked -- was removed in a single editorial pass. The Yubico migration guide for its Java WebAuthn server library makes the vendor view explicit: "This attestation type was removed from WebAuthn Level 2. ECDAA support has not been implemented in this library, so this value could in practice never be returned" [@yubico-migration].

Why did the bet fail? Four reasons, each visible from the public record.

First, no major browser ever shipped an ECDAA verifier inside the packed or tpm statement format paths. Chromium, Firefox, and Safari implemented WebAuthn with packed, tpm, fido-u2f, and android-safetynet attestation, but the ECDAA branch within packed and tpm stayed unimplemented. The Yubico migration guide quoted above is the vendor-side confirmation of an industry-wide outcome [@yubico-migration].

Second, the largest authenticator vendors picked the Basic and AttCA attestation types instead of ECDAA. YubiKey 5 series ships with the packed format using a Basic Attestation key shared across a 100,000+-unit cohort [@yubico-yk5-attestation] [@fido-cert-levels]. Feitian, Google Titan, and other major FIDO2 authenticator vendors ship Basic Attestation under the same FIDO certification-policy cohort rule [@fido-cert-levels]. Microsoft Hello platform authenticators on Windows TPM-backed devices use the tpm attestation statement format with an AIK that a Microsoft-operated CA certifies -- the AttCA type, functionally a Privacy-CA [@ms-hello-doc] [@azure-attestation]. The vendor base from which a WebAuthn relying party would actually see an attestation statement, in practice, never produced an ECDAA one.

Third, FIDO ECDAA v2.0 never advanced beyond Implementation Draft. The URL slug for the document literally encodes its status: fido-v2.0-id-20180227 -- the id-20180227 segment names the format <status>-<date>, and "id" is "Implementation Draft." It never reached "Proposed Standard" or "Approved Specification" in FIDO's process [@fido-ecdaa-v2]. A relying party making a long-term technology bet on an attestation statement format that has never advanced past Implementation Draft has no reason to invest in a verifier library.

Fourth, FIDO Basic Attestation's cohort-size rule (100,000+ authenticators per attestation group key, enforced contractually on the certified-authenticator side) gave the underlying privacy concern an operational answer [@fido-cert-levels]. A WebAuthn relying party that sees a Basic Attestation signature learns "this is one of at least 100,000 identical authenticators" -- a cohort large enough that the relying party cannot, in practice, recover individual identifying information from the attestation alone. The cohort rule does not require pairing arithmetic, does not need a verifier library, and works with the same packed and tpm attestation formats every relying party already implements.

The FIDO Basic Attestation cohort minimum is a particularly clean example of how operational rules can compete directly with cryptographic primitives. The privacy property a relying party wants -- "I cannot single out this device from its peers" -- can be obtained by (a) hardware-anchored zero-knowledge proofs that mathematically forbid linkage (cryptographic DAA), or (b) a contractual obligation that every batch of attestation keys covers at least 100,000 devices (FIDO Basic Attestation) [@fido-cert-levels]. The cryptographic answer is mathematically stronger. The operational answer is dramatically easier to debug, audit, and revoke. Production has consistently chosen the latter.

Key idea: ECDAA shipped chips. It never shipped verifiers. Standardization is necessary but not sufficient for production deployment: production cryptography needs verifier libraries, and verifier libraries are social phenomena -- they emerge from relying-party demand, SDK presence, incident-response tooling, and library-maintainer attention, none of which the cryptography itself produces. Cryptographic excellence does not predict deployment; library availability does.

This is the second aha. The reader entered §8 believing that a standardized cryptographic primitive backed by FIDO, three browser vendors, and a publicly authored attestation format would deploy. They exit understanding that ECDAA standardized everything except the social machinery -- and the social machinery is where production attestation actually lives.

If a consortium with FIDO's privacy mandate, browser-vendor coalition, and authenticator-vendor base could not generate enough relying-party momentum to keep ECDAA in WebAuthn, what chance did the silent option in TPM 2.0 ever have? The answer requires walking the Microsoft attestation stack.

9. Windows: A Billion Chips, Zero Production Use (2014-Present)

Microsoft has shipped over a billion Windows TPM 2.0 platforms [@ms-pluton-blog] [@wiki-windows-11]. Microsoft has not shipped a Windows DAA API. The two facts are not in tension. They are the story.

The shipping Windows attestation stack is documented and unambiguous. Microsoft Azure Attestation is the production-grade attestation service. Its public architecture document describes the protocol in five paragraphs that read, line for line, like TPM 1.1 from 2003 [@azure-attestation]:

"Every TPM ships with a unique asymmetric key called the endorsement key (EK)... A certification authority (CA) establishes trust in the TPM either via EKPub or EKCert... A device proves to the CA that the key for which the certificate is being requested is cryptographically bound to the EKPub and that the TPM owns the EKPriv. The CA issues a certificate with a special issuance policy to denote that the key is now attested as protected by a TPM."

The architecture is the Privacy-CA architecture. The Microsoft-operated CA inputs an EK certificate and outputs a JWT that downstream Microsoft services (Defender for Endpoint device-compliance, Intune Conditional Access policies, Entra ID conditional access, customer-defined Azure Attestation policies) consume. The Windows Health Attestation Service, the older Microsoft surface that predated Azure Attestation, used the same broker model with different deployment shape. The Defender for Endpoint device-compliance flow that gates Conditional Access on attested TPM boot state consumes WHAS or Azure Attestation JWTs, not raw DAA quotes.

Microsoft Pluton's published surface tells the same story from the silicon side. Pluton is the security processor Microsoft has been shipping in successive Windows-class platforms. Its Microsoft Learn page enumerates the cryptographic algorithms and platform-security primitives the processor exposes [@pluton]. The page is exhaustive about TPM 2.0 baseline algorithms (RSA-2048, ECDSA over NIST P-256, SHA-2 family). It contains zero occurrences of ECDAA, of TPM_ALG_ECDAA, or of any phrase like "anonymous attestation." Insufficient public evidence to assert that Pluton implements ECDAA; sufficient evidence to assert that Pluton's published surface does not advertise it.

The Windows API surface gap is the third piece of evidence. The TPM Base Services (Tbsi_* functions in Tbs.dll) expose TPM2_Commit and TPM2_Sign to user-mode applications -- but only as raw command-buffer submissions. There is no BCryptDirectAnonymousAttestation. There is no NCryptDaaSign. There is no Web Authentication API wrapper that surfaces ECDAA.

The TPM Platform Crypto Provider (PCP) that Windows ships as part of the Cryptography Next Generation (CNG) framework supports RSA and ECDSA TPM-backed keys but does not surface ECDAA. The TSS.MSR open-source TPM stack from Microsoft Research does not ship a DAA wrapper. An application developer who wants ECDAA on Windows today writes raw TBS_SUBMIT_COMMAND byte buffers against the documented TPM 2.0 command numbering, manages the Join protocol against an Issuer of their own provisioning, and verifies the resulting signatures with a library they wrote themselves or pulled from a research-grade implementation.

The interesting question is why. Microsoft has never published a "we considered DAA and chose the broker model because..." statement. Treating that absence honestly, the four reasons below are inferences from observable architecture decisions, not Microsoft-engineer-published rationales. The article labels them as such.

First, operational simplicity. A hosted CA with audit logs is more debuggable than a per-relying-party DAA verifier with no central audit point. When a device fails attestation in production, the on-call engineer reading the Azure Attestation logs can answer "why did this device fail?" in seconds; the same question against a DAA verifier requires reasoning about pairing arithmetic, basename derivation, and Issuer-credential validity. Engineering organizations choose architectures whose failure modes they can debug.

Second, revocation economics. A Privacy-CA can revoke an AIK by removing one certificate from its issued-certificate store. Revoking a DAA credential, in the construction TPM 2.0 ships, requires either EPID-style signature-based revocation -- which the TPM 2.0 ECDAA scheme does not provide -- or a private-key list distributed to every relying party (extracting the private key from the misbehaving TPM is presumed possible after compromise, and verifiers then check that the signing key is not on the list). The CA's revocation primitive is a database delete. The DAA revocation primitive is an SDK rollout to every consumer of the verification library.

Third, the relying-party stack. DAA verifier libraries are not present in any mainstream cloud platform's SDK. The .NET CryptoNG surface, the Java JCA, the Python cryptography library, the Go crypto standard library, the Rust ring and dalek ecosystems -- none ship an ECDAA verifier. X.509 / PKI verifier libraries, by contrast, are everywhere. A relying party building on top of mainstream SDKs gets PKI verification for free; gets DAA verification for nothing close to free.

Fourth, the Windows API surface gap is itself the obstacle. Adding a BCrypt / NCrypt / WebAuthn DAA wrapper to Windows requires designing a new key-storage provider contract, defining the JOIN-protocol service interface, writing the conformance test suite, drafting the security documentation, and rolling it out on the Windows release calendar. That is a project the size of Windows Hello's. Microsoft has not, to public knowledge, prioritized it.

flowchart TD HW["TPM 2.0 hardware
(discrete or Pluton)
TPM_ALG_ECDAA may be present"] TBS["TPM Base Services
(Tbs.dll, kernel)"] PCP["TPM Platform Crypto Provider
(BCrypt / NCrypt)
RSA and ECDSA only"] AZ["Microsoft Azure Attestation
(Privacy-CA architecture)"] WHAS["Windows Health Attestation Service
(Privacy-CA architecture)"] RP["Intune / Defender / Entra
Conditional Access enforcement"] HW --> TBS TBS --> PCP PCP --> AZ PCP --> WHAS AZ --> RP WHAS --> RP HW -.->|"ECDAA path exists
no Windows API"| HW

The deeper reading -- the one that makes Microsoft's choice look structural rather than accidental -- starts from a comparison the four inferences above already pointed toward.

Key idea: Privacy-CA brokers and DAA solve the same problem -- prove the TPM is genuine without disclosing which TPM. They differ only in where the trust assumption lives. The broker treats privacy as an operational policy (the CA promises not to log, audit logs prove it kept the promise, regulators enforce the promise). DAA treats privacy as a mathematical property (the issuer cannot link, period, no audit needed). The architecture that wins in production is the one with the smaller operational surface, not the one with the better cryptographic guarantee.

This is the third aha. The reader entered §9 believing that cryptographic superiority should eventually win in production, and that Microsoft's non-adoption of DAA must be an oversight or a missed product opportunity. They exit understanding that the deployment-economics asymmetry is structural: a broker-mediated attestation flow reduces, end-to-end, to standard X.509 plumbing every cloud SDK already ships, while a DAA-mediated flow requires bespoke verifier libraries, bespoke revocation infrastructure, bespoke debugging tooling, and bespoke incident-response runbooks. Cloud-platform organizations have spent the last ten years building world-class operational machinery for X.509 attestation. They will not throw it away for a cryptographic property no compliance regime currently demands.

Note: The four reasons compound. The broker model gives a single audit point, a database-delete revocation primitive, an SDK that ships in every major language, and a debugging story the on-call engineer can walk through at 3 a.m. DAA gives mathematical privacy and requires every one of those operational properties to be rebuilt from scratch. Cloud platforms have, repeatedly and consistently, picked the architecture whose operational properties are easier to ship -- not because they do not understand the cryptographic alternative, but because the cryptographic alternative would require them to discard the operational machinery they already have. This is the structural reason DAA has stayed in firmware on a billion chips and out of production attestation flows on all of them.

If the broker calculus is this durable, is there any future world in which DAA wins? Two, and both are research-stage with decade-long horizons.

10. Theoretical Limits and Open Problems

What can DAA never do? Where does the next decade of research go? Three open problems organize the active research community in 2026.

10.1 What DAA cannot do

The first honest statement is the negative one. A correctly implemented DAA scheme does not prevent a compromised TPM from signing for the cohort it belongs to. The EK certificate attestation must be honest at manufacture time; if a TPM's secret membership value f leaks to an attacker (through fault injection, through side-channel extraction, through a firmware backdoor), the attacker can produce ECDAA signatures indistinguishable from legitimate ones until the TPM's f is added to a revocation list. The same constraint applies to every group-signature scheme.

A second hard limit is per-basename linkability. The user-controlled-linkability property gives a TPM the choice of linkable or unlinkable signing -- but once a verifier has seen the pseudonym N_V = ζ^f mod Γ for a particular (TPM, bsn) pair, the linkage for that basename is permanent. A misbehaving TPM that wants its history with a particular relying party forgotten cannot, by signing under a different basename, retroactively unlink past sessions.

A third limit is rogue-key scalability. The TPM 2.0 ECDAA scheme detects rogue keys by checking each signature against a list of compromised-f values the verifier maintains. For small lists this is cheap. For very large lists -- imagine a deployment where 1% of the chip population leaks f to attackers and the verifier must check every signature against ten million revoked values -- the constant factor matters. EPID's Sig-RL mechanism uses signature-based revocation that scales better; the TPM 2.0 ECDAA scheme does not include it.

10.2 The One-TPM-to-Bind-Them-All fix

In 2017 a team consisting of Jan Camenisch, Liqun Chen, Manu Drijvers, Anja Lehmann, David Novick, and Rainer Urian published "One TPM to Bind Them All: Fixing TPM 2.0 for Provably Secure Anonymous Attestation" at IEEE S&P 2017 [@one-tpm-2017]. The paper demonstrated a Diffie-Hellman-oracle attack against the TPM 2.0 ECDAA interface as shipped: a malicious host could query the TPM in a way that gave the host a DH-oracle relative to the TPM's secret f, effectively breaking the unlinkability property. The proposed fix had been published the previous year by Camenisch, Drijvers, and Lehmann at TRUST 2016 [@cdl-2016] [@cdl-2016-eprint]; library implementations of DAA published from 2017 onward incorporate the fix.The CDL16 fix is library-level, not silicon-level. The TPM 2.0 ECDAA command surface in the chip remains as shipped; the software that drives it must use the corrected protocol sequence to avoid presenting the host-controlled DH oracle. As of late 2025, the TCG normative TPM 2.0 Library Specification text has not been amended to require the corrected sequence. Implementations of DAA on top of TPM 2.0 -- the FIDO ECDAA v2.0 library, the Camenisch-Drijvers-Lehmann reference code, modern academic ECDAA implementations -- follow CDL16. Implementations written against the bare TPM 2.0 Library Specification without reading CDL16 are vulnerable.

10.3 Post-quantum DAA

Shor's algorithm is fatal to DAA. Every classical DAA construction -- BCC 2004, BCL 2008, CPS 2010, CDL 2016 -- relies on the hardness of discrete logarithms in elliptic-curve groups, the hardness of strong-RSA factoring, or both. A cryptographically relevant quantum computer breaks all of them. Post-quantum DAA is therefore active research, with no production deployment as of 2026. Three candidate families are being actively explored:

Symmetric-primitive DAA. Dan Boneh, Saba Eskandarian, and Ben Fisch presented "Post-quantum EPID Signatures from Symmetric Primitives" at CT-RSA 2019 [@bef-2019], building a post-quantum group signature from one-way functions and Merkle trees. The construction has classical post-quantum security guarantees but pays a steep size cost.
Lattice-based DAA. Rachid El Bansarkhani and Ali El Kaafarani published "Direct Anonymous Attestation from Lattices" as IACR ePrint 2017/1022 [@bk-2017-eprint], the earliest such proposal in the literature. The state-of-the-art lattice DAA construction is the 2024 Collaborative Segregated NIZK ("CoSNIZK") work by Liqun Chen, Patrick Hough, and Nada El Kassem [@cosnizk-2024], achieving signatures of approximately 38 kilobytes -- an order of magnitude smaller than the earliest lattice proposals but still two orders of magnitude larger than CPS 2010 ECDAA.
Hash-based DAA. Liqun Chen, Changyu Dong, Nada El Kassem, Christopher Newton, and Yalan Wang published "Hash-Based Direct Anonymous Attestation" at PQCrypto 2023 [@hashdaa-2023], building DAA from SPHINCS+-style stateless hash-based signatures. Size and speed remain unfavorable for TPM 2.0 firmware budgets.

The blocker for any of these reaching production TPM firmware is not academic. The TPM 2.0 normative algorithm set does not include lattice primitives. A post-quantum DAA in TPM 2.0 would require introducing TPM_ALG_DILITHIUM, TPM_ALG_FALCON, TPM_ALG_KYBER, or some equivalent into the spec, mandating support in the PC Client Platform TPM Profile, and rolling out across the OEM TPM-vendor base. That is, at minimum, a three-to-five-year standards effort that the TCG has not, as of late 2025, publicly committed to. CoSNIZK at 38 kilobytes is also two to three times larger than the largest signature any deployed TPM 2.0 firmware budgets for; the TPM-side compute time at quantum-safe parameter sets is currently measured in seconds rather than tens of milliseconds.

10.4 DAA for confidential computing

The other future-world thread is confidential computing -- the family of CPU-anchored isolated-execution primitives (Intel SGX, Intel TDX, AMD SEV-SNP, ARM CCA) that need their own attestation surfaces. Intel SGX attestation initially used EPID and has since migrated to DCAP, a vendor-CA broker similar in shape to Microsoft Azure Attestation. AMD SEV-SNP and Intel TDX use vendor-rooted PKI from the start.

Whether DAA-style group-signature schemes are appropriate for VM-level attestation -- where cohorts are small (per-region TDX hosts in a given hyperscaler datacenter), where the verifier is often a small set of well-known cloud-platform endpoints, and where traffic-analysis leakage between confidential VMs and Privacy-CA-like services is itself a threat -- is an open architectural question. The 2026 default is "vendor-CA broker"; the academic community continues to argue that cryptographic DAA would be a better match for the threat model. Production has not, so far, agreed.

A note on Java Card DAA prototypes. A small number of academic implementations of DAA on Java Card secure elements appeared between 2014 and 2017 -- Camenisch and others published smartcard-class implementations as proofs of concept. None reached production deployment. The reasons appear to be the same operational-economics asymmetry that limits TPM 2.0 ECDAA adoption: Java Card environments lack the relying-party verifier libraries that would consume the output. This is inference; no Java Card vendor has, to public knowledge, published a "we evaluated DAA and chose not to ship it" statement.

These are the open problems for researchers. What about the rest of us, on Monday morning?

11. Practical Guide and Frequently Asked Questions

Five roles, one Monday morning. Where does this leave you?

For a Windows platform engineer. The minimum viable Windows DAA API surface is approximately a BCryptCreateDaaContext, BCryptDaaJoin, BCryptDaaSign, and BCryptDaaVerify set, plus an NCryptDaaKeyHandle for key-storage-provider lifecycle, plus a Web Authentication API surface that consumes ECDAA attestation. Shipping all of that costs a Hello-sized engineering investment. If Pluton's published surface ever advertises ECDAA, an OEM-side integration becomes possible. Today the answer is that DAA is not available through any supported Windows API.

For an attestation-provider product engineer. Pick a Privacy-CA broker architecture for production. The comparison table below makes the trade-offs explicit. Cryptographic DAA does not pay for the architectural switch unless the relying-party privacy threat is specifically the broker itself -- a threat model that, in 2026, no shipping production attestation product publicly assumes.

For a FIDO authenticator vendor. ECDAA attestation is not a viable production choice in 2026. The path to it becoming viable runs through verifier libraries in Chromium, Firefox, and Safari; relying-party SDK support across Auth0, Okta, Microsoft Entra, and Google Identity Platform; and a non-deprecated WebAuthn Level N specification that re-adds the format. None of those preconditions are visibly in progress.

For an academic zero-knowledge-proof researcher. Four open problems map onto production needs: post-quantum DAA at TPM-firmware-shippable signature sizes (the current state-of-the-art at 38 kilobytes is too large), threshold-issuer DAA (no single party can issue a credential), confidential-computing DAA (for small-cohort VM attestation), and IoT DAA (for milliwatt-class energy budgets). Each is publishable; none yet has a deployment path.

For a privacy-tech advocate or policymaker. The framing that helps Microsoft, Google, and AWS engineering teams hear the request is "the broker can be compelled by a subpoena; the math cannot." The framing that does not help is "your cryptography is worse than the academic alternative." The first is a threat-model conversation that engineering organizations can engage with; the second is a technology conversation they have already had and decided.

Comparison: four production architectures for attested privacy

Property	Privacy-CA broker	TPM 2.0 ECDAA	EPID 2.0	Vendor-CA (Apple, AWS Nitro, Google)
Trust assumption	Operational (CA promises not to log)	Cryptographic (issuer cannot link)	Cryptographic (issuer cannot link)	Operational (vendor CA promises not to log)
Anonymity from verifier?	If CA does not log	Yes (per-basename)	Yes (per-basename)	If vendor does not log
TPM-side sign time	Milliseconds (AIK signing)	Tens of milliseconds	Tens of milliseconds	N/A (signing on vendor silicon)
Signature size	Hundreds of bytes (AIK)	Hundreds of bytes	Hundreds of bytes	Hundreds of bytes (X.509 over signed JWT)
Revocation	CA database delete	Private-key list (TPM 2.0)	Sig-RL (signature-based)	Vendor revocation list
Implementer complexity	Low (X.509 PKI everywhere)	High (BN-P256 pairing libraries)	High (vendor SDK required)	Low (vendor SDK ships it)
Standardization	TCG (2003)	TPM 2.0 + ISO 20008-2 Mech 4	ISO 20008-2 Mech 4	Vendor-proprietary
Best suited for	Cloud attestation at hyperscaler scale	Hardware-anchored attestation where broker is the threat	Intel-deployed enclave attestation	Vendor-platform attestation
2026 deployment scale	Billions of attestations per day	Essentially zero production verifiers	2.4B+ EPID keys per RSAC 2016	Billions of attestations per day

The "essentially zero production verifiers" entry for TPM 2.0 ECDAA is the deployment story this article exists to explain. The cryptography is in firmware on hundreds of millions of devices; the verifier side, in 2026, is research-grade libraries and the FIDO ECDAA-Verify reference code. No production cloud-platform SDK ships an ECDAA verifier.

Four things, in order. First, Pluton's published surface advertises `TPM_ALG_ECDAA` and an Issuer key-management story (a Microsoft-operated DAA Issuer for Windows devices, with documented enrollment and revocation flows). Second, a Cryptography Next Generation API surface (`BCryptDaaSign`, `NCryptDaaKey*`) that exposes the TPM2_Commit / TPM2_Sign sequence behind a single managed-language call. Third, a Web Authentication API extension that surfaces ECDAA attestation as a first-class statement format the same way the `tpm` format is today. Fourth, an Azure Attestation policy mode that consumes ECDAA signatures and produces JWT outputs downstream Microsoft services already understand. None of these are technically blocking; all four require a multi-year roadmap commitment that, as of late 2025, Microsoft has not publicly made. This is a thought experiment about technical feasibility, not a forecast about Microsoft strategy.

The companion piece to this article is the TPM in Windows article, which walks the broader TPM 2.0 command surface ECDAA sits inside.

It depends on what the laptop ships. The TPM 2.0 Library Specification names `TPM_ALG_ECDAA`. The TCG PC Client Platform TPM Profile made the algorithm optional in v1.04 (February 2020) and has carried that designation through v1.07 RC1 (December 2025), so a conformant Windows-class platform is allowed to omit it. Many discrete TPM 2.0 modules (Infineon, STMicroelectronics, Nuvoton) do implement the algorithm; Microsoft Pluton's published documentation does not advertise it. The honest answer is "look at your specific TPM vendor's algorithm capability table" -- and that even if your TPM does support the algorithm, Windows ships no API to use it [@tpm-library-spec] [@tcg-ptp] [@pluton] [@wiki-daa]. Microsoft has not published an explicit rationale. Four inferable reasons are visible from the architecture: (1) operational simplicity -- a hosted CA is easier to debug than a per-relying-party DAA verifier; (2) revocation economics -- a CA can revoke an AIK by deleting a certificate, while DAA revocation requires a private-key list distributed to every verifier; (3) a missing relying-party verifier-library stack; (4) no Windows API surface for ECDAA. All four are inferences. The shipped architecture is the Privacy-CA-shaped flow documented at the Microsoft Learn attestation page [@azure-attestation]. WebAuthn Level 1 (March 2019) registered ECDAA as an attestation *type* (Basic, Self, AttCA, ECDAA, None) carried inside the `packed` and `tpm` attestation statement formats. The Level 1 specification text contains 63 references to "ecdaa." WebAuthn Level 2 (April 2021) removed the type entirely; an independent grep of the Level 2 Recommendation HTML returns zero occurrences of "ecdaa." The Yubico migration guide for its WebAuthn server library states verbatim that "this attestation type was removed from WebAuthn Level 2" and that "ECDAA support has not been implemented in this library." The format has not been resurrected as of 2026 [@webauthn-1] [@webauthn-2] [@yubico-migration]. EPID is a DAA variant with one cryptographic addition: signature-based revocation (Sig-RL), which lets a verifier prove that a candidate signature was not produced by the same signer as any signature on a revocation list. The TPM 2.0 ECDAA scheme is the Chen-Page-Smart 2010 construction; EPID 2.0 is essentially the same construction with Sig-RL added. Intel positions EPID separately because of its production deployment (2.4 billion-plus keys shipped per Intel's RSAC 2016 disclosure, used for SGX attestation, Widevine, and several Intel chipsets), its specific licensing structure (royalty-free under Intel's contribution to ISO/IEC 20008 / 20009), and its open-source SDK that Intel maintained until archiving in 2023 [@brickell-li-epid-2007] [@brickell-li-tdsc-2012] [@wiki-epid] [@epid-sdk]. Active research, no production deployment as of 2026. The leading constructions are lattice-based (CoSNIZK 2024 at approximately 38 kilobytes per signature [@cosnizk-2024]), hash-based (the 2023 PQCrypto paper from SPHINCS+ [@hashdaa-2023]), and symmetric-primitive-based (Boneh-Eskandarian-Fisch CT-RSA 2019 [@bef-2019]). The barriers to shipping any of them in a TPM are fundamental: TPM 2.0 firmware does not implement lattice primitives, signature sizes at 30+ kilobytes are incompatible with current attestation-latency budgets, and no relying-party verifier library exists. A post-quantum DAA TPM is a 2030s project at the earliest. No. The Stage 0a focus-premise audit of this article demoted that framing as not supported by evidence. The accurate claim is "standardized in the TPM 2.0 Library Specification (2014); optional in the TCG PC Client Platform TPM Profile since February 2020; present on many discrete TPMs (vendor documentation confirms); absent from Microsoft Pluton's published algorithm surface; supported by no Windows API." That hedged statement is the one the article carries from its first 200 words through to this FAQ [@tpm-library-spec] [@tcg-ptp] [@pluton].

The cryptography is finished. The standardization is finished. The hardware is in the field. What is missing is the social machinery -- the verifier libraries, the SDK presence, the operational tooling, the incident-response runbooks, the regulator demand -- that turns cryptography into deployment. Direct Anonymous Attestation is the cleanest example in platform security of a primitive that won every standardization fight and lost every deployment one. The lesson is not that the cryptography is wrong. The lesson is that cryptography is necessary but never sufficient. Production systems are social systems whose mathematical components, however elegant, must compete with operational alternatives whose properties are easier to ship.

The companion pieces in this series are The TPM in Windows (the cryptographic primitive plumbing TPM 2.0 ECDAA sits inside) and the Microsoft Pluton continuation article (Pluton's published capability surface and the negative claim this article rests its §9 hedge on). The Measured Boot piece -- forthcoming -- walks the data that a hypothetical DAA quote would attest. If those three articles arrive together, the picture of Windows attestation as a system rather than a primitive becomes complete.

Pluton: A TPM On Silicon Microsoft Can Patch

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

**Microsoft Pluton is the architectural answer to a TPM threat model that broke between 2019 and 2024.** It moves the TPM onto the application SoC die, runs Microsoft-authored Rust firmware on a dedicated TEE, and ships updates through Windows Update -- closing every attack surface that defeated discrete TPM (Andzakovic 2019), Intel PTT (TPM-Fail 2019), and AMD fTPM (faulTPM 2023). Each design choice retires a 2014-2024 attack class and places a new trust in Microsoft: silicon supply chain, firmware compiler, signing key, update channel. The chip is the cheapest part of the system; the cost is a single Microsoft signing key as the trust anchor for every Pluton-equipped Windows 11 client.

1. The question Microsoft answered architecturally before the prior article posed it

"The TPM was supposed to be the part of the system you didn't have to trust anyone for. Twenty-five years later, the trust question is back -- and the answer is now political." That was the closing line of the previous article in this series [@prior-tpm-in-windows]. The counterintuitive fact: by the time that question was asked, Microsoft had been shipping its architectural answer to it for twelve years already, inside an Xbox.

The Xbox One launched in November 2013 with an on-die, Microsoft-signed security processor and a Microsoft-controlled firmware update path. Microsoft's own announcement seven years later named the lineage explicitly: "the Pluton design was introduced as part of the integrated hardware and OS security capabilities in the Xbox One console released in 2013 by Microsoft in partnership with AMD" [@ms-pluton-blog-2020]. The November 17, 2020 announcement that Pluton would ship on Windows PCs was not the introduction of a new design. It was a decision to apply a console design pattern to the general-purpose PC, with all the political and supply-chain consequences that come with that decision.

The prior article ended with three sets of broken engineering. A NZ$40 iCE40 FPGA on an LPC bus defeats discrete TPM in the time it takes a laptop to finish Trusted Boot [@andzakovic-2019-tpm-sniffing]. A network packet defeats Intel PTT through a 5-hour timing side channel against the ECDSA implementation in CSME [@tpmfail-microsite]. A few hours of physical access defeats AMD fTPM via a voltage glitch on the SVI2 power-management bus, walking out with the entire fTPM internal state [@jacob-2023-faultpm]. All three are documented in the prior article's section 5 and will not be re-derived here.

This article is what those three results forced into shape. Microsoft's reply is structural: move the TPM onto the SoC die so the bus disappears; run it on a dedicated TEE so a faulTPM-class glitch cannot drop everything; rewrite the firmware in a memory-safe language so the next decade of TPM-Fail-class CVEs has somewhere shorter to live; and route updates through Windows Update so the patch latency stops being measured in OEM-capsule quarters and starts being measured in Patch Tuesday weeks. Each design choice closes a specific 2014-2024 attack class. Each design choice also names a new trust. The bus is closed by trusting the silicon supply chain. The TEE is dedicated by trusting Microsoft's chip-level isolation. The firmware is memory-safe by trusting Microsoft's compiler and SDLC. The update path is fast by trusting Microsoft's signing key and Windows Update infrastructure. That is the article in five sentences.

The route from here is historical, then technical, then practical. Section 2 traces the design pattern from Xbox One (2013) through Project Sopris (2015), the Seven Properties of Highly Secure Devices paper (2017), Project Cerberus (2017), and Azure Sphere (2018). Section 3 shows why every other architectural option for "where the TPM lives" was systematically broken in public between 2019 and 2024. Section 4 walks the five generations of Microsoft security silicon side by side. Section 5 takes the four design choices in the November 17, 2020 announcement one at a time. Section 6 lists what is shipping in 2026, who has it on by default, and how to verify. Section 7 puts Pluton next to Apple's Secure Enclave Processor, Google's Titan M2 / OpenTitan, Caliptra, and the still-shipping Project Cerberus. Section 8 is what Pluton still cannot do, including the worked example of CVE-2025-2884. Section 9 is the open problems Pluton has named but not solved. Section 10 is the Monday-morning checklist. Section 11 is the FAQ and the closing.

Key idea: A single design pattern -- on-die security processor, Microsoft-signed firmware, online firmware updates -- migrating across product domains for thirteen years until it lands on the general-purpose PC. That migration is the subject of this article. Its cost is the subject of its closing.

gantt title Microsoft on-die security silicon 2013-2025 dateFormat YYYY-MM axisFormat %Y section Lineage Xbox One on-die security processor :2013-11, 2018-12 Project Sopris (Codename 4x4) :2015-01, 2017-04 Seven Properties paper (MSR-TR-2017-16) :2017-03, 2017-12 Project Cerberus (OCP) :2017-11, 2025-12 Azure Sphere (MT3620, Pluton MCU) :milestone, 2018-04, 1d section Pluton on PC November 17 2020 announcement :milestone, 2020-11, 1d AMD Ryzen 6000 first silicon :milestone, 2022-01, 1d Linux 6.3 tpm_crb merged :milestone, 2023-02, 1d Caliptra 1.0 (parallel path) :milestone, 2024-04, 1d Rust-based firmware foundation :2024-01, 2026-12 section Stress test CVE-2025-2884 (TCG ref code OOB) :milestone, 2025-06, 1d

Where did the design pattern come from, and why was it ready for the PC in 2020 and not earlier?

2. Origins -- Xbox One (2013), Sopris (2015), Seven Properties (2017), Cerberus (2017), Azure Sphere (2018)

The November 2020 announcement is retroactive. The design dates to Xbox One in 2013; the name "Pluton" first appears publicly in April 2018, in an Azure Blog post on the Azure Sphere MCU [@azure-blog-anatomy-secured-mcu]. The five-year gap is the architecture maturing from "console-only thing the SoC team built" to "thing Microsoft Research thinks every device should have."

2013 -- Xbox One

A console adversary has full physical access, unlimited time, and an economic incentive measured in hundreds of thousands of pirated units. Microsoft and AMD co-designed the Xbox One SoC with an on-die security subsystem, Microsoft-signed firmware, and a hardware-enforced separation between the Game OS and the System OS. The 2020 Pluton announcement [@ms-pluton-blog-2020] names the lineage explicitly. The architectural shape that the Pluton-on-PC program would later put under TCG TPM 2.0 wire compatibility was already running in production at consumer-console scale by 2014. The motivation matters because it is the only domain where Microsoft had hands-on experience deploying an on-die security processor against an adversary who owned the hardware. (Note: that the design was driven specifically by RGH-class console-modding adversaries is architectural inference, not a Microsoft statement.)

2015 -- Codename 4x4 / Project Sopris

In 2015, a small team in Microsoft AI+Research NExT, led by Galen Hunt, began exploring whether the same architectural shape could secure a $4 microcontroller [@msr-blog-azure-sphere]. The internal codename was Codename 4x4 -- a reference to the technical requirements that the chip would have at least 4 MB of RAM and 4 MB of Flash [@msr-blog-azure-sphere]. The Microsoft Research blog post is the surviving primary source on Sopris [@msr-blog-azure-sphere].The "Codename 4x4" name was internal team shorthand. Hunt's MSR Blog post records both the meaning and the constraint: "This was the origin of the project, internally called 'Codename 4x4', referring to the technical requirements that the chip will have at least 4 MB of RAM and 4 MB of Flash" [@msr-blog-azure-sphere]. The point was not the storage budget; the point was that a $4 MCU must afford the same architectural properties as a console SoC.

March 2017 -- Seven Properties of Highly Secure Devices

Hunt, George Letey, and Edmund Nightingale published The Seven Properties of Highly Secure Devices as Microsoft Research Technical Report MSR-TR-2017-16 in March 2017 [@msr-2017-seven-properties]. The paper makes a single normative claim: "This paper makes two contributions to the field of device security. First, we identify seven properties we assert are required in all highly secure devices" [@msr-2017-seven-properties]. The seven are: hardware-based root of trust, small trusted computing base, defense in depth, compartmentalisation, certificate-based authentication, renewable security, and failure reporting. Property #6 is the one the rest of this article turns on. Renewable security via online firmware updates is precisely the property that distinguishes Pluton-on-PC from a 2014 dTPM. The chip is allowed to be wrong, as long as the chip can be made right again, fast.

A 2017 Microsoft Research framework (Hunt, Letey, Nightingale; MSR-TR-2017-16) listing the architectural properties any "highly secure device" must satisfy: hardware-based root of trust, small TCB, defense in depth, compartmentalisation, certificate-based authentication, *renewable security via online updates*, and failure reporting [@msr-2017-seven-properties]. Renewable security is the property the Pluton-on-PC update path operationalises; it also names the new trust the program places in Microsoft.

November 9, 2017 -- Project Cerberus

Microsoft announced Project Cerberus at the OCP Summit on November 9, 2017 [@siliconangle-2017-cerberus]. Kushagra Vaid, then Microsoft Azure GM, described the architecture as "a cryptographic microcontroller running secure code which intercepts accesses from the host to flash over the SPI bus (where firmware is stored), so it can continuously measure and attest these accesses to ensure firmware integrity" [@siliconangle-2017-cerberus]. Microsoft contributed a five-PDF specification set to OCP under Project Olympus [@ocp-cerberus]: Architecture Overview, Challenge Protocol, Firmware Update, Host Processor Firmware Requirements, and Processor Cryptography. The reference implementation lives at Azure/Project-Cerberus on GitHub [@azure-cerberus-github] -- platform-agnostic core, FreeRTOS and Linux ports, "designed to be a hardware root of trust (RoT) for server platforms" [@azure-cerberus-github]. Microsoft Learn describes Cerberus as "a NIST 800-193 compliant hardware root-of-trust with an identity that cannot be cloned" [@ms-learn-cerberus] [@nist-sp-800-193]. This was Microsoft's first public commitment to publishing a hardware-RoT design and to running it in production at fleet scale.

Cerberus matters here for what it cannot do, not what it can. It is a discrete chip. It needs board area, a BOM line, and per-OEM design-in cost. It works on a $20,000 server motherboard. It does not work on a $700 ultrabook -- and putting it on one would reintroduce the very external-bus surface that Andzakovic 2019 showed to be sniffable [@andzakovic-2019-tpm-sniffing]. Cerberus solves the server problem definitively. It does not solve the PC problem, and its existence makes the PC-side need explicit.

April 16, 2018 -- Azure Sphere preview at RSA 2018

Hunt's announcement of Azure Sphere at the 2018 RSA Conference is the first public, named appearance of "Pluton." The Azure Blog launch post promised "custom silicon security technology from Microsoft, inspired by 15 years of experience and learnings from Xbox, to secure this new class of MCUs and the devices they power" [@azure-blog-2018-azure-sphere]. The companion Anatomy of a Secured MCU post is the first technical description: "our Pluton Security Subsystem is the heart of our security story" [@azure-blog-anatomy-secured-mcu]. Three components, one trust anchor: the MediaTek MT3620 MCU with the Pluton subsystem on die; the Microsoft-managed Linux-based Azure Sphere OS; and the Azure Sphere Security Service (AS3) cloud, which signed firmware updates and consumed device attestations. Wikipedia records the general-availability date as February 24, 2020 [@wikipedia-azure-sphere], also describing Pluton as "a Microsoft-designed security subsystem that implements a hardware-based root of trust for Azure Sphere" [@wikipedia-azure-sphere].

Each chip includes custom silicon security technology from Microsoft, inspired by 15 years of experience and learnings from Xbox, to secure this new class of MCUs and the devices they power. -- Galen Hunt, Azure Blog, April 16, 2018 [@azure-blog-2018-azure-sphere]

By April 2018, Microsoft had three architectural pieces in production. Xbox One proved the on-die security processor. Project Cerberus proved that Microsoft could publish an open RoT design and operate the back end at hyperscale. Azure Sphere proved that the Pluton block could be licensed onto a third-party SoC, attested to a Microsoft-operated cloud service, and serviced over the air. None of those three pieces was on a Windows PC.

flowchart LR Xbox[Xbox One 2013
on-die security processor
console form factor] Sopris[Project Sopris 2015
4 MB RAM + 4 MB Flash
research prototype] Seven[Seven Properties 2017
MSR-TR-2017-16
renewable security] Cerberus[Project Cerberus 2017
discrete RoT
server BMC] Sphere[Azure Sphere 2018
Pluton-on-MCU
MediaTek MT3620] PC[Pluton-on-PC 2020
general-purpose Windows PC] Xbox --> Seven Sopris --> Seven Seven --> Sphere Xbox --> Sphere Cerberus --> PC Sphere --> PC

Microsoft had a working architecture by 2018. Why did it take until November 17, 2020 to put it on a PC, and what changed between 2018 and 2020 that made the PC mandatory?

3. The threat model that closed every other door (2019-2024)

The answer to "what changed between 2018 and 2020" is that, between 2019 and 2024, every alternative architecture for where the TPM lives was systematically broken in public. Not by intention. By research. By the time Microsoft made the November 17, 2020 announcement, Pluton-on-PC was the only architectural option that simultaneously closed the bus, contained the TEE blast radius, and gave Microsoft a fast firmware-patch path. This section is the prior article's section 5, recast as the story Microsoft was watching unfold while the Pluton design was being prepared for PC.

March 13, 2019 -- Andzakovic's $40 LPC sniffer

Denis Andzakovic, working at Pulse Security, published an end-to-end attack on the Trusted Boot path of an HP business laptop [@andzakovic-2019-tpm-sniffing]. A NZ$40 iCE40 FPGA, seven wires (LFRAME, LAD0-LAD3, LCLK, GND) soldered to the LPC bus between the CPU and the discrete TPM, the BitLocker Volume Master Key falling off the wire in plaintext during boot. The prior article walks the bit-level details. What matters here is that the November 17, 2020 Pluton announcement names this attack class as motivation: "attackers have begun to innovate ways to attack [the TPM], particularly in situations where an attacker can ... gain physical access to a PC ... target[ing] the communication channel between the CPU and TPM" [@ms-pluton-blog-2020]. Discrete TPM as a class is broken against a determined adversary with physical access. The bus is the surface.

November 12, 2019 -- TPM-Fail

Daniel Moghimi and colleagues published TPM-Fail later in 2019 [@tpmfail-microsite]: timing side channels in the ECDSA implementation in Intel PTT (CVE-2019-11090) and the STMicro ST33 dTPM (CVE-2019-16863). Local key recovery in 4-20 minutes; remote, over the network, in approximately 5 hours. The fixes shipped as firmware patches. The lesson Microsoft took from TPM-Fail is not in the bug, it is in the deploy mechanism. PTT lives in CSME; CSME ships through the OEM's UEFI capsule path. ST33 lives behind the TPM vendor's signed flash and ships through the OEM's UEFI capsule path. The OEM UEFI capsule path is measured in quarters to years for high-volume client OEMs. A fix existed but the deploy mechanism was insufficient. This is the architectural lesson that the next generation has to internalise: the patch path is part of the security property.The deploy-mechanism lesson is the one that gets quietly swallowed into Pluton's design. The bug count in firmware-TPM territory is not zero; it is steady. What changes is whether a fix can reach the fleet before its dwell time becomes a procurement problem. TPM-Fail's structural lesson is therefore not "ECDSA timing leaks" -- it is "the channel that delivers the fix is the security property that matters."

April 28, 2023 -- faulTPM

Hans Niklas Jacob, Christian Werling, Robert Buhren, and Jean-Pierre Seifert published faulTPM: Exposing AMD fTPMs Deepest Secrets at IEEE EuroS&P 2023 [@jacob-2023-faultpm]. "In this paper, we analyze a new class of attacks against fTPMs: Attacking their Trusted Execution Environment can lead to a full TPM state compromise. We experimentally verify this attack by compromising the AMD Secure Processor" [@jacob-2023-faultpm]. The mechanism: a voltage glitch on the SVI2 power-management bus, against the AMD PSP (an ARM TrustZone Cortex-A5 inside modern Ryzen SoCs [@wikipedia-amd-psp]), in 2-3 hours of physical access. The output: the entire fTPM internal state, including the EK and any sealed material.

The structural failure in faulTPM is not the glitch. It is that the PSP is a shared TEE. The same coprocessor that runs the fTPM service also runs SEV memory-encryption setup, secure-boot enforcement, and platform initialisation. One fault drops everything. Shared-TEE fTPM is broken because the TEE is shared. The architectural conclusion that this forces is hard: a fTPM that lives next to memory-encryption services, alongside boot-policy enforcement, in a coprocessor that also handles fuse provisioning, is not separable in failure. To restore TEE isolation, you need a dedicated TEE.

The architecture cascade

Three results in five years close every architectural option Microsoft had on the PC.

Realization	Structural failure	First public proof	What survives the failure
Discrete TPM (LPC / SPI)	External bus is sniffable	Andzakovic 2019 [@andzakovic-2019-tpm-sniffing]	Hardened dTPM with encrypted bus (TPM 2.0 ENC sessions); not retrofittable to existing fleets
Intel PTT in CSME	Slow OEM UEFI capsule patch path	TPM-Fail 2019 [@tpmfail-microsite]	The cryptographic primitive; not the deploy channel
AMD fTPM in PSP	Shared TEE -- one fault drops everything	faulTPM 2023 [@jacob-2023-faultpm]	The compatibility surface; not the secrets the chip held
Pluton on the SoC die	(subject of sections 5-8)	--	--

The reasoning chain that lands the design is short. dTPM is broken because the bus is sniffable. Shared-TEE fTPM is broken because the TEE is shared. Therefore: dedicated TEE on the SoC die, with a deploy channel that is not the OEM UEFI capsule. That is Pluton-on-PC. On-die is not a Microsoft engineering preference. It is the only shape left after every other architecture has been broken in public.

flowchart TD dTPM[Discrete TPM
external LPC/SPI bus] PTT[Intel PTT
fTPM inside CSME] fTPM[AMD fTPM
fTPM inside PSP] AND[Andzakovic 2019
\$40 FPGA bus sniff] TF[TPM-Fail 2019
5-hour ECDSA recovery] FT[faulTPM 2023
SVI2 voltage glitch] Forced[On-die dedicated TEE
OS-channel update path
= Pluton-on-PC] dTPM --> AND PTT --> TF fTPM --> FT AND --> Forced TF --> Forced FT --> Forced

Note: By 2024, all three production options for the TPM realization had been defeated by public research. dTPM by the bus surface (Andzakovic 2019). Intel PTT by the patch latency of CSME (TPM-Fail 2019). AMD fTPM by the shared-TEE blast radius (faulTPM 2023). On-die is not an aesthetic choice; it is the only architectural shape left after every other option has been demonstrably broken. The "Pluton design" is the negative space these three results leave behind.

If Microsoft had a working on-die-RoT architecture as early as 2013, and the threat model demanded it on PC by 2020, why did Microsoft go through Cerberus and Azure Sphere first? What did each generation contribute that the previous one could not?

4. Five generations of Microsoft security silicon

Microsoft's path to Pluton-on-PC was not linear. The architecture took shape across five generations of Microsoft security silicon -- three direct predecessors, the PC deployment itself, and one parallel path. Each generation contributed a piece the next one needed. The shape of Pluton-on-PC was determined by what Xbox One was, what Cerberus could not be on a client, what Azure Sphere proved at scale, and what Caliptra would later make visible as a choice rather than a technical necessity.

Note: This article counts Microsoft on-die security-silicon programs (Generations 3-7 = Xbox One, Cerberus, Azure Sphere Pluton, Pluton-on-PC, Caliptra). The prior article counts TPM realisations (Generations 1-3 = standalone hardware TPM, firmware TPM, on-die TPM) [@prior-tpm-in-windows]. The two schemes share an index space but count different things. Project Cerberus appears as Generation 4 here even though it is discrete (not on-die), because the count is over Microsoft security-silicon programs, not over TPM realisations.

A hardware element that anchors three separable services: Root of Trust for Storage (the chip can hold private keys that never leave it), Root of Trust for Reporting (the chip can sign attestations of its own state and of code it measured), and Root of Trust for Measurement (the chip records integrity hashes of code as it loads). The TPM 2.0 specification names all three; Pluton, Apple SEP, Caliptra, and OpenTitan implement subsets and combinations of them.

Generation 3 -- Xbox One on-die security processor (2013)

Existence proof. Microsoft and AMD co-designed the Xbox One SoC with an on-die security subsystem [@ms-pluton-blog-2020]. Console signing key. Hardware-enforced separation between Game OS and System OS. The Xbox One demonstrated, at consumer-console scale, that Microsoft and a chip vendor could ship an on-die security processor that survived a determined adversary with full physical access. Limitation: console-only. No TCG TPM 2.0 wire surface. Microsoft did not commit publicly that this design would ever leave the Xbox.

Generation 4 -- Project Cerberus (November 9, 2017)

Discrete RoT chip on the server BMC. NIST SP 800-193 alignment [@ms-learn-cerberus] [@nist-sp-800-193]. Open spec at OCP [@ocp-cerberus]; reference implementation on GitHub [@azure-cerberus-github]. Architecturally the inverse of Pluton: external chip, separate flash interception, dedicated authority. That shape is right for a server motherboard. That shape is wrong for a $700 ultrabook -- BOM cost, board area, and per-OEM design-in cost rule it out, and reintroducing an external bus would re-expose the very Andzakovic-class surface the program is trying to close. Cerberus is not a rejected design; it is the server-side answer that runs alongside the client-side answer Pluton would later be. The two coexist in the November 17, 2020 announcement, which describes Cerberus as "providing a secure identity for the CPU that can be attested by Cerberus" [@ms-pluton-blog-2020]. Server-side RoT and client-side RoT compose; they do not compete.

Generation 5 -- Azure Sphere Pluton MCU (April 2018)

The first public, named appearance of "Pluton." MediaTek MT3620 SoC; Linux-based MCU OS; Azure Sphere Security Service in the cloud [@azure-blog-2018-azure-sphere] [@azure-blog-anatomy-secured-mcu]. "Our Pluton Security Subsystem is the heart of our security story" [@azure-blog-anatomy-secured-mcu]. Three things became operationally proven in this generation. First, Microsoft-designed on-die security IP could be licensed to a third-party SoC and taped out under another vendor's process. Second, Microsoft-operated cloud-side firmware servicing was viable at MCU scale. Third, the Seven Properties mapped cleanly onto the silicon-plus-firmware-plus-cloud triple. Limitation: MCU-class power and instruction set; not Windows; product retiring in 2027.The precision matters. The design pattern -- on-die security processor, Microsoft-signed firmware, cloud or OS-channel updates -- dates to Xbox One in 2013. The name "Pluton" first appears publicly in the April 2018 Anatomy of a Secured MCU Azure Blog post [@azure-blog-anatomy-secured-mcu]. The 2020 PC announcement uses the name retroactively for the 2013 design. When narrating: the design is Xbox-era, the name is Azure-Sphere-era.

Generation 6 -- Pluton on Windows-PC SoCs (November 17, 2020)

The subject of section 5. Brief hand-off here. Microsoft, AMD, Intel, and Qualcomm announced that the Pluton design would ship on Windows-PC SoCs [@ms-pluton-blog-2020]. AMD Ryzen 6000 was the first silicon to actually ship, at CES 2022 [@phoronix-2022-amd-ryzen-pluton]. Microsoft Learn currently lists AMD Ryzen 6000 / 7000 / 8000 / 9000 / Ryzen AI; Intel Core Ultra 200V Series, Ultra Series 3, and Series 3; and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series [@ms-learn-pluton]. This is the generation the rest of the article lives in.

Generation 7 -- Caliptra 1.0 (April 2024)

Open-source datacenter Root of Trust. Co-designed by Microsoft, Google, AMD, and NVIDIA. Specification, RTL, ROM, and runtime all public on CHIPS Alliance [@caliptra-github] [@caliptra-spec]. "Caliptra targets datacenter-class SoCs like CPUs, GPUs, DPUs, TPUs. It is the specification, silicon logic, ROM and firmware for implementing a Root of Trust for Measurement (RTM) block inside an SoC" [@caliptra-github]. Caliptra is not a successor to Pluton. It is a parallel path, and that distinction is what makes Caliptra structurally important for this article: it makes the single-signer choice in Pluton visible as a choice, not a technical necessity. Caliptra exists. The single-signer property of Pluton-on-PC is therefore not the only design that 2024 hardware can support; it is the one Microsoft chose for the client.

The five generations side by side:

Generation	Year	On-die?	Discrete?	Open RTL?	Multi-signer?	Trust anchor	Where it ships
3 -- Xbox One sec proc	2013	Yes	No	No	No	Microsoft (Xbox CA)	Xbox One console
4 -- Project Cerberus	2017	No	Yes	Yes (spec/RI)	No (per-deployment signer)	Microsoft Azure CA (operator)	Server BMC
5 -- Azure Sphere Pluton	2018	Yes	No	No	No	Microsoft (AS3)	MCU (MediaTek MT3620)
6 -- Pluton-on-PC	2020	Yes	No	No	No	Microsoft (Windows Update)	Windows 11 client SoCs
7 -- Caliptra 1.0	2024	Yes	No	Yes	Multi-vendor by deployment	Per-chip integrator	Datacenter SoCs

flowchart TD Gen3[Gen 3: Xbox One 2013
existence proof at scale] Gen4[Gen 4: Cerberus 2017
open spec + NIST 800-193] Gen5[Gen 5: Azure Sphere 2018
Pluton-on-MCU + cloud servicing] Gen6[Gen 6: Pluton-on-PC 2020
TCG TPM 2.0 surface + Windows Update] Gen7[Gen 7: Caliptra 2024
open-source datacenter RoT] Gen3 -->|console-only existence| Gen5 Gen3 -->|client-side
architecture| Gen6 Gen4 -->|server-side
composes with Gen 6| Gen6 Gen4 -->|open governance
refined into| Gen7 Gen5 -->|MCU-scale to PC-scale| Gen6 Gen6 -.parallel path.-> Gen7

What, exactly, makes Generation 6 different from the four generations that came before it -- and what new trust does each of its design choices ask the reader to place in Microsoft?

5. The breakthrough -- on-die plus dedicated TEE plus Rust plus Windows Update

The November 17, 2020 announcement [@ms-pluton-blog-2020] is shorter than its consequences suggest. It makes four design choices explicit. Each one closes a specific architectural gap that 2014-2024 had opened. Each one also names a new trust that is now placed in Microsoft. This section walks the four choices, the gap each one closes, and the trust each one creates.

Design choice 1 -- on-die SoC integration

There is no off-package bus between the CPU and the Pluton block. The November 2020 announcement names this property as the structural answer to the bus-sniffing class: "attackers have begun to innovate ways to attack [the TPM], particularly in situations where an attacker can ... gain physical access to a PC ... target[ing] the communication channel between the CPU and TPM" [@ms-pluton-blog-2020]. With Pluton, that communication channel is silicon, not a board trace. Andzakovic-class attacks have nothing to attack [@andzakovic-2019-tpm-sniffing].

The new trust: the silicon supply chain. Microsoft licenses the IP block; AMD, Intel, and Qualcomm tape it out on TSMC or another foundry; the OEM integrates the resulting SoC into a finished product. None of those steps is on the public record at the bit level. (See open problem 5 in section 9 -- supply-chain integrity beyond firmware signing.)

Design choice 2 -- dedicated TEE, not shared

Pluton is not the same coprocessor that runs SEV memory encryption (AMD) or CSME runtime services (Intel). It is a separate block on the SoC die, with its own ROM, its own firmware, and its own boundary. faulTPM-class attacks on the AMD PSP do not transitively drop Pluton secrets [@jacob-2023-faultpm], because Pluton is not running inside the PSP. The structural failure that defeated AMD fTPM -- one fault drops everything because the TEE is shared -- does not apply to Pluton-as-Pluton. (AMD-Ryzen-6000-class chips can ship Pluton silicon next to the existing PSP-based fTPM; the OEM picks which the host advertises as the system TPM via the Pluton (HSP) BIOS toggle and PSP-directory 0xB BIT36 soft fuse Garrett 2022 documents [@garrett-2022-pluton-rev]. Windows TBS exposes one TPM at a time. On systems the OEM exposes as fTPM, faulTPM-class attacks remain valid; on systems exposed as Pluton-as-TPM they no longer reach the chip's secret state.)

The new trust: Microsoft's chip-level isolation engineering. The TEE is dedicated only because Microsoft and the chip vendor agreed to dedicate it. There is no public peer-reviewed audit demonstrating that the Pluton boundary is bit-for-bit non-shared with PSP / CSME on shipping silicon. The independent CHES 2024 study TPMScan [@tpmscan-2024] [@tpmscan-iacr] sampled 78 TPM 2.0 versions across 6 vendors, and the IACR TCHES record states explicitly that the corpus "include[s] recent Pluton-based iTPMs" alongside dTPM, fTPM, and earlier iTPM variants from Microsoft, AMD, Intel, Infineon, ST, and Nuvoton [@tpmscan-iacr]. The paper's per-vendor findings centre on RSA / ECDSA nonce-leakage and command-timing observability across the corpus; the paper does not single Pluton out for a per-implementation audit, and it does not characterise Pluton's specific timing surface as worse or better than the iTPM cohort it sits in. The TPMScan study therefore places Pluton inside the audited iTPM population without singling it out -- a useful baseline, not a Pluton-specific clean bill of health.

Design choice 3 -- Microsoft-authored Rust firmware

Microsoft Learn states it explicitly: "Pluton platforms in 2024 AMD and Intel systems will start to use a Rust-based firmware foundation given the importance of memory safety" [@ms-learn-pluton]. Memory-safe firmware is a direct response to the firmware-CVE history -- TPM-Fail [@tpmfail-microsite], the long Intel ME / AMD PSP CVE backlog, and CVE-2025-2884 (worked example in section 8 below). The class of bug that a memory-safe runtime structurally rules out is large; it is not the entirety of the bug surface (logic bugs survive Rust), but it is the part that has driven the CVE economy in firmware-TPM territory for a decade.

Microsoft Learn commits to *"a Rust-based firmware foundation"* on 2024+ AMD and Intel platforms [@ms-learn-pluton]. Secondary technology press has named the runtime as Tock OS, the memory-safe embedded operating system maintained by an open community [@tock-github]. Tock is a plausible candidate -- it is the most mature publicly reviewed memory-safe embedded RTOS for the kind of constraints Pluton operates under. But Microsoft has not made the Tock attribution publicly. The honest reading is: Rust on the PC firmware path is committed; the specific runtime has not been named by Microsoft as of 2026. The reader who wants to track this should watch the Microsoft Learn Pluton page for an explicit runtime name.

The reason this hedge matters: "Pluton runs Tock" is widely repeated in tech press, and the difference between "memory-safe Rust embedded OS" and "specifically Tock" is the difference between an architectural commitment and a procurement choice. Both are interesting, but they are not the same statement.

Garrett's April 2022 reverse-engineering [@garrett-2022-pluton-rev] documented that the Pluton firmware blob on the 2022 AMD Ryzen 6000 BIOS he disassembled was an ARM image derived from the TCG TPM 2.0 reference code (section 6 carries the verbatim quote and section 8 carries the CVE-2025-2884 connection). That is the 2022 firmware on a 2022-vintage chip; it is not the 2024+ Rust runtime. Both observations are consistent: the 2022 ARM blob is what existed on the first silicon, and the 2024+ Rust runtime is what Microsoft Learn now commits to. CVE-2025-2884 (section 8) reaches this firmware exactly through the TPM 2.0 reference-code derivation Garrett identified.

The new trust: Microsoft's compiler and SDLC. The chip ships running code that Microsoft authored. Whatever the compiler optimised away, whatever the test suite did not catch, whatever subtle un-unsafe-block reasoning passed code review -- that becomes the property of the chip's trust anchor.

Design choice 4 -- Windows Update servicing path

Microsoft Learn: "Pluton platform supports loading new firmware delivered through operating system updates" [@ms-learn-pluton]. The change in shape is this: from quarters-to-years (the OEM UEFI capsule rollout that TPM-Fail had to crawl through) to days-to-weeks (the Patch Tuesday cadence that already delivers Windows kernel updates to roughly 1.4 billion endpoints, the deployment scale Microsoft itself reports for Windows monthly active devices). Microsoft has not published a numerical SLA for Pluton firmware delivery; this article will not assert one. The change in channel is the architectural fact.

The new trust: Microsoft's signing key and Windows Update infrastructure. Whoever can sign for the Windows Update channel can, in principle, push firmware to every Pluton chip the channel reaches. This is the same trust that already underwrites the rest of Windows; Pluton extends it to the chip itself.

The trust shift, named explicitly

Pull the four choices together. Each closes a specific 2014-2024 attack class -- bus, shared-TEE, firmware-CVE, OEM-capsule patch latency. Each names a new trust placed in Microsoft -- silicon supply chain, chip-level isolation engineering, compiler and SDLC, signing key and Windows Update infrastructure. On-die alone is not the breakthrough. The breakthrough is the combination.

The November 2020 announcement also commits to a property beyond TCG TPM 2.0: SHACK. "Pluton also provides the unique Secure Hardware Cryptography Key (SHACK) technology that helps ensure keys are never exposed outside of the protected hardware, even to the Pluton firmware itself" [@ms-pluton-blog-2020]. The TCG TPM 2.0 specification requires that keys be non-exportable from the chip; SHACK extends the boundary one ring inward, naming a class of keys that the firmware running on Pluton itself cannot read. This is Microsoft's claim that Pluton offers a stronger property than the TCG TPM 2.0 spec requires. Verifying that claim from outside Microsoft requires source access Microsoft has not published.

A Pluton property named in the November 17, 2020 announcement [@ms-pluton-blog-2020]; Microsoft's claim that Pluton's non-exportability boundary extends one ring inside the TCG TPM 2.0 boundary, so keys are unreadable even by Pluton firmware. See the §5 prose paragraph above for the verbatim Microsoft quote and the article's hedge that no external peer-reviewed validation of SHACK exists as of 2026.

How the chip boots and how the chip gets patched

The boot-and-attest sequence below is the public shape of how Pluton starts and how new firmware reaches it. The exact ROM-to-FMC-to-runtime chain is generic to on-die RoT designs (Caliptra exposes this shape openly in its source [@caliptra-github]); Pluton's specific protocol details are not all on the public record, so the diagram captures the architectural shape rather than a Microsoft-internal protocol.

sequenceDiagram participant SoC as SoC reset participant ROM as Pluton ROM participant FMC as Pluton FMC participant RT as Pluton runtime participant Win as Windows + WU SoC->>ROM: power-on, Pluton enters ROM ROM->>ROM: verify FMC signature against on-die public key ROM->>FMC: hand off after measurement FMC->>FMC: verify runtime signature FMC->>RT: hand off, runtime exposes TPM 2.0 CRB RT-->>Win: TPM 2.0 commands over CRB Win->>Win: Patch Tuesday delivers signed Pluton blob Win->>RT: stage new firmware via OS update channel RT->>FMC: queue new runtime, reboot to apply FMC->>FMC: verify new runtime signature, commit

The detection logic that follows is the structural shape of the Get-Tpm PowerShell query that section 10 will revisit. It is mocked here to make the four-letter MSFT check explicit.

{// Mock of the Windows TPM Base Services (TBS) manufacturer query. // Real Get-Tpm reads ManufacturerIdTxt from the TPM 2.0 capability // response and matches the four-character ASCII manufacturer. const manufacturers = { 'MSFT': 'Microsoft Pluton', 'INTC': 'Intel PTT (firmware TPM in CSME)', 'AMD ': 'AMD fTPM (firmware TPM in PSP)', 'IFX': 'Infineon discrete TPM', 'STM': 'STMicro discrete TPM', 'NTC': 'Nuvoton discrete TPM', }; function classify(mfr) { return manufacturers[mfr] || 'Unknown / non-TCG TPM'; } console.log('MSFT =>', classify('MSFT')); console.log('INTC =>', classify('INTC')); console.log('AMD =>', classify('AMD ')); console.log('IFX =>', classify('IFX'));}

Key idea: The Pluton breakthrough is the combination, not on-die alone. On-die plus dedicated TEE plus memory-safe firmware plus OS-channel updates -- four design choices, each closing a different 2014-2024 attack class, each placing a new trust in Microsoft. The chip is the cheapest part of the system. The cost is what those four trusts add up to.

What is actually shipping in 2026? Hardware lists, default-on / default-off behavior, vendor pushback that survived from 2022 into 2026 -- the gap between marketing claim and shipping reality.

6. Pluton in 2026 -- what is shipping, where, and how to verify

The 2020 announcement is now five and a half years old. The 2022 first-silicon shipment is four. What is the actual fleet shape in 2026?

The Microsoft-published hardware list

The current Microsoft Learn Pluton page enumerates the supported silicon: AMD Ryzen 6000, 7000, 8000, 9000, and Ryzen AI; Intel Core Ultra 200V Series, Ultra Series 3, and Series 3; and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series [@ms-learn-pluton]. Every chip on that list ships with Pluton silicon present on the die. Present and enabled by default are not the same property, which is the point of the next subsection.

Default-on versus default-off varies by OEM SKU

The first x86 silicon to ship with Pluton was AMD Ryzen 6000 "Rembrandt", at CES 2022. Phoronix's launch coverage [@phoronix-2022-amd-ryzen-pluton] confirms that the CES 2022 keynote disclosed the integration. The vendor responses that followed in March 2022 set the OEM-by-OEM posture that the fleet still reflects in 2026. The Register obtained vendor statements [@register-2022-pluton]. Lenovo deployed the chip on AMD Ryzen 6000 ThinkPads but disabled it: "AMD Ryzen 6000 ThinkPads will include Pluton as it's present in those AMD chips, though the feature will be disabled by default"; Intel-powered ThinkPads "will not support Microsoft Pluton at launch"; the Snapdragon 8cx Gen 3 Lenovo X13s did include Pluton [@register-2022-pluton]. Dell's reply was the most direct: "Pluton does not align with Dell's approach to hardware security and our most secure commercial PC requirements" [@register-2022-pluton] [@pcworld-2022-pluton]. HP declined to comment.

The 2024 inflection is the Copilot+ PC program. Microsoft Surface and Qualcomm Snapdragon X Elite / Snapdragon X Series Copilot+ devices ship Pluton enabled by default [@ms-learn-pluton]. This is the first product class where retail-bought Windows 11 hardware turns Pluton on at the factory.The 2024 Copilot+ inflection is the first time a high-volume consumer Windows-PC SKU ships Pluton on by default. Prior to Copilot+, Pluton was either off (Lenovo AMD Ryzen 6000 ThinkPads), absent (Dell), or behind a BIOS toggle the user had to find. Copilot+ collapses the discoverability problem because Windows 11 itself depends on the secure-boot and credential-protection primitives that Pluton hosts when the OEM has enabled it.

Linux 6.3 -- February 20, 2023

The standard TCG Command Response Buffer (CRB) interface that Pluton exposes is reachable from Linux. Phoronix records the merge: "Linus Torvalds merged to Linux 6.3 Git the TPM CRB support for Microsoft's controversial Pluton security co-processor" [@phoronix-2023-pluton-linux63] [@kernel-org-pluton-merge]. The driver author was Matthew Garrett [@kernel-org-pluton-merge]. Pluton-as-TPM is now reachable from non-Windows operating systems via the standard TCG CRB transport. This constrains -- although it does not eliminate -- the "Microsoft-only black box" narrative. The chip speaks the open TCG wire protocol that any operating system can talk to.

Garrett's reverse-engineering -- April 2022

Matthew Garrett's April 2022 disassembly of the Asus ROG Zephyrus G14 BIOS [@garrett-2022-pluton-rev] yielded two facts that matter for the rest of this article. First, the user-controllable BIOS Pluton (HSP) toggle on AMD Ryzen 6000 may not be a hardware power-down. Garrett's reading: "PSP directory entry 0xB BIT36 ... if bit 36 is set, the PSP tells Pluton to turn itself off and will no longer send any commands to it" [@garrett-2022-pluton-rev]. The toggle is a soft fuse. Inventory queries that report "Pluton present" do not always distinguish enabled from soft-disabled. Second, "there's a blob starting at 0x0069b610 that appears to be firmware for Pluton -- it contains chunks that appear to be the reference TPM2 implementation, and it broadly decompiles as valid ARM code" [@garrett-2022-pluton-rev]. The Pluton firmware blob is, on the silicon Garrett looked at, an ARM image derived from the TCG TPM 2.0 reference code. That is the observation that makes CVE-2025-2884 (section 8) reachable inside Pluton firmware too.

On AMD Ryzen 6000 / 7000 / 8000 platforms, the OEM can set PSP directory entry 0xB bit 36 in the AMD-firmware part of the BIOS to instruct the PSP to *"tell Pluton to turn itself off"* [@garrett-2022-pluton-rev]. This is a soft fuse, not a hardware power-down. The host's TPM advertisement (`Get-Tpm`) does not always distinguish enabled-Pluton from soft-disabled-Pluton; verification requires inspecting the BIOS-level Pluton (HSP) toggle directly, or correlating against the Plug-and-Play device list.

Note: Garrett's PSP-directory soft-fuse documentation [@garrett-2022-pluton-rev] is the practical pitfall of any 2026 Pluton procurement audit. An OEM can ship AMD Ryzen 6000 / 7000 / 8000 silicon with Pluton soft-disabled at boot. Inventory queries that count "Pluton-present" SKUs without correlating against the BIOS-level Pluton (HSP) toggle will overcount by an unknown margin. Section 10 walks the practical detection path.

The fleet shape, in one comparison table:

Platform	First shipped	Default state at launch	Vendor posture today	Linux support
AMD Ryzen 6000 mobile	January 2022 [@phoronix-2022-amd-ryzen-pluton]	Off on Lenovo ThinkPad [@register-2022-pluton]; Dell declined [@pcworld-2022-pluton]	Per-OEM; soft-fuse trap on Lenovo	Linux 6.3 CRB driver [@phoronix-2023-pluton-linux63]
AMD Ryzen 7000 / 8000 / 9000 / Ryzen AI	2023-2025	Per-OEM SKU	Microsoft Learn lists as supported [@ms-learn-pluton]	Same CRB driver
Intel Core Ultra 200V / Series 3	2024-2025	Per-OEM SKU	Microsoft Learn lists as supported [@ms-learn-pluton]	Same CRB driver
Snapdragon 8cx Gen 3 (Lenovo X13s)	2022	On at launch [@register-2022-pluton]	Shipping	Same CRB driver
Snapdragon X Series Copilot+ PCs	2024	On by default [@ms-learn-pluton]	Microsoft + Qualcomm core program	Same CRB driver
Microsoft Surface Copilot+	2024	On by default [@ms-learn-pluton]	First-party Microsoft hardware	Same CRB driver

flowchart LR AMD[AMD Ryzen 6000-9000
+ Ryzen AI] Intel[Intel Core Ultra 200V
Series 3] Qualcomm[Qualcomm Snapdragon
8cx Gen 3 + X Series] Lenovo[Lenovo
ThinkPad / X13s] Dell[Dell
commercial] HP[HP
commercial] Surface[Microsoft Surface
Copilot+] OEMx[Snapdragon X
Copilot+ OEMs] Off[Default off
at launch] Vendor[Vendor declined
to ship] On[Default on
at retail] AMD --> Lenovo AMD --> Dell AMD --> HP Intel --> Lenovo Qualcomm --> Lenovo Qualcomm --> Surface Qualcomm --> OEMx Lenovo -->|2022 Ryzen 6000| Off Dell -->|"does not align"| Vendor HP -->|declined comment| Vendor Lenovo -->|X13s 8cx Gen 3| On Surface --> On OEMx --> On

The detection logic for the Garrett soft-fuse trap, mocked here so the structural shape is explicit:

{// Mock of the PSP directory entry 0xB inspection that Garrett 2022 // documented. Real verification reads the AMD-firmware bytes off the // SPI flash; this demonstrates the bit-36 check that decides // "enabled" vs "soft-disabled". function plutonState(plutonPresent, pspDir0xB_BIT36) { if (!plutonPresent) return 'absent'; if (pspDir0xB_BIT36 === 1) return 'soft-disabled'; // PSP told to silence Pluton return 'enabled'; } console.log('Pluton present, BIT36=0 =>', plutonState(true, 0)); console.log('Pluton present, BIT36=1 =>', plutonState(true, 1)); console.log('No Pluton silicon =>', plutonState(false, 0));}

Pluton is not the only on-die security processor in 2026. Apple has the Secure Enclave Processor. Google has Titan M2. The OCP coalition has Caliptra. How does Pluton compare, and what does the comparison reveal about Microsoft's design choices?

7. Competing approaches -- Apple SEP, Google Titan M2, OpenTitan, Caliptra, Cerberus

Pluton is not alone. The platforms below are its nearest analogues -- the strongest evidence that Microsoft's design choices were choices, not technical necessities.

Apple Secure Enclave Processor

Apple's Apple Platform Security documentation describes SEP as "a dedicated secure subsystem integrated into Apple [SoC] ... isolated from the main processor to provide an extra layer of security" [@apple-sep]. By deployment count it is the most mature single-vendor on-die security processor on the planet -- shipping in every iPhone since the iPhone 5s (2013), every iPad since iPad Air, and every Apple-silicon Mac [@apple-sep] [@wikipedia-apple-silicon]. The architecture has matured generation by generation: a Boot ROM as the hardware root of trust; an Apple-customised L4 microkernel; a Memory Protection Engine that combines AES-XEX with CMAC and an anti-replay tree on A11 / S4 and later; a Boot Monitor on A13 and later that hashes the loaded image and updates the SCIP (System Coprocessor Integrity Protection) settings before transferring control; and on A14 / M1 and later, the Memory Protection Engine "supports two ephemeral memory protection keys" -- one for SEP-private data and a second one shared with the Secure Neural Engine [@apple-sep].

The trade-off versus Pluton is not the architecture -- it is the governance model. Apple owns the silicon, the operating system, the signing key, and the device. The multi-signer political question never arises because there is only one signer for every layer of the stack. The cost: complete lock-in. The Apple T2 line, which shipped in 2017-2020 Intel Macs as a discrete A10-derived security chip running bridgeOS, inherited the A10 Boot ROM [@wikipedia-apple-t2]. The A10 Boot ROM has the structurally important property that no Boot-ROM-resident bug can be patched without silicon respin -- which the checkm8 / blackbird class of jailbreaks demonstrated end-to-end. T2 was discontinued June 5, 2023 [@wikipedia-apple-t2]. The lesson is direct: renewable security (Seven Properties #6) is not optional. Even Apple's vertically integrated stack pays the price when a generation ships without it.

A dedicated secure subsystem integrated into Apple [SoC] ... isolated from the main processor to provide an extra layer of security. -- Apple, *Apple Platform Security* [@apple-sep]

Google Titan M / Titan M2 and OpenTitan

Google announced Titan M with the Pixel 3 launch in October 2018 [@pixel-3-titan-m]: "This year, with Pixel 3, we're advancing our investment in secure hardware with Titan M, an enterprise-grade security chip custom built for Pixel 3..." [@pixel-3-titan-m]. Titan M2 followed with Pixel 6 in October 2021 [@pixel-6-titan-m2]. Both are discrete or in-package security chips on Pixel for Android Verified Boot, StrongBox-grade key storage, anti-rollback, and lock-screen verification. Both are Google-vertical: Google designs the chip, Google operates the cloud back end, Google ships the OS.

OpenTitan is the open-source descendant. Hosted by lowRISC, it is "the first open source project building a transparent, high-quality reference design and integration guidelines for silicon root of trust (RoT) chips" [@opentitan-home]. RISC-V Ibex core; hardware AES, HMAC, KMAC, and OTBN big-number engines; full RTL, ROM, and verification stack public; Apache 2.0 license. OpenTitan reached commercial availability on February 13, 2024 [@opentitan-commercial] -- the first open-source silicon project to do so. The press release names the nine coalition members verbatim: "Google, Winbond, Nuvoton, zeroRISC, Rivos, Western Digital, Seagate, ETH Zurich and Giesecke+Devrient, hosted by the non-profit lowRISC CIC" [@opentitan-commercial]. OpenTitan is the closest existing answer to "what would an open-source Pluton look like?" -- but as of 2026 it is discrete or in-package, not on-die in an application SoC.The lowRISC press release is precise on a point that secondary press has frequently flubbed. lowRISC is the host organisation for OpenTitan; it is not a member of the nine. The nine commercially announced coalition members on February 13, 2024 are Google, Winbond, Nuvoton, zeroRISC, Rivos, Western Digital, Seagate, ETH Zurich, and Giesecke+Devrient [@opentitan-commercial]. The distinction matters because lowRISC's role is governance, not deployment.

Caliptra

The OCP coalition's open-source datacenter Root of Trust. Specification, RTL, ROM, FMC, and runtime are public on CHIPS Alliance [@caliptra-github] [@caliptra-spec]. Founders: Microsoft, Google, AMD, NVIDIA. Google Cloud's Caliptra-1.0 announcement reports: "the Caliptra specification and open-source hardware and software implementation is complete, reaching the revision 1.0 milestone." The Google Cloud post adds that the Caliptra IP block is being integrated by member companies into chips expected in the market in 2026. Caliptra targets "datacenter-class SoCs like CPUs, GPUs, DPUs, TPUs" [@caliptra-github]. It is not a Pluton substitute on Windows clients -- the form factor is different and the threat model assumes server-side operators.

The instinct, on reading that Caliptra is open-source and multi-vendor, is to ask why Microsoft does not just put Caliptra into the next Surface. Three reasons. First, form factor: Caliptra is a datacenter-SoC IP block; the integration target is a CPU / GPU / DPU / TPU package on a \$20,000 server motherboard, not a \$700 ultrabook. Second, signer model: Caliptra is multi-vendor *by deployment*, but each Caliptra-equipped chip still has *one* signer -- the integrating chip vendor (AMD signs AMD's Caliptra firmware; NVIDIA signs NVIDIA's). The choice of signer moved; the count of signers per chip did not. Third, threat model: Caliptra's RTM serves a server attestation flow ending at a fleet operator (Google, Microsoft, NVIDIA, the rack owner), not a client BitLocker flow that has to survive a powered-off laptop on an airport conveyor belt.

Caliptra is the right counter-design to the governance of Pluton, not its form factor. It is what makes the single-signer-per-chip choice in Pluton-on-PC visible as a choice, not a technical necessity. That visibility is the whole reason this section exists.

Project Cerberus -- still in production

Cerberus has not been retired. Microsoft Learn describes it as "a NIST 800-193 compliant hardware root-of-trust with an identity that cannot be cloned" [@ms-learn-cerberus] [@nist-sp-800-193] running in Azure datacenters; the GitHub reference implementation [@azure-cerberus-github] is actively maintained. In the November 2020 Pluton announcement, Microsoft framed Cerberus as the server-side counterpart to Pluton's client-side root of trust [@ms-pluton-blog-2020] -- the two are designed to compose, with Pluton providing the per-CPU identity that an upstream Cerberus chip (or Caliptra-equipped server) can attest. The distinction between Pluton-as-client-RoT and Cerberus-as-server-RoT is operational, not architectural rivalry.

The cross-design comparison

Dimension	Pluton-on-PC	Apple SEP	Google Titan M2	Caliptra	Cerberus
Physical location	On-die in application SoC	On-die in Apple SoC	Discrete or in-package on Pixel	On-die in datacenter SoC	Discrete on server BMC
Trust anchor	Microsoft (chip-firmware signer)	Apple (vertical)	Google (vertical)	Per-chip integrator	Operator (Microsoft on Azure)
Update channel	Windows Update [@ms-learn-pluton]	iOS / macOS update	Android / Pixel update	Server-side platform update	OEM / operator update
Firmware language	Rust (2024+) [@ms-learn-pluton]	Apple-customised L4 [@apple-sep]	Not publicly disclosed	Open-source firmware [@caliptra-github]	C / C++ (open) [@azure-cerberus-github]
Open source	Closed	Closed	Closed (driver public)	Open (RTL + firmware)	Open (RI on GitHub)
Multi-signer	Single	Single	Single	Multi-vendor by deployment	Per-deployment
Standards exposure	TCG TPM 2.0 over CRB	Apple-private	Android Verified Boot, StrongBox	Caliptra spec; SPDM 1.3 in 2.0	NIST SP 800-193
Best-known structural attack	None peer-reviewed Pluton-specific (TPMScan corpus only [@tpmscan-2024])	T2 inherits A10 Boot ROM (checkm8) [@wikipedia-apple-t2]	None public on Titan M2	Reviewed open-source RTL	Mature; deployed since 2017
Best suited for	Windows 11 client procurement	Apple devices	Pixel devices	Datacenter SoC integration	Server BMC RoT
Form factor	General-purpose PC	Apple devices	Pixel phones	Datacenter SoCs	Server motherboards

The political question made architectural. Caliptra and OpenTitan answer "what would multi-signer / open-source look like?" in the datacenter. Apple SEP demonstrates that the single-vendor / single-signer model is operationally durable at consumer scale -- but only when the vendor owns the entire stack. Pluton sits in the awkward middle: single-signer but multi-OEM, closed-firmware but open-Linux-driver, on-die but the chip vendor is not the firmware vendor. That middle position is what makes the procurement debate hard, and it is what makes the open problems in section 9 unresolved.

Pluton is the strongest on-die RoT for Windows clients in 2026, with the fastest patch cadence, the broadest hardware list, and the most mature design pedigree. What can it still not do?

8. What Pluton still cannot do

Two structural limits inherited from the prior article, and a third that is specific to single-signer on-die firmware. The first two say what no on-die RoT can do. The third says what no Microsoft-only-signer RoT can do. The worked example is CVE-2025-2884.

Limit 1 -- RTS+RTR, not RTE

A passive cryptoprocessor -- including Pluton -- cannot detect that the wrong code measured itself. It can only refuse to release sealed material when PCRs do not match the stored policy. The prior article's section 7.1 [@prior-tpm-in-windows] walks the bit-level reasoning. On-die does not change this. Pluton implements Root of Trust for Storage and Root of Trust for Reporting; it does not implement a Root of Trust for Execution that runs the code outside the chip on the reader's behalf.

Limit 2 -- The VMK transits OS RAM at unseal

The Volume Master Key must enter RAM during Trusted Boot, and once unsealed it lives in OS-controlled memory. An attacker who reads OS RAM at the release moment, or any time after, defeats TPM-only BitLocker regardless of TPM strength (prior article sections 7.2 and 7.3 [@prior-tpm-in-windows]). Pluton's on-die location eliminates the dTPM bus surface; it does not change which side of the unseal boundary the VMK lives on. This is why Virtualization-Based Security, Credential Guard, DRTM, and System Guard Secure Launch exist as complements, not substitutes, to the TPM/Pluton primitive.

Limit 3 -- Single-signer revocation impossibility

This is the new one. State the result precisely: if the on-die RoT firmware can only be authenticated by a single signer S, then the chip's trust anchor cannot be retired without bricking the chip's firmware-update path, regardless of whether S is compromised, coerced, or jurisdictionally constrained. This is not a cryptographic impossibility. It is a key-management impossibility. Revocation requires either (a) a second trust anchor provisioned at chip manufacture and held outside S's control -- i.e., multi-signer at the chip level, not just at the deployment level -- or (b) physical replacement of the silicon. Caliptra and Cerberus weaken the failure mode by moving the signer to the integrating chip vendor or to the operator, but they do not eliminate it; each chip still has one signing root.

A key-management (not cryptographic) impossibility: a chip whose firmware-authentication root has one signer in ROM cannot have that signer retired without bricking the firmware-update path or replacing the silicon. Pluton-on-PC silicon shipping today bakes a Microsoft-rooted public key into ROM. See the §8 prose paragraph above and the Callout below for the precise statement of conditions and the operational reasoning (FIDO2 / threshold-signature analogues; §5 trust-shift cross-anchor).

Note: There is no cryptographic objection to multi-signer RoT firmware. The math has been understood since the FIDO2 multi-credential work, and threshold signatures have been a primitive for decades. The objection is operational: replacing public keys after the chip is in the field requires either fab-time multi-signer or hardware replacement. Section 5 named the choice; this Callout names what makes it hard to undo.

Worked example -- CVE-2025-2884

On June 10, 2025, NVD published CVE-2025-2884 [@cve-2025-2884]. The CERT/CC coordination ticket is VU#282450 [@cert-cc-vu-282450]. The vulnerability is an out-of-bounds read in the CryptHmacSign function of the TCG TPM 2.0 reference implementation, Level 00, Revision 01.83 (March 2024). The CERT/CC document describes the impact: "An authenticated local attacker can send malicious commands to a vulnerable TPM interface, resulting in information disclosure or denial of service of the TPM" [@cert-cc-vu-282450].

Crucially for attribution, the CERT/CC ticket is explicit about who reported it and who wrote it up: "Thanks to the reporter, who wishes to remain anonymous. This document was written by Vijay Sarvepalli" [@cert-cc-vu-282450]. The reporter is anonymous; the CERT/CC document author is Vijay Sarvepalli. Tech press accounts that have attributed the disclosure to Quarkslab are incorrect; the primary CERT/CC record is dispositive.The Quarkslab attribution that some 2025 tech-press accounts use for CVE-2025-2884 is contradicted by the primary CERT/CC record VU#282450, which says verbatim: "Thanks to the reporter, who wishes to remain anonymous. This document was written by Vijay Sarvepalli" [@cert-cc-vu-282450]. The reporter is anonymous. The document author is Vijay Sarvepalli. This article uses that attribution and only that attribution.

Multiple downstream products are affected. Intel published Security Advisory SA-01209 [@intel-sa-01209]. Siemens published SSA-628843 [@siemens-ssa-628843]. The libtpms project assigned CVE-2025-49133 [@cve-2025-49133] for its own derivative; the upstream fix landed in libtpms commit 04b2d8e9 [@libtpms-commit-04b2d8e9]. The TCG itself coordinated VRT0009 [@tcg-vrt0009-advisory] and a TPM 2.0 Library Specification v1.83 errata (cited via NVD as the verifiable mirror -- the TCG site returns 403 to non-browser User-Agents).

Why this is the right worked example for Pluton. Garrett's April 2022 reverse-engineering [@garrett-2022-pluton-rev] documented that the Pluton firmware blob in the AMD Ryzen 6000 BIOS is "firmware for Pluton -- it contains chunks that appear to be the reference TPM2 implementation, and it broadly decompiles as valid ARM code." The Pluton firmware blob is an ARM image derived from the TCG TPM 2.0 reference code. So a CryptHmacSign OOB read in the TCG reference code was present in Pluton firmware too, on the silicon Garrett looked at, until the firmware was rebuilt against the patched reference implementation. On-die location did not stop the bug from existing.

What did matter for outcomes was the dwell time before the vulnerable code was replaced. The structural change that distinguishes Pluton from a 2014 dTPM is not "where the chip is" but "who can patch it, and how fast." A discrete TPM with the same bug would wait for the dTPM vendor to push a firmware build, the OEM to package a UEFI capsule, the OEM to test it across its product lines, and the user to install it. Microsoft's Pluton patch path is the Windows Update channel -- the same channel that already delivers kernel updates to roughly 1.4 billion endpoints on a Patch Tuesday cadence. Section 5 design choice 4 walked the channel-shape change and the no-SLA hedge; this is what makes the channel the security property that matters here.

Realization	Patch path	Approximate latency	Bottleneck
Discrete TPM	dTPM vendor build -> OEM UEFI capsule	Quarters to years	OEM fleet test + per-OEM rollout
Intel PTT (CSME)	Intel ME firmware -> OEM UEFI capsule	Months to quarters	OEM UEFI capsule path (TPM-Fail lesson)
AMD fTPM (PSP)	AMD AGESA -> OEM UEFI capsule	Months to quarters	Same OEM UEFI capsule path
Pluton-on-PC	Microsoft signs -> Windows Update	Days to weeks (no published SLA)	Microsoft signing key + WU infrastructure

flowchart TD Ref[TCG TPM 2.0 reference
Level 00 Rev 01.83
March 2024] CVE[CVE-2025-2884
CryptHmacSign OOB read
NVD published 2025-06-10] Pluton[Pluton firmware
ARM blob
per Garrett 2022] Intel[Intel SA-01209] Siemens[Siemens SSA-628843] Libtpms[libtpms
CVE-2025-49133
commit 04b2d8e9] TCG[TCG VRT0009
+ TPM 2.0 v1.83 errata] Ref --> CVE CVE --> Pluton CVE --> Intel CVE --> Siemens CVE --> Libtpms CVE --> TCG

Key idea: Pluton's structural advantage is the patch path, not the silicon location. CVE-2025-2884 demonstrates that on-die location does not stop a TCG-reference-code bug from existing on a Pluton chip. What changes between a 2014 dTPM and a 2025 Pluton is not "where the chip is" but "who can patch it, and how fast." On-die is necessary but not sufficient. The breakthrough is the update path. The cost of the update path is the political question section 1 promised.

If single-signer revocation is impossible, what would multi-signer Pluton look like? And what other open problems does this design choice leave unsolved?

9. Open problems Pluton has named but not solved

Five concrete open problems sit in front of any 2026 reader of the Pluton design. Each is mapped below to the closest existing partial result. None has a public solution.

Open problem 1 -- Multi-signer firmware for on-die client RoTs

No public proposal exists for multi-signer Pluton on a Windows client. Caliptra moves the signer to the integrating chip vendor [@caliptra-github], so the count of signers per chip remains one even when the count per deployment is many. There is no public proposal for two simultaneous signers on a single client RoT (e.g., Microsoft and a sovereign signer; or AMD and Microsoft for a Pluton-on-AMD chip). The closest existing analogues live elsewhere -- IETF KEYTRANS for transparency-logged keys [@ietf-keytrans-wg], HSM-cluster split-signing for operational continuity -- but none has a hardware-RoT counterpart that has shipped. The unresolved engineering question, named in the prior article's section 8, is whether multi-signer can be added without losing the timely-update property that motivated Pluton in the first place.The IETF KEYTRANS working group [@ietf-keytrans-wg] is the closest active venue for the multi-signer thread, although KEYTRANS is concerned with end-user identity-key transparency rather than firmware-signing keys. The transparency-log primitive is the same (a Merkle tree of signed claims, auditable by independent verifiers); the hardware-RoT integration is missing. A reader interested in the multi-signer thread should track KEYTRANS and the OpenTitan / Caliptra governance discussions in parallel.

Open problem 2 -- Regulatory jurisdiction of single-signer firmware

Pluton's signing key is, in effect, a US export-controlled artifact. The EU Cyber Resilience Act entered into force on December 10, 2024, with the bulk of its security obligations applying from December 11, 2027 and reporting obligations applying from September 11, 2026 [@eu-commission-cra]; from the 2027 date it will require demonstrable security properties for products with digital elements, without specifying who the signer must be. Sovereign fleets -- the German Federal Office for Information Security (BSI), Singapore, Switzerland -- have varying postures on whether a non-domestic RoT is acceptable. Read in 2026, the Dell and Lenovo statements of March 2022 [@register-2022-pluton] [@pcworld-2022-pluton] are the first public push-back along this axis. The procurement debate is not technical; it is jurisdictional. There is no current proposal for a Pluton variant that satisfies a non-US sovereign procurement requirement.

The EU Cyber Resilience Act entered into force on December 10, 2024 [@eu-commission-cra]. Reporting obligations apply from September 11, 2026; the main security obligations apply from December 11, 2027 [@eu-commission-cra]. CRA does not name signers; it requires demonstrable security properties, vulnerability handling, and update channels for products sold into the EU. A single-signer foreign-rooted RoT can satisfy CRA. Whether it satisfies *sovereign* procurement requirements is a separate question.

The German BSI's Common Criteria PP-0084 protection profile [@bsi-pp-0084] (used historically for Infineon SLB 9670 / 9672 dTPMs) bakes in expectations of the chip-supplier governance that a US-rooted Pluton does not satisfy without a parallel certification path. Switzerland's federal IT procurement, Singapore's CSA, and a number of EU member-state ministries take comparable positions. None of these is a formal ban on Pluton; all of them are formal preferences that procurement officers must navigate.

The architectural fix -- a sovereign signing-root variant of Pluton -- has not been publicly proposed by Microsoft. The economic incentives for such a variant are not obviously favourable: every additional signer adds operational cost to the Windows Update path that Pluton's design specifically optimises. The procurement market is, as of 2026, deciding both ways, and the 2022 Dell statement is the most-cited public datapoint of a vendor declining to take the bet.

Open problem 3 -- SPDM 1.3 component attestation on PC

Pluton attests the host SoC. It does not yet attest individual components -- NICs, NVMe SSDs, PCIe accelerators -- on Windows clients. The DMTF's Security Protocol and Data Model (DSP0274) is the wire protocol for component-to-component attestation: a publication cadence of 1.3.0 in June 2023, 1.3.2 in September 2024, and 1.3.3 in December 2025 [@dmtf-dsp0274]. The Caliptra MCU project's Rust SPDM responder design page is the most explicit public reference for what an SPDM 1.3 endpoint looks like inside an on-die RoT: SPDM is "a protocol designed to ensure secure communication between hardware components by focusing on mutual authentication and the establishment of secure channels over potentially insecure media... using X.509v3 certificates" [@caliptra-mcu-spdm], with a fixed message inventory (GetVersion, GetCapabilities, NegotiateAlgorithms, GetDigests, GetCertificate, Challenge, GetMeasurements, KeyExchange, Finish) carried over an MCTP transport binding. Caliptra 2.0's RTL design freeze in October 2024 [@caliptra-ocp-2024-news] commits SPDM as part of the Caliptra Subsystem reference stack: "Reference Stack: MCTP PLDM, SPDM" [@caliptra-ocp-2024-news]. That is the server-side commitment.

The PC-client equivalent is not on the public record as of May 2026. Microsoft Learn's Pluton page does not mention SPDM, DSP0274, MCTP, or component attestation [@ms-learn-pluton]. There is no Microsoft-published Windows feature or Pluton-firmware milestone that names "SPDM responder" or "component attestation on PC" as a roadmap deliverable. The architectural question -- whether Pluton becomes the platform's SPDM responder, whether each component (NVMe controller, Wi-Fi card) is its own responder and Pluton aggregates the evidence, or whether Windows Defender System Guard owns the Windows-side appraiser -- is not answered by any published Microsoft document on the public record as of May 2026. The closest existing reference design lives in chipsalliance/caliptra-mcu-sw (Rust SPDM responder, X.509-anchored mutual auth), and the most likely standards venues for a PC-client profile are the DMTF SPDM WG (the wire protocol owner) and the OCP Security WG (the appraisal-framework owner). Until Microsoft publishes a Windows-feature surface that owns the SPDM responder on PC, "Pluton attests the host SoC, period" is the article's honest description of the 2026 state.

Open problem 4 -- Pluton-Caliptra interoperation

A Pluton-rooted client should, in principle, be able to attest to a Caliptra-rooted server in a single end-to-end protocol with both roots of trust visible in the resulting evidence chain. The wire-protocol candidates exist and are largely standardised. What is missing is the composite-attestation profile that wires them into a single client-to-server flow.

The candidate stack as of May 2026 lives across three SDOs and one OCP project. The DMTF owns SPDM 1.3 for component-to-component attestation [@dmtf-dsp0274] [@caliptra-mcu-spdm]. The IETF Remote Attestation Procedures (RATS) Working Group owns the architectural primitives for what an evidence-and-results message contains: RFC 9711 (April 2025, Standards Track) is the Entity Attestation Token (EAT), a CBOR Web Token (CWT) or JSON Web Token (JWT) form for "an attested claims set that describes the state and characteristics of an entity" [@ietf-rfc9711]; draft-ietf-rats-corim-10 (in WG Last Call as of March 2026) is the Concise Reference Integrity Manifest, the appraisal-time profile for "Endorsements and Reference Values in CBOR format" [@ietf-corim]; draft-ietf-rats-msg-wrap-23 (in the RFC Editor queue since December 2025) is the Conceptual Message Wrapper, a CBOR-tag / JWT / CWT / X.509-extension envelope for composing evidence, attestation results, endorsements, and reference values across protocols [@ietf-msg-wrap]. The full RATS WG document inventory at datatracker.ietf.org/wg/rats/documents/ shows additional active drafts on multi-verifier composition, posture-assessment, EAR (an evidence-appraisal-results profile), and PKIX key attestation [@ietf-rats-wg-docs]. The OCP Security WG owns the third-party appraisal framework: OCP S.A.F.E. v2.0 (March 2026) added explicit CoRIM SFR support and is the public mechanism by which a fleet operator certifies that a vendor's firmware-appraisal evidence has been independently audited [@ocp-safe-framework]. Caliptra 2.0's reference stack already wires SPDM, MCTP, and PLDM [@caliptra-ocp-2024-news]; the Caliptra MCU Rust responder shows the SPDM endpoint shape [@caliptra-mcu-spdm].

What is missing is a single published profile that walks the chain end to end: a Pluton-rooted Windows client emits a Get-Tpm-derived attestation (Pluton acting as evidence producer); the network carries CMW-wrapped evidence with a CoRIM endorsement set the verifier consumes; the verifier emits an EAT-formatted attestation result; a Caliptra-rooted server consumes the result and gates fleet membership. Each leg has a draft. No public SDO document binds them into a single Pluton-Caliptra composite-attestation profile with reference implementations on both ends. The natural venue is a joint DMTF SPDM WG and OCP Security WG profile, with IETF RATS as the architectural reference; the natural reference implementation pair is chipsalliance/caliptra-mcu-sw on the responder side and a Windows-feature surface (which Microsoft has not named publicly) on the client side. Until that joint profile exists and ships reference implementations, Pluton-Caliptra interoperation in 2026 is two roots-of-trust deployed, with no published end-to-end protocol that visibly carries both signatures into a single evidence chain.

Open problem 5 -- Supply-chain integrity beyond firmware signing

The Pluton signing root protects firmware integrity after the chip ships. Listing the supply-chain steps in chronological order makes the residual trust gap concrete: (1) the IP-licensing handshake from Microsoft to AMD / Intel / Qualcomm; (2) tape-out and process-design-kit integration at TSMC; (3) wafer fabrication; (4) per-vendor package assembly; (5) OEM motherboard integration; (6) OEM firmware integration (BIOS / UEFI vendor code that surrounds the Pluton block); (7) retail distribution. None of these steps is presently attested by Pluton itself; the on-die signing root is applied at step 6 and exercised from step 7 onward, but steps 1-5 are out of band of the chip's RoT.

The closest existing partial answer is a layered combination of three primitives. First, DICE -- TCG's Device Identifier Composition Engine -- gives every component a Hardware Root of Trust (HRoT) which uniquely identifies the component and attests component firmware [@tcg-dice], anchored by a per-die Unique Device Secret (UDS) that derives a Compound Device Identifier (CDI) per layer; the Open Profile for DICE v2.6 [@open-dice] is the reference profile and explicitly cites the TCG normative parent. DICE answers step 4-5 (per-package and per-board identity) provided the integrator provisions a UDS on the die. Second, SPDM 1.3 [@dmtf-dsp0274] [@caliptra-mcu-spdm] is the wire protocol that surfaces those DICE identities to a verifier at runtime: a per-component SPDM responder (carried over MCTP / PLDM in Caliptra 2.0's stack [@caliptra-ocp-2024-news]) emits a measurement set tied to its CDI. Third, OCP S.A.F.E. (Security Appraisal Framework and Enablement) v2.0 [@ocp-safe-framework] is the third-party-audit framework that lets a fleet operator certify that a Device Vendor's firmware was assessed by a Security Review Provider; the v2.0 March 2026 revision explicitly added CoRIM SFR support, wiring S.A.F.E. into the IETF RATS appraisal stack [@ietf-corim]. Together, DICE + SPDM + S.A.F.E. answer "is each component what its vendor said it was, and has the firmware been independently appraised?"

What is not built is the verifier infrastructure that consumes that evidence end to end. There is no public per-component-EK transparency log analogous to Certificate Transparency for the web PKI; there is no Pluton-rooted client-side appraiser that consumes per-component SPDM evidence and gates Windows boot on it; there is no shipping fleet-side hardware-bill-of-materials (HBOM) audit pipeline that ingests S.A.F.E. reports and Caliptra-rooted server attestations together. The supply-chain trust is named by DICE + SPDM + S.A.F.E.; it is not operationalised end to end on a 2026 Windows 11 client. The honest framing is: Pluton's signing root closes step 6 and step 7; DICE + SPDM + S.A.F.E. are the public standards that, if implemented in the Windows feature stack, would close steps 4-5; steps 1-3 (IP licensing, tape-out, wafer) remain out of band of any of the public standards above.

The 10-property scoreboard for an ideal client-PC on-die RoT

Five open problems converge onto a single scoreboard. This article's SOTA review enumerates ten properties an ideal client-PC on-die Root of Trust in 2026 would satisfy (expanding the prior article's six TPM-ideal properties [@prior-tpm-in-windows] with multi-signer governance, public RTL, native PQC, and component attestation): (1) on-die location with no off-package bus; (2) an isolated TEE shared with nothing else; (3) memory-protected DRAM with AES + authenticated + anti-replay protection; (4) OS-channel firmware updates; (5) memory-safe firmware language; (6) multi-signer firmware authentication; (7) public RTL and verification flow; (8) native post-quantum primitives (ML-DSA, ML-KEM); (9) component attestation across PCIe / NVMe / NIC via SPDM 1.3; (10) high-assurance certification depth (Common Criteria EAL4+ and FIPS 140-3). No shipping method satisfies all ten; the matrix below shows where each design sits.

Property	Pluton-on-PC 2026	Apple SEP (A14/M1+)	OpenTitan (Earl Grey / Darjeeling)	Caliptra 2.0 (RTL freeze Oct 2024)	Cerberus (current production)
1. On-die, no bus	Yes [@ms-pluton-blog-2020]	Yes [@apple-sep]	Discrete or in-package	Yes [@caliptra-github]	No (discrete on BMC)
2. Isolated TEE	Yes (dedicated)	Yes [@apple-sep]	Yes (whole chip)	Yes (RTM block)	Yes (whole chip)
3. AES + authenticated + anti-replay DRAM	Not on public record	Yes (A14/M1+) [@apple-sep]	Limited (chip-internal SRAM)	N/A (no DRAM responder role)	N/A (server BMC)
4. OS-channel firmware updates	Yes (Windows Update) [@ms-learn-pluton]	Yes (iOS / macOS) [@apple-sep]	Project-managed	Server platform updates	OEM / operator updates
5. Memory-safe firmware	Yes (Rust 2024+) [@ms-learn-pluton]	Apple-customised L4 [@apple-sep]	Rust runtime in OpenTitan codebase	Rust [@caliptra-github] [@caliptra-mcu-spdm]	C / C++ [@azure-cerberus-github]
6. Multi-signer	No (Microsoft only)	No (Apple only)	No (per-deployment)	Multi-vendor by deployment, single per chip [@caliptra-github]	Per-deployment signer
7. Public RTL and verification	No	No	Yes [@opentitan-home] [@opentitan-commercial]	Yes [@caliptra-github]	Yes (reference impl) [@azure-cerberus-github]
8. Native PQC (ML-DSA, ML-KEM)	No public commitment date	No public commitment date	On roadmap [@opentitan-home]	Yes (RTL freeze incl. Dilithium + Kyber) [@caliptra-ocp-2024-news]	No
9. Component attestation (SPDM 1.3)	No (open problem 3)	Apple-private equivalents	Not yet	Yes (Reference Stack: MCTP PLDM, SPDM) [@caliptra-ocp-2024-news] [@caliptra-mcu-spdm]	NIST SP 800-193 framing [@ms-learn-cerberus]
10. EAL4+ and FIPS 140-3	No equivalent posture in 2026 [@bsi-slb-9670-cc]	Not pursued for SEP	In assessment	Not pursued	Some certifications via OEM
Properties satisfied	4 (1, 2, 4, 5)	4 (1, 2, 3, 4)	2 (5, 7)	3 (5, 7, 8) -- on track for 9	1-2 (7 + partial 9)

The matrix says two things at once. First, no shipping on-die RoT in 2026 satisfies more than four of the ten properties; the scoreboard is sparse on purpose. Second, the closest trajectory to the ten-property ideal is not any single design; it is the union of Pluton's properties (1, 2, 4, 5), Caliptra's open RTL and PQC commitments (7, 8, 9), and OpenTitan's open RTL (7). A hypothetical Pluton variant that adopted Caliptra-style multi-signer governance, OpenTitan-style RTL transparency, and the Caliptra 2.0 SPDM responder reference stack would satisfy 1, 2, 4, 5, 6, 7, 8, 9 -- eight of the ten -- with high-assurance certification (10) the residual procurement question. That hypothetical Pluton has not been publicly proposed by Microsoft. It is, however, the design the matrix names as the destination if all five open problems above were closed.

The shape of the unanswered question

Open problem	Why it matters	Closest existing partial result	Outstanding gap
Multi-signer client RoT	Single-signer revocation impossibility	Caliptra (multi-vendor by deployment, single-signer per chip) [@caliptra-github]	No two-signer-per-chip proposal for client
Regulatory jurisdiction	Sovereign procurement, EU CRA (in force Dec 10 2024, reporting from Sep 11 2026, main obligations from Dec 11 2027) [@eu-commission-cra]	March 2022 Dell / Lenovo posture [@register-2022-pluton] [@pcworld-2022-pluton]	No sovereign Pluton variant
SPDM 1.3 on PC	Component attestation beyond the SoC	Caliptra 2.0 reference stack with SPDM [@caliptra-ocp-2024-news] [@caliptra-mcu-spdm]	No PC-client SPDM responder named on Microsoft Learn
Pluton-Caliptra interop	Composite client-to-server attestation	RATS EAT [@ietf-rfc9711] + CoRIM [@ietf-corim] + CMW [@ietf-msg-wrap] + S.A.F.E. [@ocp-safe-framework]	No joint DMTF / OCP / RATS profile binding the chain end to end
Supply-chain integrity beyond firmware signing	Pre-ship trust (steps 1-5 of the chain)	DICE [@tcg-dice] [@open-dice] + SPDM [@dmtf-dsp0274] + S.A.F.E. [@ocp-safe-framework]	Verifier infrastructure (per-component-EK transparency, HBOM appraiser) not built

All five share the same shape. Pluton has narrowed but not eliminated structural classes of trust. On-die narrowed but did not eliminate the silicon supply chain trust. Microsoft-rooted firmware servicing narrowed but did not eliminate the firmware-signing trust. Component attestation, when it ships on PC, will narrow but not eliminate the per-component supply-chain trust. Each Pluton design choice trades one trust for another; the residual trusts are the ones the article cannot answer technically and must label politically.

On Monday morning, what does the Windows engineer reading this actually do?

10. The Pluton checklist for 2026

Five questions. Each has a one-paragraph answer and a verifiable command or check. The reader who skipped sections 6 and 8 will still avoid the most expensive mistake -- counting "Pluton present" as "Pluton enabled."

Q1 -- Is Pluton present on this device?

Get-Tpm in PowerShell reports ManufacturerIdTxt. The four-character ASCII manufacturer string distinguishes the realisation. MSFT is Pluton; INTC is Intel PTT; AMD (with trailing space) is AMD fTPM; IFX, STM, and NTC cover Infineon, STMicro, and Nuvoton discrete TPMs respectively. The prior article's section 9 [@prior-tpm-in-windows] documents the broader manufacturer-string discovery path. The new Pluton-specific check is the four-letter MSFT value.

Open PowerShell as administrator and run:

Get-Tpm | Select-Object ManufacturerIdTxt, ManufacturerVersion, TpmPresent, TpmReady

A ManufacturerIdTxt of MSFT indicates Microsoft Pluton. INTC is Intel PTT (the firmware TPM in CSME). AMD (with the trailing space) is AMD fTPM (the firmware TPM in the PSP). The same logic is captured in the JavaScript <RunnableCode> mock in section 5 above. For richer detail, run tpm.msc -- the Microsoft Management Console snap-in shows the full TPM identity.

Q2 -- Is Pluton enabled, not just present?

This is the §6 soft-fuse trap. On AMD Ryzen 6000 / 7000 / 8000 silicon, Get-Tpm returning MSFT proves Pluton is exposed as the TPM but does not, on its own, prove Pluton is enabled in firmware (§6's Definition + Callout walk the PSP directory 0xB BIT36 mechanism Garrett 2022 documents [@garrett-2022-pluton-rev]). The procurement-relevant action is to audit BIOS-level Pluton (HSP) toggles and correlate Get-Tpm's manufacturer string with Get-PnpDevice / Device Manager before counting an AMD-Ryzen-6000-class device as Pluton-protected. On Lenovo AMD Ryzen 6000 ThinkPads specifically, the launch posture was Pluton present but disabled by default [@register-2022-pluton] -- so a 2022 ThinkPad inventory query that finds Ryzen 6000 silicon will not, on its own, tell the operator whether Pluton is doing any work.

Q3 -- Is Pluton firmware current?

Microsoft publishes Pluton firmware via Windows Update [@ms-learn-pluton]. Microsoft does not publish a per-release notes feed for Pluton firmware, so the operator must rely on the general Windows Update history and the chip vendor's advisory feed (Intel SA-* for Intel-Pluton silicon; AMD's security bulletins for AMD-Pluton silicon). The procurement-relevant property is that the channel exists and ships. The procurement-relevant question is whether the operator's organisation is willing to depend on that channel.

Q4 -- When to prefer Pluton over dTPM, PTT, or AMD fTPM

Three procurement scenarios where Pluton is the right answer in 2026.

Default Windows 11 client procurement. Pluton on AMD Ryzen 6000 and later, Intel Core Ultra 200V Series and Series 3, and Snapdragon X Series [@ms-learn-pluton]. The Microsoft-supported configuration; the path of least administrative resistance; the only realisation that ships memory-safe firmware on the Patch Tuesday cadence.
Adversary model includes physical access. Andzakovic-class bus sniffing [@andzakovic-2019-tpm-sniffing], faulTPM-class voltage glitching [@jacob-2023-faultpm]. Pluton (on-die, dedicated TEE) closes both surfaces structurally.
Need fast firmware updates for security responses to TCG-reference-code bugs. CVE-2025-2884 is the worked example [@cve-2025-2884]. Pluton's Windows Update servicing is the only realisation in 2026 that does not depend on the OEM UEFI capsule path.

Q5 -- When to not prefer it

Three procurement scenarios where Pluton is not the right answer.

Regulated fleets requiring a non-US trust anchor. German BSI PP-0084-class procurement [@bsi-pp-0084], EU sovereign workloads. Hardened dTPM (Infineon SLB 9670 / 9672, STMicro ST33TPHF) has the certified posture [@bsi-slb-9670-cc]; Pluton has no equivalent EAL4+ certification path on the public record as of 2026 [@bsi-slb-9670-cc].
Air-gapped fleets that cannot accept Windows-Update-delivered firmware. Offline UEFI capsule servicing remains the only operationally feasible patch path; dTPM is the mechanically right choice for that fleet.
Multi-vendor sourcing requirements. dTPM has multiple silicon vendors (Infineon, STMicro, Nuvoton). Pluton has one signer per chip and only the AMD / Intel / Qualcomm silicon paths Microsoft has licensed. Datacenter operators who need multi-vendor sourcing should look at Caliptra [@caliptra-github] -- not a Pluton substitute on Windows clients, but the right answer for datacenter SoC procurement.

Choose Pluton when...	Choose dTPM (or Caliptra) when...
Default Windows 11 client procurement [@ms-learn-pluton]	Sovereign procurement (German BSI, EU sovereign)
Adversary model includes physical access	Air-gapped fleet, no Windows Update channel acceptable
Need Patch Tuesday firmware response cadence	Need EAL4+ / FIPS 140-3 certification posture today
Want memory-safe Rust firmware (2024+ silicon)	Need multi-vendor silicon sourcing
Want on-die dedicated TEE versus shared PSP/CSME	Datacenter SoC integration (Caliptra)

flowchart TD Start[Need a TPM/RoT in 2026?] Q1{Datacenter SoC?} Q2{Sovereign / non-US RoT required?} Q3{Air-gapped fleet?} Q4{Default Windows 11 enterprise?} Caliptra[Caliptra 1.0] DTPM[Hardened dTPM
Infineon SLB 9670/9672
or STMicro ST33TPHF] DTPMcap[Hardened dTPM
offline UEFI capsule path] Pluton[Pluton on AMD Ryzen 6000+
or Intel Core Ultra 200V+
or Snapdragon X Series] Start --> Q1 Q1 -->|Yes| Caliptra Q1 -->|No| Q2 Q2 -->|Yes| DTPM Q2 -->|No| Q3 Q3 -->|Yes| DTPMcap Q3 -->|No| Q4 Q4 -->|Yes| Pluton Q4 -->|No| DTPM

We started with the question Microsoft answered architecturally before the prior article posed it. Where does that leave the political question that even the architectural answer cannot resolve?

11. Frequently asked questions, and one more political question

The architectural answer to "what is the cost of letting Microsoft sign the chip's firmware?" is partial and has been answered by every section above. The remaining piece is a set of common misconceptions, then a closing tied to the prior article.

No. fTPM is a TPM 2.0 task running inside an existing TEE -- Intel CSME (PTT) or AMD PSP. Pluton is a *dedicated* IP block on the SoC die that does not share a TEE with anything else. The threat-model gap that faulTPM exposed [@jacob-2023-faultpm] only closes for Pluton-as-Pluton, not for fTPM running on Pluton-equipped silicon. AMD-Ryzen-6000-class chips can ship Pluton silicon next to the existing PSP-based fTPM; §5 documents the OEM-picks-one mechanism via the Pluton (HSP) BIOS toggle [@garrett-2022-pluton-rev], and faulTPM-class attacks remain valid only on systems the OEM exposes as fTPM. No. Pluton implements the TCG TPM 2.0 specification plus Microsoft-specific extensions like SHACK [@ms-pluton-blog-2020]. From Windows's perspective, Pluton *is* a TPM, with a different update story (Windows Update versus OEM UEFI capsule) and a different trust anchor (Microsoft as firmware signer). Whether the OEM exposes Pluton "as the TPM" or alongside a discrete TPM is an OEM choice [@ms-learn-pluton-as-tpm]: *"Microsoft Pluton can be used as a TPM, or with a TPM. Although Pluton builds security directly into the CPU, device manufacturers might choose to use discrete TPM as the default TPM, while having Pluton available to the system as a security processor for use cases beyond the TPM"* [@ms-learn-pluton-as-tpm]. No. Pluton firmware is Microsoft-authored and Microsoft-signed [@ms-learn-pluton]. Caliptra is Microsoft-co-contributed and open source [@caliptra-github] -- but Caliptra is datacenter-class, not a Pluton substitute on Windows clients. The closest open-source on-die RoT for clients is OpenTitan [@opentitan-home] [@opentitan-commercial], which as of 2026 is discrete or in-package, not on-die in an application SoC. Tock OS [@tock-github] is the most mature publicly reviewed memory-safe embedded RTOS that *could* host Pluton-class workloads; whether it is the actual runtime on Pluton-on-PC is not on the public record. No. Pluton centralises firmware *signing*, not key access. The November 17, 2020 announcement specifies SHACK -- Secure Hardware Cryptography Key -- which states that keys *"are never exposed outside of the protected hardware, even to the Pluton firmware itself"* [@ms-pluton-blog-2020]. Microsoft signs the firmware that runs on Pluton; the keys Pluton creates and seals stay inside Pluton. (The prior article's FAQ entry on this point [@prior-tpm-in-windows] makes the same observation about the underlying TPM 2.0 non-exportability property.) Three things, in order. First, no off-package bus to sniff -- Andzakovic-class attacks [@andzakovic-2019-tpm-sniffing] have nothing to attack on Pluton silicon. Second, Patch Tuesday-cadence firmware fixes for TCG-reference-code bugs -- CVE-2025-2884 [@cve-2025-2884] is the worked example; the Pluton Windows Update path collapses the dwell time that a discrete-TPM fix would otherwise spend in OEM UEFI capsule queues. Third, Microsoft-authored Rust firmware on 2024+ AMD and Intel silicon [@ms-learn-pluton]; the bug class that memory-safe firmware structurally rules out is large. The cost of all three is a Microsoft signing key as the chip's trust anchor. Pluton inherits the TCG TPM 2.0 algorithm-agility property the prior article documented in section 8.1 [@prior-tpm-in-windows]. Caliptra 2.0 has a stated commitment to ML-DSA and ML-KEM [@caliptra-github]; Pluton-firmware post-quantum migration tracks similar primitives, but no Microsoft public commitment to a specific date for a post-quantum Pluton firmware release exists in 2026. The point of the algorithm-agility property is that the migration is a firmware change, not a silicon respin -- which is precisely the property the Pluton update path is designed to operationalise. Generally no. Disabling Pluton on AMD Ryzen 6000+ via the BIOS toggle does not return the system to a *stronger* security posture; it returns it to AMD fTPM (or no TPM at all, depending on the OEM's BIOS design). The faulTPM-class attack surface that motivated the move to Pluton in the first place re-opens [@jacob-2023-faultpm]. The procurement scenarios in section 10 list the narrow cases where dTPM is the right answer; in those cases the right action is to procure dTPM-equipped silicon, not to disable Pluton on Pluton-equipped silicon.

A closing tied to the prior article

Return to the line that opened this article. "The TPM was supposed to be the part of the system you didn't have to trust anyone for. Twenty-five years later, the trust question is back -- and the answer is now political" [@prior-tpm-in-windows]. The architectural answer to that question existed inside an Xbox before the question was asked. Twelve years of Microsoft security silicon -- Xbox One in 2013, Project Sopris in 2015, the Seven Properties paper in 2017, Project Cerberus in 2017, Azure Sphere in 2018, Pluton-on-PC in 2020, AMD Ryzen 6000 silicon in 2022, Linux 6.3 driver in 2023, Caliptra 1.0 in 2024, the CVE-2025-2884 dwell-time test in 2025 -- have shaped the on-die security processor on the modern Windows 11 client.

The article's own answer is direct. Pluton makes the political question concrete and unavoidable, but it does not resolve it. On-die closes the bus surface. Dedicated TEE closes the shared-TEE blast radius that defeated AMD fTPM. Memory-safe Rust firmware narrows the bug class that has driven the firmware-CVE economy for a decade. Windows Update collapses the patch latency from OEM-capsule quarters to Patch Tuesday weeks. Each design choice retires a 2014-2024 attack class. Each design choice places a new trust in Microsoft. The trust question is now visible at every level of the stack: silicon supply chain, firmware language, signing key, update channel, regulatory jurisdiction. It does not go away because Microsoft engineered the chip well. It goes from being a technical question to being a procurement question.

Pluton makes the political question concrete and unavoidable, but it does not resolve it.

The closing image is operational. An engineer running Get-Tpm on a Windows 11 laptop in 2026 reads a four-letter token in the manufacturer string. MSFT is what twelve years of Microsoft security silicon buys you. It is what closed the bus surface that the prior article's $40 FPGA exploited. It is what closed the shared-TEE surface that faulTPM extracted state from. It is what gives the Patch Tuesday channel something to deliver. It is also what places a single Microsoft signing key as the trust anchor for every Pluton-equipped Windows 11 client. That four-letter token is the article's subject, the prior article's epilogue, and the next decade's procurement question.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9. The boot-chain attacks that actually worked

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Six structural limits.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

console.log(live); `}

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

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

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

The TPM in Windows: One Primitive, Twenty-Five Years, and the Chip Microsoft Bet On Twice

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

The TPM (1.2 since 2007, 2.0 since 2014) is the hardware root of trust under almost every Windows security feature shipped since Vista -- BitLocker, Measured Boot, Credential Guard, Windows Hello, device attestation. Twenty-five years of engineering refined a single primitive (measure, extend, seal, quote) into something one chip could underwrite. Twenty-five years of attacks (Andzakovic 2019, TPM-Fail 2020, faulTPM 2023) have argued empirically about how passive that chip can be. The current state of the art -- Microsoft Pluton on the CPU die, Microsoft-signed Rust firmware (on 2024 AMD and Intel platforms) delivered via Windows Update -- closes the bus and the TEE attack surfaces, but centralizes firmware trust on Microsoft. Post-quantum migration is the next frontier.

1. The chip nobody asked for

On June 24, 2021, Microsoft announced Windows 11 [@ms-windows-experience-blog-2021] -- and told hundreds of millions of working PCs they were no longer eligible to upgrade. Not because they were too slow. Because they did not have a small chip most users had never thought about: a TPM 2.0. The PR backlash was immediate; the technical rationale was almost invisible. Why was Microsoft willing to take that much heat over a piece of silicon?

The next morning, Microsoft's security team tried to explain [@ms-security-blog-windows11-2021]. The argument was four words long: hardware root of trust.

All certified Windows 11 systems will come with a TPM 2.0 chip to help ensure customers benefit from security backed by a hardware root-of-trust.

That sentence sat awkwardly against the user experience: a green checkmark in the PC Health Check tool, or a red X telling you to buy a new computer. The deeper claim -- that a passive cryptoprocessor underwrote the security guarantees of half the operating system -- was not something Microsoft had ever asked consumers to think about. For OEMs, the requirement was old news. Since July 28, 2016 [@ms-learn-oem-tpm], every new Windows device model had been contractually required to "implement and enable by default TPM 2.0." The 2021 mandate did not introduce the chip. It made an existing OEM rule into a visible install gate.

A small, isolated cryptoprocessor that holds keys, performs cryptographic operations, and records integrity measurements -- usually on a separate package or block of silicon that the host operating system cannot read directly. The TPM is "passive": it executes commands sent to it but never reaches into the host's memory. The PC Health Check tool was pulled and re-released. Reddit and Hacker News spent a weekend arguing about whether Microsoft had effectively bricked older hardware to sell new licenses. Microsoft's reply -- that TPM-by-default produces measurable population-level security gains even when individual users do not understand it -- was correct, but never quite the rebuttal that a consumer audience could engage with. The politics of "Trusted Computing" had returned, twenty years after the original Stallman objection [@wikipedia-trusted-computing].

This article is about that piece of silicon: what it does, why Windows needs it more than ever, and why twenty-five years of engineering and twenty-five years of attacks have together produced a chip that quietly defines what modern Windows can defend against -- and what it cannot.

The central claim, which the rest of this piece will earn: a passive cryptoprocessor designed in 1999 became the load-bearing pillar of half of Windows security, and the history of attacks against it has been a sustained empirical argument about exactly how passive that pillar is allowed to be.

2. The problem the TPM was built to solve

Picture an engineer at IBM in early 2000. The Windows kernel has just been rooted again. The newly shipped DPAPI master keys -- introduced with Windows 2000's general availability on February 17, 2000 [@wikipedia-windows-2000] -- are recoverable in seconds once SYSTEM falls. Stolen ThinkPads come back with their fresh EFS volumes already decrypted. Where do you put a secret that the OS cannot read?

Software-only key storage was Generation 0. Windows had DPAPI, EFS, and LSA secrets [@ms-learn-cryptography-portal], all deriving their wrapping keys from the user's logon credential or from system-level material. Every derivation had the same structural problem: the unwrapping key, sooner or later, lived in the kernel's address space. An attacker who reached SYSTEM (or who carried the disk away to a separate machine) could replay it. A volume encrypted "at rest" was decryptable as soon as the disk was readable -- and a disk you can read is a disk you can read offline. Microsoft now states the constraint plainly: a TPM-resident key, by contrast, "truly can't leave the TPM" [@ms-learn-how-windows-uses-tpm]. That property cannot be retrofitted onto software-only storage.

Key idea: Software-only key storage cannot defend against an attacker who reaches SYSTEM, and cannot defend against an attacker who carries the disk away. To survive both, the secret must live in silicon that the OS itself cannot read.

In October 1999 [@wikipedia-tcg], five PC-industry incumbents took that observation and turned it into an industrial coalition: Compaq, Hewlett-Packard, IBM, Intel, and Microsoft incorporated the Trusted Computing Platform Alliance.The Wikipedia Trusted Computing Group article gives the day-precision date as October 11, 1999. The original TCPA press release URL has not survived; the founder list and date are consistent across secondary sources. TCPA's charter was narrow: define a chip that could hold keys an x86 OS could not export, record boot-time integrity measurements, and sign attestations about that boot. The first chip to ship against the resulting TPM Main Specification 1.1b [@tcg-tpm-main-spec] appeared in 2003 [@wikipedia-tpm]. Atmel, Infineon, and STMicroelectronics built it [@wikipedia-tpm].

In parallel, Microsoft Research ran its own bet. Paul England, Butler Lampson, John Manferdelli, Marcus Peinado, and Bryan Willman [@england-2003-trusted-open-platform] published "A Trusted Open Platform" in IEEE Computer, July 2003. The codename inside Microsoft was Palladium; the public name was the Next-Generation Secure Computing Base, NGSCB. It described a Windows where high-assurance code could run isolated from a possibly-compromised OS kernel, anchored in a hardware secure coprocessor that looked very much like a TPM. The motivating sentence read like a thesis: NGSCB extends personal computers "to offer mechanisms that let high-assurance software protect itself from the operating systems, device drivers, BIOS, and other software running on the same machine."

NGSCB never shipped as advertised. By 2005, reports indicated [@wikipedia-ngscb] that Microsoft would ship "only part of the architecture, BitLocker, which can optionally use the Trusted Platform Module to validate the integrity of boot and system files prior to operating system startup." The "Nexus" hypervisor, the user-mode high-assurance "agents," the protected paths for keyboard and display -- all dropped against the Vista deadline.The deadline pressure on Vista is legendary. The architecture team chose to ship the smallest piece of NGSCB the existing chip could underwrite -- BitLocker -- and shelved the rest. That shelved piece eventually returned, fifteen years later, as Virtualization-Based Security and Credential Guard.

The shelved primitives, however, did not die. Measured boot -- the firmware measures the boot loader, the boot loader measures the kernel, each measurement extended into a register that cannot be rewound -- migrated into Vista BitLocker and, later, into Windows 8 Measured Boot. Sealed storage -- a key tied to a measured boot state, unreleasable unless the boot state matches -- became the defining property of every TPM-bound BitLocker volume. Remote attestation -- a device signing a quote of its own measurements for a remote verifier -- became Device Health Attestation. NGSCB shipped, just not as itself.

In the early 2000s, Richard Stallman and the Free Software Foundation framed Trusted Computing as "treacherous computing" [@wikipedia-trusted-computing]: hardware secured "for its owner, but also against its owner." That objection has aged unevenly. The DRM concerns the FSF predicted did not dominate -- Hollywood never got the protected video paths it wanted on PCs. The trust-centralization concern has aged well: the modern Pluton debate raises a structurally similar question about who holds the signing key on the world's PC fleet, and the answer is now political rather than technical.

TCPA had built a chip that could hold a key the OS couldn't read. Which keys, under whose authority, against which threats? The first answer was almost good enough -- and it lasted about a decade.

3. Generation 1 and Generation 2: TPM 1.1b -> 1.2, and why they failed

If you opened a 2007 ThinkPad and looked at the LPC bus next to the Super-IO chip, you would see a small Infineon SLB chip [@andzakovic-2019-tpm-sniffing]. That was your TPM 1.2. It did exactly one job, and Vista's BitLocker was the first feature to depend on it.

The architectural skeleton of TPM 1.x [@wikipedia-tpm] was simple. At least sixteen Platform Configuration Registers, with the PC Client TPM Interface Specification mandating 24 per active bank. Hash algorithm: SHA-1. Asymmetric algorithm: RSA-2048. A single root of storage, the Storage Root Key, whose private half never left the chip. An Endorsement Key burned in at manufacture as the chip's permanent identity. An HMAC-SHA1 authorization model over command parameters. A "Take Ownership" ceremony where the platform owner created the SRK and bound it to an owner secret.

A TPM-internal register modified only by a one-way "extend" operation: $\text{PCR}_{\text{new}} = H(\text{PCR}_{\text{old}} \,\|\, \text{measurement})$. Static PCRs (0-15) cannot be rolled back without a full platform reset. TPM 2.0 also defines *dynamic* PCRs (16, 17-22, and 23 in the PC Client profile) that can be reset at specific localities via `TPM2_PCR_Reset`. DRTM uses PCRs 17-22 at locality 4 to re-launch a known measurement chain mid-run; PCRs 16 and 23 are resettable at lower localities for debug and application use. Either way, PCRs are the data structure that compresses a chain of measurements into a single attestable digest. The TPM's permanent identity key, generated at manufacture and accompanied by an EK certificate from the chip vendor's CA. The EK is non-migratable and is used during attestation to prove that a given key was generated inside a genuine TPM. It is also the privacy-sensitive part of TPM identity: the EK is unique to one chip, so unrestricted use of the EK in attestation reveals which physical machine you are. The root of the TPM's key hierarchy. In TPM 1.x there was exactly one SRK per chip, created during the "Take Ownership" ceremony. Every protected key in the hierarchy was a child of the SRK -- if you cleared the SRK, every key tied to it was lost. A restricted signing key the TPM uses to sign quotes of PCR values for a remote verifier. Naming changed with the spec: in TPM 1.x it was the Attestation Identity Key (AIK), a separate RSA key whose binding to a real TPM was asserted by a Privacy CA's certificate over the EK. In TPM 2.0 it is the Attestation Key (AK), a primary key in the Endorsement Hierarchy *derived from the same Endorsement Primary Seed as the EK* -- the AK is a sibling of the EK, not a copy, and it is certified by the EK rather than being an alias of it. Either way, the AIK/AK signs the quote; the EK never directly signs anything.

TPM 1.2 [@wikipedia-tpm], shipped in late 2003 and standardized as ISO/IEC 11889:2009, layered on the practical machinery: locality (a way for code at different privilege levels to extend different PCRs), monotonic counters, NV indices, transport sessions, and the eight-PCR split between firmware (PCR[0..7]) and OS (PCR[8..15]). It was the chip that mass-deployed in essentially every business PC from 2006 to 2014. When Windows Vista [@wikipedia-ngscb] reached volume-license RTM in late 2006 and broad availability in early 2007, BitLocker [@ms-learn-bitlocker] (Enterprise and Ultimate editions only) became the first mainstream Windows feature whose security depended on the chip: BitLocker sealed the Volume Master Key to PCR values describing the boot-loader chain, so that a stolen disk could not be decrypted offline. Secure Boot binding (PCR[7]) would not arrive until UEFI Secure Boot [@ms-learn-oem-secure-boot] shipped with Windows 8 in 2012.

flowchart TD EK["Endorsement Key (EK)
RSA-2048, burned at manufacture"] Owner["Owner secret
(Take Ownership)"] SRK["Storage Root Key (SRK)
RSA-2048, single per chip"] K1["Storage key
(child)"] K2["Binding key
(child)"] K3["Signing key
(child)"] AIK["Attestation Identity Key
(independent RSA key)"] PCA["Privacy CA"]

Owner --> SRK
SRK --> K1
SRK --> K2
SRK --> K3
AIK --> PCA
EK -. cert .-> PCA

The problem with all of this was not that anyone broke it. The problem was that the architecture hard-coded its cryptographic primitives into its data structures. SHA-1 was not a configurable algorithm; it was the literal width of the PCR register and of every hash field in the spec. RSA-2048 was not a configurable algorithm; it was the literal layout of the EK, the SRK, and every protected key blob. If the world deprecated SHA-1, you did not patch the firmware. You replaced the chip.

NIST SP 800-131A deprecated SHA-1 [@nist-sp-800-131a-r2] digital signatures starting in 2011. The 2017 SHAttered collision [@google-2017-shattered] drove the point home.The 2017 SHAttered SHA-1 collision does not retroactively break Vista BitLocker in practice -- to do that, an attacker would have to choose firmware blobs whose hashes collide, not merely demonstrate a collision exists. But it ended any defense of "SHA-1 in PCRs is fine because nobody can collide it." Algorithm flexibility cannot be retrofitted onto silicon whose data structures hard-code SHA-1. There were other limitations: a single SRK hierarchy meant clearing the chip's storage hierarchy also reset chip identity; the Privacy CA model for attestation never deployed at scale; ECC was missing; and the HMAC-based authorization model made every command exchange a piece of bespoke crypto plumbing.

Generation	Year	Hash	Asym	Hierarchies	Status
Software-only (LSA / PStore)	1996+ [@wikipedia-windows-nt-4]	varies	varies	n/a	NT 4.0 baseline; disk-readable wrapping keys
Software-only (DPAPI / EFS)	2000+	varies	RSA-1024 (EFS)	n/a	Defeated by offline disk theft and by SYSTEM compromise
TPM 1.1b	2003	SHA-1	RSA-2048	1 (SRK)	First mass deployment; superseded by 1.2
TPM 1.2	2003-2014	SHA-1	RSA-2048	1 (SRK)	Vista/7/8 BitLocker baseline; algorithm-rigid
TPM 2.0	2014+	SHA-1 + SHA-256 (+ SHA-3, future PQC)	RSA, ECC	4 (Platform / Endorsement / Storage / Null)	Current; ISO/IEC 11889:2015

TCG accepted the constraint in 2014 and started over. The 2.0 design did not add features to 1.2. It answered a different question: how do you let one TPM survive twenty years of cryptographic transitions?

4. Generation 3: TPM 2.0 -- one primitive, many algorithms

On April 9, 2014 [@wikipedia-tpm], the Trusted Computing Group [@tcg-tpm2-library-spec] did something rare in standards bodies: they threw away a working specification and started from a different question. The result was the TPM 2.0 Library Specification, Family 2.0, Level 00, Revision 116. A year later it became ISO/IEC 11889-1:2015 Edition 2 [@iso-iec-11889-1-2015], which removed the "industry consortium" objection from procurement teams in regulated environments. By July 28, 2016 [@ms-learn-oem-tpm], Microsoft had quietly made TPM 2.0 a contractual must-have for every new Windows OEM SKU.

Four conceptual changes carry the architecture.

4.1 Algorithm agility

Every cryptographic algorithm in TPM 2.0 carries an integer identifier. PCRs no longer have a single hash; they have banks, one per supported algorithm, all extended in parallel by a single command. Microsoft's own documentation [@ms-learn-how-windows-uses-tpm] describes the contract: when firmware extends PCR[0] with the IBV's CRTM measurement, the TPM extends both the SHA-1 bank and the SHA-256 bank, and on newer parts the SHA-384 bank as well.The PC Client Platform TPM Profile mandates SHA-1 + SHA-256 minimum, not SHA-256-only. Backwards compatibility had a cost. Future-proofing against SHA-3 and post-quantum algorithms is now a matter of registering a new ID, not replacing silicon.

A property of a cryptographic protocol or device whereby the choice of hash, signature, or encryption algorithm is decoupled from the protocol's data structures. Algorithm-agile systems carry algorithm identifiers alongside their cryptographic blobs, so a new algorithm can be added by registering an ID rather than by re-laying out the wire format. TPM 2.0 is algorithm-agile; TPM 1.x was not.

4.2 Four hierarchies, four primary seeds

Where TPM 1.x had a single SRK, TPM 2.0 has four hierarchies -- Platform, Endorsement, Storage, Null -- each rooted in a per-hierarchy primary seed. Primary keys are derived deterministically: call TPM2_CreatePrimary with the same template against the same seed, and you get the same key back, byte-for-byte. The Apress textbook by Arthur, Challener, and Goldman [@arthur-challener-goldman-2015] -- the de-facto developer reference for the spec -- describes this as the architectural fix to a real operational problem: the platform owner can clear the storage hierarchy without losing the device's endorsement identity.

flowchart TD subgraph Platform["Platform Hierarchy
(firmware-only)"] PSeed["Platform Primary Seed"] PSRK["Platform SRK"] PSeed --> PSRK end subgraph Endorsement["Endorsement Hierarchy
(privacy-sensitive)"] ESeed["Endorsement Primary Seed"] EK["EK"] AK["AK
(restricted signing)"] ESeed --> EK ESeed --> AK EK -. cert .-> AK end subgraph Storage["Storage Hierarchy
(owner-cleared)"] SSeed["Storage Primary Seed"] SRK["SRK"] Sealed["Sealed VMK
(BitLocker)"] Bound["Hello key
(per-user)"] SSeed --> SRK SRK --> Sealed SRK --> Bound end subgraph Null["Null Hierarchy
(reset on every reboot)"] NSeed["Null Primary Seed
(per-boot random)"] end

4.3 Enhanced Authorization

The most interesting change is how TPM 2.0 talks about access control. Every protected object has a policyDigest, an algorithm-agile hash of an arbitrarily complex set of conditions. To use the object, the caller starts a policy session (TPM2_StartAuthSession with SE_POLICY) and walks predicates -- TPM2_PolicyPCR, TPM2_PolicyAuthorize, TPM2_PolicySigned, TPM2_PolicyCommandCode, TPM2_PolicyAuthValue -- each extending the running session digest. At the end, the TPM checks that the session digest matches the object's policyDigest, and only then authorizes the operation. BitLocker, in its current Microsoft Learn description [@ms-learn-bitlocker], uses this to seal the Volume Master Key to PCR[7] (Secure Boot policy) and PCR[11] (BitLocker control flags). Any tampering with Secure Boot configuration -- or any non-BitLocker boot path -- causes unseal to fail.

TPM 2.0's flexible authorization mechanism. Each protected object carries a hash (policyDigest) of the predicates required to use it. A caller builds an equivalent digest by walking a sequence of TPM2_Policy* commands inside a policy session; the TPM only authorizes the operation if the two digests match. This is the mechanism that lets BitLocker bind the VMK to specific PCR values, lets Hello bind a key to a PIN gesture with anti-hammering, and lets attestation servers compose policies they did not design into the chip.

4.4 The unifying primitive: measure, extend, seal, quote

The reason any of this matters for Windows is that the entire feature surface compresses down to four operations on the same set of registers.

Measure. A piece of code computes the hash of the next piece of code (or configuration) about to run.
Extend. That hash is folded into a PCR via PCR_new = H(PCR_old || hash). The operation is one-way: PCRs cannot be rewound.
Seal. A symmetric key (or arbitrary blob) is encrypted under the TPM's Storage hierarchy with a policyDigest that names a specific set of PCR values. TPM2_Unseal releases the blob if and only if the live PCR state matches.
Quote. The TPM signs a snapshot of selected PCRs with an Attestation Key. A remote verifier can check the signature against a known AKpub and an EK certificate chain.

The boot of a measured Windows machine is exactly this loop. The Core Root of Trust for Measurement -- a small piece of immutable firmware -- measures the next stage and extends PCR[0]. Each stage measures the next: PCR[2] for option ROMs, PCR[4] for the Windows Boot Manager, PCR[7] for the Secure Boot policy, PCR[11] for BitLocker volume control flags, and on through ELAM and the kernel. Microsoft's Trusted Boot description [@ms-learn-secure-boot-process] walks the chain.

sequenceDiagram participant FW as Firmware (CRTM) participant BM as Bootmgr participant Win as Windows kernel participant TPM as TPM FW->>TPM: PCR_Extend(PCR[0], H(firmware)) FW->>BM: Hand off BM->>TPM: PCR_Extend(PCR[4], H(bootmgr)) BM->>TPM: PCR_Extend(PCR[7], H(SecureBoot policy)) BM->>Win: Hand off Win->>TPM: PCR_Extend(PCR[11], H(BitLocker control)) Win->>TPM: TPM2_Unseal(VMK, policyDigest = PCR[7],PCR[11]) TPM-->>Win: VMK if PCRs match policy, else error

Now compress the Windows feature catalogue against those four operations.

BitLocker [@ms-learn-bitlocker] seals the VMK to a PCR policy.
Measured Boot and Device Health Attestation [@ms-learn-azure-measured-boot] quote PCRs to a remote verifier.
Credential Guard [@ms-learn-credential-guard] seals the VBS-isolated NTLM/Kerberos secrets with a policy that includes the VBS measurement.
Windows Hello for Business [@ms-learn-hello-for-business] creates a per-user RSA-2048 or P-256 key whose authorization policy requires the PIN gesture and is bounded by the TPM's anti-hammering counter.
Virtual smart cards, DPAPI-NG, and TPM key attestation [@ms-learn-tpm-key-attestation] for ADCS-issued certificates all sit on the same primitives.

Note: BitLocker, Measured Boot, Credential Guard, Windows Hello, virtual smart cards, DPAPI-NG, and TPM key attestation are not seven independent uses of a chip. They are seven policy expressions over the same four operations -- measure, extend, seal, quote -- on the same PCR set. The TPM is not a checkbox shared by features. It is one primitive that defines what hardware-rooted security can do in Windows.

Key idea: One primitive -- measure, extend, seal, quote -- underwrites every Windows hardware-rooted security feature shipped since Vista. The TPM's value to Windows is not a list of cryptographic operations. It is a single, composable contract: "this key only releases when the boot looks like this."

By July 28, 2016, TPM 2.0 was a hidden contractual requirement under the entire Windows OEM channel. By June 24, 2021, Microsoft made the same chip the visible install gate for Windows 11. The architecture had won the building. Then attackers started taking it apart.

5. The threat model collapses inward (2019-2024)

On March 13, 2019, a New Zealand security researcher named Denis Andzakovic posted a blog entry [@andzakovic-2019-tpm-sniffing] that, in retrospect, started the modern era of TPM offense. He demonstrated two LPC-bus sniffing attacks on two different machines. On an HP business laptop running TPM 1.2, he used a DSLogic Plus logic analyzer connected via the laptop's debug header (7 wires: LCLK, LFRAME, LAD[0:3], and ground) to lift the BitLocker Volume Master Key off the LPC bus. On a Surface Pro 3 running TPM 2.0, he spent $40 NZD on a Lattice iCE40 ICEStick FPGA (8 connections: GND, LCLK, LFRAME#, LRESET#, LAD[0:3]) and replicated the attack. With the disk in hand and the motherboard accessible, a thief could decrypt a TPM-only BitLocker volume in the time it took to boot it once. Andzakovic open-sourced the FPGA gateware [@andzakovic-lpc-sniffer-code] the same day.Andzakovic credits Hector Martin (@marcan) for prototyping LPC sniffing earlier; the 2019 write-up was the first end-to-end public demonstration with reproducible code.

The structural insight, which has not been backed away from, is that Windows does not enable TPM 2.0 parameter encryption on the BitLocker boot path. The VMK travels in plaintext at the LPC bus's 33 MHz clock across a few millimetres of PCB.Why doesn't Windows turn on parameter encryption for BitLocker? The boot-time pressure is real -- pre-OS code lives in a tight memory budget and parameter encryption requires HMAC-signed sessions. The pragmatic mitigation Microsoft documents is preboot authentication (PIN or startup key), which makes the bus-sniffed VMK insufficient on its own.

The attack would not stay a one-laptop curio. In late 2020, WithSecure's Henri Nurmi released an SPI variant [@withsecure-2020-spi-sniffing] and a public BitLocker-key extraction tool. A year later, Thomas Dewaele and Julien Oberson at SCRT reproduced the LPC attack [@scrt-2021-tpm-sniffing] on a Lenovo ThinkPad L440 with a chip (labeled P24JPVSP, identified by SCRT as probably equivalent to the ST33TPM12LPC) and published a tutorial. By October 2024, SCRT had industrialized the attack [@scrt-2024-bitlocker-pin] across "the three major enterprise-grade laptop manufacturers (i.e. Lenovo, HP, and Dell)" in "a few minutes."

The first reassurance the industry reached for was: ship the TPM inside the chipset. No bus, no sniff. Both Intel (Platform Trust Technology, fTPM-in-CSME [@wikipedia-intel-me]) and AMD (fTPM-in-PSP) had already done this for cost reasons. The second reassurance lasted eight months.

In November 2019, Daniel Moghimi, Berk Sunar, Thomas Eisenbarth, and Nadia Heninger -- soon to be USENIX Security 2020 -- released TPM-Fail [@tpmfail-microsite]. Their finding: Intel PTT and a STMicro ST33 dTPM both leaked ECDSA private keys through ordinary timing side channels in their scalar multiplication. The numbers were brutal:

A local adversary can recover the ECDSA key from Intel fTPM in 4-20 minutes depending on the access level. We even show that these attacks can be performed remotely on fast networks, by recovering the authentication key of a virtual private network (VPN) server in 5 hours. -- TPM-Fail, tpm.fail [@tpmfail-microsite], 2019

NVD assigned CVE-2019-11090 [@cve-2019-11090] to Intel PTT and CVE-2019-16863 [@cve-2019-16863] to STMicroelectronics' ST33TPHF2ESPI. The latter entry is blunt: "STMicroelectronics ST33TPHF2ESPI TPM devices before 2019-09-12 allow attackers to extract the ECDSA private key via a side-channel timing attack because ECDSA scalar multiplication is mishandled, aka TPM-FAIL." Both chips were certified at the moment of disclosure -- the STMicro chip held both Common Criteria EAL4+ and FIPS 140-2 Level 2, while the Intel chip held FIPS 140-2 [@tpmfail-microsite]. Certification did not catch the bug. The presentation is preserved in the USENIX Security 2020 proceedings [@moghimi-2020-usenix-tpmfail].

Note: Removing the bus did not remove the attack surface. It relocated it from the PCB to the trusted execution environment that hosted the firmware TPM. The fTPM closes one channel and opens another -- and the certification regime that was supposed to catch both missed the timing leak in chips that had passed their respective certification programmes (STMicro: Common Criteria EAL4+ and FIPS 140-2 Level 2; Intel: FIPS 140-2). The "fTPM has no bus to sniff" reassurance was a category error.

The final beat came four years later. In April 2023, Hans Niklas Jacob, Christian Werling, Robert Buhren, and Jean-Pierre Seifert posted faulTPM (arXiv:2304.14717) [@jacob-2023-faultpm], with reproducible code at github.com/PSPReverse/ftpm_attack [@pspreverse-ftpm-attack]. The attack: voltage-glitch the AMD Platform Security Processor and walk out with the entire internal TPM state. The paper's own claim is the sentence that, more than any other, framed the modern TPM threat model.

this vulnerability exposes the complete internal TPM state of the fTPM. It allows us to extract any cryptographic material stored or sealed by the fTPM regardless of authentication mechanisms such as Platform Configuration Register validation or passphrases with anti-hammering protection. -- Jacob, Werling, Buhren, Seifert, faulTPM (2023) [@jacob-2023-faultpm]

Two to three hours of physical access. Anti-hammering bypassed because anti-hammering is enforced by the TPM, and once the TPM's internal state is on your bench you set the counter to zero. PCR-policy bypassed because the sealed blob's wrapping key is in the extracted state. The structural punch is that this makes BitLocker TPM+PIN on AMD fTPM with a low-entropy PIN less secure than a TPM-less passphrase (a corollary the faulTPM paper makes explicit [@jacob-2023-faultpm]): the TPM concentrates all your trust into a chip whose internal state can be exfiltrated.

timeline title Three generations of TPM attack section Bus sniffing 2019 March : Andzakovic - \$40 FPGA, BitLocker VMK off LPC bus 2020 December : WithSecure - SPI variant and key-extraction tool 2021 November : SCRT reproduces on Lenovo ThinkPad L440 2024 October : SCRT - few-minute attack on Lenovo, HP, Dell section Side channel in fTPM 2019 November : TPM-Fail (Moghimi, Sunar, Eisenbarth, Heninger) 2019 November : CVE-2019-11090 (Intel PTT), CVE-2019-16863 (STMicro) section Fault injection in fTPM 2023 April : faulTPM - full AMD fTPM state extracted in 2-3 h

Attack class	TPM form	Cost	Time	Source
LPC bus sniffing (BitLocker VMK)	Discrete TPM 1.2 / 2.0	$0 (logic analyzer) -- ~$40 NZD (iCE40 FPGA, Surface Pro 3)	Minutes once wired	Andzakovic 2019; SCRT 2021/2024
SPI bus sniffing	Discrete TPM 2.0	~$50 (logic analyzer)	Minutes once wired	WithSecure 2020-2024
Timing side channel on ECDSA	Intel PTT, STMicro ST33	Software-only	4-20 min local; 5 h remote VPN	TPM-Fail 2019/2020
Voltage glitch on PSP	AMD fTPM	~$200 (glitching rig)	2-3 h physical	faulTPM 2023

If a $40 FPGA defeats discrete TPM, a network packet defeats Intel PTT, and a few hours of physical access defeats AMD fTPM completely -- where does the next generation of TPM live? Microsoft's answer was on the CPU die itself.

6. State of the art: five realizations of one specification

All five chips in this section pass the same TCG conformance suite. They expose the same TPM2_* command surface to Windows. They fail to completely different attackers. The architecture is identical; the attack surface is everything.

A *discrete* TPM is a separate chip on the motherboard, talking to the host over LPC, SPI, or I2C. A *firmware* TPM is a TPM 2.0 implementation running inside an existing trusted execution environment on the host -- Intel CSME (Platform Trust Technology), AMD PSP (fTPM), or a dedicated Microsoft IP block (Pluton). Both pass the same TCG specification; they differ in physical location, attack surface, and update channel. A zero-knowledge protocol that lets a TPM prove "I am a real TPM certified by vendor X" without revealing which chip is talking. Replaces the TPM 1.2 Privacy CA model, which required a third-party CA to mediate every attestation. ECDAA is the elliptic-curve variant standardized in TPM 2.0.

6.1 Discrete TPM

The classical chip. Infineon, STMicroelectronics, Nuvoton. Hangs off the motherboard's LPC, SPI, or I2C bus. Best certifications (Common Criteria EAL4+, FIPS 140-2/3). One bug class: bus sniffing in minutes for $40 against the BitLocker boot path that Windows leaves in plaintext.

6.2 Intel PTT

TPM 2.0 inside the Converged Security and Management Engine -- historically on the Platform Controller Hub die, and increasingly on the SoC die in integrated-platform Intel processors since Tiger Lake. Either way, no physical bus to sniff. Defeated by TPM-Fail [@tpmfail-microsite] timing side channel; firmware-patched, but inherits CSME's broader attack surface and CSME's update story (UEFI capsule via OEM, lifecycle entirely under the OEM's control).

6.3 AMD fTPM (PSP)

TPM 2.0 inside the AMD Platform Security Processor [@wikipedia-amd-psp] (an ARM TrustZone Cortex-A5 core integrated into every modern Ryzen SoC). Ships in essentially all Ryzen-class client SoCs since 2017. No physical bus to sniff. Defeated end-to-end by the faulTPM [@jacob-2023-faultpm] voltage-glitch attack against the PSP. The structural problem is shared TEE: the same coprocessor is responsible for memory encryption setup, secure-boot enforcement, and TPM service, and a single fault-injection path drops all of those.

6.4 Microsoft Pluton

A Microsoft IP block on the CPU SoC die, with Microsoft-authored Rust firmware (on 2024 AMD and Intel platforms) [@ms-learn-pluton] delivered through Windows Update. According to Microsoft's hardware list, Pluton "is currently available on devices with the following chipsets running on Windows 11: AMD: Ryzen 6000, 7000, 8000, 9000 and Ryzen AI Series ... Intel: Core Series Processors -- Ultra 200V Series, Ultra Series 3 and Series 3 ... Qualcomm: Snapdragon 8cx Gen 3 and Snapdragon X Series." The same page notes that "Pluton platforms in 2024 AMD and Intel systems will start to use a Rust-based firmware foundation given the importance of memory safety."

The thesis is laid out in Microsoft's November 17, 2020 announcement post [@ms-pluton-blog-2020], which links explicitly to Andzakovic. The architectural framing is unusually direct.

The Pluton design removes the potential for that communication channel to be attacked by building security directly into the CPU. -- Microsoft Security Blog, November 17, 2020 [@ms-pluton-blog-2020]

Three things change at once. The bus is gone -- Pluton is on-die, so dTPM bus-sniffing has no surface to attack. The TEE host is dedicated -- Pluton is not the same coprocessor that runs SEV memory encryption or ME runtime services. And the firmware ships through Windows Update -- so when a Pluton firmware vulnerability is found (and one will be found), the patch reaches the deployed fleet through Windows Update rather than through OEM UEFI capsule rollouts.The Pluton-as-TPM page makes the trade-off explicit: "Microsoft Pluton can be used as a TPM, or with a TPM. Although Pluton builds security directly into the CPU, device manufacturers might choose to use discrete TPM as the default TPM." [@ms-learn-pluton-as-tpm] Several enterprise security teams have publicly cited the Pluton update model as a reason to keep dTPM as their default for high-assurance fleets even where Pluton silicon is available.

6.5 vTPM

A software TPM emulation, typically inside a hypervisor. Azure Trusted Launch [@ms-learn-azure-trusted-launch] is Microsoft's flagship implementation: "Trusted Launch is the default state for newly created Azure Gen2 VM and scale sets." The vTPM lives in a host-protected memory region and inherits the trust of the host. For cloud workloads where the threat model already includes "the hypervisor host is honest," this is the right shape; for adversarial physical access, it is not.

6.6 Head-to-head

Dimension	dTPM	Intel PTT	AMD fTPM	Pluton	vTPM
Physical location	Separate chip	CSME (PCH die)	PSP (CPU die)	Dedicated IP block on CPU die	Hypervisor memory
Bus to host	LPC / SPI / I2C	None (on-die)	None (on-die)	None (on-die)	None (virtual)
TEE shared with	none (own die)	CSME	PSP (large)	none (Pluton-only)	host kernel
Side-channel exposure	Implementation-dependent	TPM-Fail patched	faulTPM unaddressed structurally	Limited public research	host-dependent
Update channel	UEFI capsule	UEFI capsule (CSME)	UEFI capsule (PSP)	Windows Update	hypervisor patch
Certifications	EAL4+, FIPS 140-2/3	EAL4+	varies	varies	n/a
OEM cost	per-chip BOM	bundled	bundled	bundled	n/a
Best-known attack	LPC/SPI sniffing in minutes	TPM-Fail timing	faulTPM full state	None public at faulTPM depth	host compromise
Algorithm agility	spec-required	spec-required	spec-required	spec-required + Rust firmware updates	spec-required
Best fit	Compliance-driven, high-assurance fleets	Existing Intel platforms	Existing AMD platforms	Default for Windows 11 client	Cloud workloads

flowchart LR subgraph TPMs["Five realizations"] dTPM["Discrete TPM
(LPC/SPI/I2C)"] PTT["Intel PTT
(CSME)"] AMD["AMD fTPM
(PSP)"] Pluton["Microsoft Pluton
(on-die, Rust, WU)"] vTPM["vTPM
(Hyper-V / Azure)"] end subgraph Surface["TCG2 command surface"] TCG["TPM2_* commands"] end dTPM --> TCG PTT --> TCG AMD --> TCG Pluton --> TCG vTPM --> TCG TCG --> BL["BitLocker VMK seal"] TCG --> MB["Measured Boot / DHA"] TCG --> CG["Credential Guard"] TCG --> WH["Windows Hello"] TCG --> VSC["Virtual smart cards"] TCG --> DPAPI["DPAPI-NG"] TCG --> KA["TPM key attestation (ADCS)"]

The deep claim of the Pluton design is not that it is a better cryptoprocessor. It is that the previous decade's lesson -- TEE memory-safety bugs are systemic, certification did not catch them, and OEM UEFI capsule patching is too slow -- argues for moving the firmware signer to Microsoft and the firmware language to Rust. That is a political choice, not just a technical one. The October 2019 Secured-core PCs initiative [@ms-secured-core-blog-2019] was the first public step; Pluton is its descendant.

If you can sniff a dTPM, time-attack an Intel PTT, glitch an AMD fTPM, and trust Microsoft to sign your Pluton firmware -- which threat are you actually defending against?

7. Theoretical limits: what a passive cryptoprocessor cannot do

A famous joke in the trusted-computing community: the TPM cannot make a compromised OS uncompromised. It can only make sure that nothing else helped.

Three impossibility-style results follow from the architecture itself, regardless of which of the five realizations you pick.

7.1 The TPM is a Root of Trust for Storage and Reporting, not Execution

The Core Root of Trust for Measurement -- the immutable code that bootstraps the measurement chain -- lives in firmware, not in the TPM. The TPM cannot detect that the wrong code measured itself; it can only refuse to release sealed material when the PCRs do not match the stored policy. If the CRTM is compromised (or a downstream measurement is forged before extension), the TPM has no way to know.

Stronger guarantees require an active root of trust: a Dynamic Root of Trust for Measurement, where the CPU enters a known good state late in the boot and re-measures from there. Intel TXT, AMD SVM-SKINIT, and Microsoft's System Guard Secure Launch [@ms-learn-system-guard] on Secured-core PCs all implement this. The TPM is a participant in DRTM; on its own, it is not sufficient.

7.2 TPM-only BitLocker has a structural lower bound

The VMK must enter RAM during Trusted Boot before the user authenticates. This is not a bug; it is the threat-model definition of "TPM-only." Therefore any attacker who intercepts the VMK at the moment of release defeats TPM-only BitLocker, regardless of TPM strength. This is what every dTPM bus-sniffing attack actually exploits -- not a weakness of the TPM, but the structural condition that the key must traverse the boot path.

Microsoft's countermeasures documentation [@ms-learn-bitlocker-countermeasures] names the mitigation in plain terms: preboot authentication. Adding TPM+PIN raises the bound to "guess the PIN against intact anti-hammering" -- but only as long as the TPM's anti-hammering counter cannot be exfiltrated. faulTPM violates that condition for AMD fTPM. On a Pluton or hardened dTPM, anti-hammering still holds, and a sufficiently random PIN closes the bound.

The complexity of guessing an $n$-digit PIN against intact anti-hammering [@ms-learn-bitlocker-countermeasures] with a per-failure delay $\Delta t$ is approximately $\frac{1}{2} \cdot 10^n \cdot \Delta t$ in the average case. For $n = 8$ and $\Delta t \geq 1\text{s}$ this is roughly $5 \times 10^7$ seconds, or about 1.6 years. For $n = 4$, it is hours.

CVE-2023-21563 [@cve-2023-21563] -- the BitLocker Security Feature Bypass that the offensive-security community calls "Bitpixie" -- is a useful reminder that breaking BitLocker does not require breaking the TPM. The NVD entry reads simply "BitLocker Security Feature Bypass Vulnerability," and the bypass operates against the boot path that consumes the unsealed VMK, not against the chip that sealed it. (NVD does not use the "Bitpixie" name; it is community-known-as.)

7.3 Once a key is unsealed, it lives in the OS's address space

A runtime-compromised OS reads any key the TPM has unsealed for it. The TPM defends against the offline attacker (disk theft, post-shutdown tamper) and the pre-OS attacker (boot-time integrity violation that fails the unseal). It does not defend against a privileged runtime attacker. This is a general impossibility, not a TPM weakness; no passive cryptoprocessor can decide whether the OS asking to unseal a key is itself trustworthy at the moment it asks.

This is why VBS, Credential Guard, and DRTM exist as separate disciplines: they answer "what protects the unsealed key once it is in RAM?" by isolating the key inside a VTL1 enclave or by re-measuring the OS after launch. The TPM is a participant; it is not the answer.

Key idea: The TPM defends against the offline attacker and the pre-OS attacker. It does not defend against a runtime-compromised OS. This is by design, and is the most a passive cryptoprocessor can do. Stronger guarantees require an active component (DRTM, VBS, hypervisor isolation) -- and none of those are the TPM.

What would an ideal TPM look like? On-die (no bus), in an isolated TEE shared with nothing else, with the host-firmware-update path replaced by an OS-channel update path, with high-assurance certification depth, with an authenticated wire protocol always on, and with native support for post-quantum primitives. No shipping TPM today satisfies all six properties. Pluton plus future PQC firmware updates is the closest existing trajectory; it is on-die, isolated, OS-channel-updated, and Rust-implemented, but it does not yet expose PQC primitives and its certification depth is still evolving.

If the TPM cannot defeat a runtime-compromised OS by design, and the best fTPM can be extracted in three hours, where is the security frontier actually moving?

8. Open problems: PQC, supply chain, and trust centralization

On August 13, 2024, NIST finalized FIPS 203 (ML-KEM) [@nist-fips-203-mlkem], FIPS 204 (ML-DSA) [@nist-fips-204-mldsa], and FIPS 205 (SLH-DSA) [@nist-fips-205-slhdsa] -- the first federal post-quantum cryptography standards. ML-DSA-87's public keys are 2,592 bytes. A typical TPM has 6 to 32 KiB of NV memory total. The math gets uncomfortable quickly.

8.1 Post-quantum migration

The NIST Post-Quantum Cryptography project page [@nist-pqc-project] describes the timeline: "In August 2024, NIST released its principal PQC standards ... Under the transition timeline in NIST IR 8547, NIST will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier." That is the deadline driving every TPM roadmap, and the August 14, 2024 Federal Register notice [@federal-register-2024-fips-pqc] made it formal U.S. policy.

Three concrete obstacles. First, the TCG algorithm registry has not yet normatively added ML-KEM, ML-DSA, or SLH-DSA; a TCG PQC working group exists, but its output is in flight. The Microsoft TPM 2.0 reference code [@ms-tpm-20-ref-releases] tracks TCG: the V1.83 release notes describe it as "the first revision in sync with Trusted Computing Group 1.83," and that revision still does not expose PQC algorithm IDs. The Fraunhofer SIT Post-Quantum Cryptography for TPM [@fraunhofer-pqc-tpm] programme has prototyped PQC primitives inside reference TPM stacks, but those changes are research artefacts, not normative TCG output.

Second, the constrained NV-memory budget on a typical TPM cannot hold many simultaneous PQC keys at the larger parameter sets. Quick arithmetic against ML-DSA-87 (FIPS 204): 2,592-byte public key plus 4,896-byte private key plus protocol overhead pushes a single persistent key blob past 7.5 KiB. A 16-KiB-NV TPM can hold at most two persistent ML-DSA-87 slots before exhausting NV. The larger SLH-DSA-256s signatures (29,792 bytes per FIPS 205 Table 2) [@nist-fips-205-slhdsa] routinely exceed the typical 1-4 KiB response-buffer cap (TPM_PT_MAX_RESPONSE_SIZE in the PC Client Platform TPM Profile [@tcg-pc-client-ptp-spec]); the related TPM_PT_NV_BUFFER_MAX (the maximum NV read/write chunk) is in the same order of magnitude and complicates persistent-storage cases as well. The chip cannot return such a signature in a single command without fragmentation extensions. PQC support on commodity TPMs is not just a software upgrade; it is an NV-budget renegotiation.

Third, hybrid signing schemes (composite RSA + ML-DSA, or ECDSA + ML-DSA) are well-defined for transitional certificates. The IETF LAMPS WG draft on composite ML-DSA signatures [@ietf-lamps-pq-composite-sigs] specifies "combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448" for X.509 PKIX. The TLS hybrid key-exchange draft [@ietf-tls-hybrid-design] does the same for TLS 1.3 handshakes. Neither defines a hybrid TPM2_Sign profile, and no shipping Windows TPM exposes one.

Microsoft's Quantum Safe Security blog (August 2025) [@ms-quantum-safe-2025] describes the broader effort -- "Our PQC effort began in 2014 when we published research on post-quantum algorithms ... We participated in four submissions to the original 2017 NIST PQC call and one submission to the current call" -- but is silent on Pluton-firmware PQC support specifically.

The architectural punchline: Pluton's Windows-Update firmware delivery channel is the only realization that can plausibly add a PQC primitive across the deployed fleet without a hardware refresh. Every other realization will need new silicon to ship native PQC.

8.2 The supply-chain trust of EK certificates

The Microsoft TPM key attestation documentation [@ms-learn-tpm-key-attestation] describes the trust-chain assumption plainly: the requestor proves "to a CA that the RSA key in the certificate request is protected by either 'a' or 'the' TPM that the CA trusts." That trust is anchored on the EK certificate the chip's vendor issued at manufacture. A vendor-CA compromise therefore equals collapse of TPM-bound device identity for an entire OEM cohort.

The 2017 ROCA incident is the canonical event for why this matters. In February 2017, Matúš Nemec, Marek Sýs, Petr Švenda, Dušan Klinec, and Vashek Matyáš at Masaryk University [@crocs-muni-roca] disclosed to Infineon a flaw in its RSA key-generation library that drastically reduced the entropy of generated keys and made factoring tractable. The NVD entry for CVE-2017-15361 [@cve-2017-15361] is precise about scope: "The Infineon RSA library 1.02.013 in Infineon Trusted Platform Module (TPM) firmware ... mishandles RSA key generation, which makes it easier for attackers to defeat various cryptographic protection mechanisms via targeted attacks, aka ROCA. Examples of affected technologies include BitLocker with TPM 1.2, YubiKey 4 (before 4.3.5) PGP key generation, and the Cached User Data encryption feature in Chrome OS." The Wikipedia summary [@wikipedia-roca] reports the team's own estimate that the bug "affected around one-quarter of all current TPM devices globally."

The Estonian e-ID program -- about 750,000 cards issued since 2014 [@arstechnica-2017-roca-estonia], all using the affected Infineon chip -- had to be re-enrolled. Microsoft published advisory ADV170012 [@msrc-adv170012] on the same coordinated disclosure date. There is still no scalable revocation mechanism for individual EK certificates: vendor-level revocation breaks every device whose EKpub was issued by that vendor's CA, and ADCS-template OEM-pinning limits scope but does not solve in-scope CA compromise. Pluton centralizes one part of trust (Microsoft as firmware signer); EK certificate issuance for the silicon is unchanged, and supply-chain integrity remains a per-vendor question.

8.3 Attestation freshness in zero-trust networks

A TPM Quote proves "this device booted clean," not "this device is currently clean." Microsoft Intune's default device-compliance check-in is on the order of hours; Microsoft Entra's Continuous Access Evaluation documentation [@ms-learn-cae] specifies the upper-bound numerics: "By default, access tokens are valid for one hour ... The goal for critical event evaluation is for response to be near real time, but latency of up to 15 minutes might be observed because of event propagation time."

A 15-minute revocation window for critical events is good. But it propagates signed policy decisions, not fresh TPM measurements. A device that was clean at boot, was compromised five minutes ago, and just made a request now will pass CAE if its existing access token is valid. Closing that window requires either much shorter token lifetimes, runtime attestation (TCG DICE, Project Cerberus), or a hypervisor-mediated re-measurement -- and none of them are the TPM.

DPAPI-NG, the CNG-layer successor to classic DPAPI that Windows uses to encrypt secrets to a set of authorization principals, is a useful test case. The DPAPI-NG documentation [@ms-learn-cng-dpapi] describes the API as "secure[ly] shar[ing] secrets (keys, passwords, key material) and messages by protecting them to a set of principals." The protection-descriptor grammar [@ms-learn-protection-descriptors] permits five descriptor keywords -- SID, SDDL, LOCAL, WEBCREDENTIALS, CERTIFICATE -- across three logical authorization classes (AD-forest groups, web credentials, certificate-store entries). Notably absent: any literal TPM=true clause. DPAPI-NG can be backed by a TPM-bound CNG key, but the authorization is expressed in principal terms, not in TPM terms. The TPM is a key-residence property, not a policy primitive at this layer -- the right architectural choice, but it means TPM-bound DPAPI-NG inherits the freshness limits of whatever principal authorization decides who is currently authorized.

8.4 The Pluton political question

Centralizing firmware on a single Microsoft signing key is a deliberate trade-off, not an oversight. The benefit is the patch path: a Pluton firmware vulnerability becomes a Windows Update release rather than a multi-quarter OEM capsule rollout. The cost is that the chip's trust anchor is now a Microsoft signing key, in a way that even the most conservative dTPM is not. The market response in 2022 was openly mixed.

In March 2022, The Register obtained vendor statements [@register-2022-pluton] from Dell, Lenovo, and HP. Dell's reply was unusually direct: "Pluton does not align with Dell's approach to hardware security and our most secure commercial PC requirements." Lenovo deployed the chip but disabled it: "[ThinkPads] will not support Microsoft Pluton at launch ... But ThinkPads introduced in January with AMD Ryzen 6000 processors will include Pluton as it's present in those AMD chips, though the feature will be disabled by default. AMD has provided an option for users to turn the feature on and off." PCWorld followed up [@pcworld-2022-pluton] with Lenovo's articulated reasoning: "Pluton is disabled by default on 2022 Lenovo ThinkPad laptops using AMD Ryzen PRO 6000 Series processors because that's what Lenovo customers have asked for, the choice to enable or not."

Matthew Garrett -- who later contributed the upstream Linux kernel support for the Pluton TPM CRB interface in Linux 6.3 (merged February 2023, released April 2023) [@phoronix-2023-pluton-linux63] -- published the closest thing to a public engineering analysis of Pluton's controllability. His April 2022 reverse-engineering write-up [@garrett-2022-pluton-rev] of the ASUS ROG Zephyrus G14 BIOS documents two firmware-level disable mechanisms on AMD Ryzen 6000 platforms: an x86-firmware "do not communicate" toggle, and a PSP directory entry 0xB BIT36 soft-fuse that "will NOT put HSP hardware in disable state, to disable HSP hardware, you need setup PSP directory entry 0xB, BIT36 to 1." Garrett's caveat is honest: "My interpretation of this is that it doesn't directly influence Pluton, but disables all mechanisms that would allow the OS to communicate with it." It is not a multi-signer proposal. There is no public peer-reviewed proposal for multi-signer or open-source Pluton firmware.

The unresolved engineering question: whether a multi-signer model is feasible without losing the timely-update property that motivated Pluton in the first place. The answer is genuinely unknown. The political question -- whether one signing key on the world's PC fleet is the right cost for the Windows-Update patch latency it enables -- is no longer a technical argument. It is a procurement-policy and procurement-jurisdiction argument, and high-assurance fleets are deciding both ways.

The TPM was supposed to be the part of the system you didn't have to trust anyone for. Twenty-five years later, the trust question is back -- and the answer is now political.

9. A Windows practitioner's TPM reference

What does this mean for the engineer running Get-Tpm on Monday morning? Three concrete things: discovery, choosing a form factor, and avoiding the pitfalls.

9.1 Discovery

Three commands establish ground truth on any Windows 11 device. Get-Tpm returns presence, ownership, and command-availability state. Get-TpmEndorsementKeyInfo returns the EK public and certificate. tpm.msc opens the Microsoft Management Console snap-in. The TCG event log lives at C:\Windows\Logs\MeasuredBoot\*.log and contains the per-PCR measurement history for every boot. Microsoft's BitLocker page [@ms-learn-bitlocker] documents the protector model that pairs with the TPM state.

{` // Demonstrates the logic of: // Get-Tpm // (Get-BitLockerVolume -MountPoint 'C:').KeyProtector // // Mirrors the PowerShell decision tree without requiring a real TPM.

const tpm = { TpmPresent: true, TpmReady: true, ManufacturerVersion: '7.2.0.1', PhysicalPresenceVersionInfo: '1.3', };

// Sample KeyProtector list as PowerShell would return it. const protectors = [ { KeyProtectorType: 'Tpm' }, { KeyProtectorType: 'RecoveryPassword' }, // Uncomment to model TPM+PIN: // { KeyProtectorType: 'TpmPin' }, ];

function classify(tpm, protectors) { if (!tpm.TpmPresent) return 'no-tpm'; if (!tpm.TpmReady) return 'tpm-not-ready';

const types = protectors.map(p => p.KeyProtectorType); const hasPin = types.includes('TpmPin') || types.includes('TpmPinStartupKey'); const hasStartupKey = types.includes('TpmStartupKey'); const hasRecovery = types.includes('RecoveryPassword');

if (hasPin) return 'tpm-plus-pin'; if (hasStartupKey) return 'tpm-plus-startup-key'; if (types.includes('Tpm')) return 'tpm-only'; return 'no-tpm-protector'; }

const verdict = classify(tpm, protectors); console.log('TPM present:', tpm.TpmPresent); console.log('TPM ready :', tpm.TpmReady); console.log('Configuration:', verdict); if (verdict === 'tpm-only') { console.log('WARN: TPM-only is vulnerable to bus-sniffing on dTPM.'); console.log('Mitigation: enable TPM+PIN with PIN length >= 8.'); } console.log('Recovery key escrowed:', protectors.some(p => p.KeyProtectorType === 'RecoveryPassword')); `}

9.2 Choosing a TPM form when the OEM gives you a choice

A short decision tree, distilled from the SOTA analysis above:

Opportunistic theft, low-skill attacker. Default TPM-only is acceptable but not ideal. TPM+PIN with at least 8 random digits closes the bus-sniffing window on dTPM and the low-PIN-entropy window on AMD fTPM.
Determined targeted adversary. TPM+PIN is necessary but not sufficient. Add FIDO2 or smart-card preboot authentication where supported, and prefer Pluton or hardened dTPM over commodity AMD fTPM for the device class.
Compliance-driven. Discrete TPM with EAL4+ / FIPS 140-2 certification is still the easiest procurement story. Verify the OEM has not enabled Pluton-as-TPM if the auditor's checklist requires a discrete chip.
Cloud workload. Azure Trusted Launch with vTPM [@ms-learn-azure-trusted-launch] is the default for Gen2 VMs and underwrites Confidential VM offerings.
Surface Copilot+, AMD Ryzen 6000+, Intel Core Ultra 200V, Snapdragon X. Pluton-as-TPM [@ms-learn-pluton] is the OEM default in many SKUs; verify the Pluton firmware is current via Windows Update.

9.3 Five common pitfalls

Note: Clearing the TPM invalidates BitLocker recovery on every TPM-bound protector. Always verify recovery key escrow first -- in Microsoft Entra ID for Azure-AD-joined devices, in Active Directory for AD-joined devices, or in a printed/saved location for personal devices. If the recovery key is unescrowed and the TPM is cleared, the volume is unrecoverable.

The other four pitfalls in brief: firmware updates change PCR[0] and PCR[7], so suspend BitLocker before applying them; dual-boot Linux extends PCRs differently than Windows, so PCR-only sealing breaks under it -- escape with TPM+PIN; Windows does not enable parameter encryption on the BitLocker boot path, so the actual mitigation against dTPM bus sniffing is preboot authentication, not "TPM hardening"; and Windows Hello silently falls back to no-TPM credential storage if the TPM is unhealthy, so periodically check Get-Tpm on enrolled devices."Anti-hammering" is the persistent rate-limit counter the TPM enforces against authValue and policy-PIN failures. It survives reboots and only resets after a long lockout period.

Note: The Group Policy setting "Require additional authentication at startup" with a minimum PIN length of 8 buys you the most security against published attacks for the least operational cost. It defeats Andzakovic-style bus sniffing (the VMK is no longer the only secret on the bus) and forces an attacker on AMD fTPM to either compromise the TPM state out-of-band or guess the PIN against anti-hammering. The exception is a fully-extracted AMD fTPM where faulTPM has already obtained the unsealed material -- in that case the PIN is bypassed.

From an elevated PowerShell prompt:

Suspend-BitLocker -MountPoint "C:" -RebootCount 1

The RebootCount 1 argument auto-resumes after the next reboot, which is what you want when the firmware update reboots the device. After the update completes, run Get-BitLockerVolume -MountPoint C: and confirm ProtectionStatus is On again. If you forget, the next boot will land on the BitLocker recovery prompt because PCR[0] no longer matches the sealed policy.

The TPM does exactly what it was designed to do, no more. Which is exactly enough -- if you understand what "exactly" means.

10. FAQ and closing

A handful of questions get asked again and again about the TPM. The answers do not always match the marketing.

No. TPM keys are non-exportable and held inside the chip; the Microsoft documentation [@ms-learn-how-windows-uses-tpm] is explicit that "if a key stored in a TPM has properties that disallow exporting the key, that key truly can't leave the TPM." The Endorsement Key is a privacy concern (it uniquely identifies the chip) but it is not a Microsoft backdoor. Pluton centralizes firmware *signing*, not key access -- Microsoft signs the firmware that runs on Pluton, but the keys Pluton creates and seals stay inside Pluton. Depends on threat model. Against software attackers, fTPM is sufficient -- the no-bus property defeats the cheap LPC/SPI sniffing class. Against well-funded physical attackers, fTPM is weaker than dTPM: TPM-Fail [@tpmfail-microsite] showed timing-side-channel ECDSA key recovery on Intel PTT, and faulTPM [@jacob-2023-faultpm] showed 2-3 hour state extraction on AMD PSP. Pluton sits between the two with a smaller TEE surface but less public scrutiny. Yes -- Microsoft mandates it. The OEM mandate has been in force since July 28, 2016 [@ms-learn-oem-tpm]; the consumer mandate became visible on June 24, 2021 with the Windows 11 announcement. The defensive primitives the TPM underwrites -- BitLocker, Credential Guard, Windows Hello, Device Health Attestation [@ms-learn-azure-measured-boot] -- are real, measurable, and not realistically replaceable by software-only equivalents. Practically no for dTPM and Pluton; the EK private key never leaves the chip, and replicating it would require silicon-level extraction that no public attack has achieved. faulTPM [@jacob-2023-faultpm] proved that AMD fTPM internal state can be *extracted* in 2-3 hours of physical access; that is closer to "extracted" than "cloned" but the practical effect is the same for keys the chip held. Because ransomware operates after the OS has loaded -- by definition outside the TPM's threat model. The TPM secures keys at rest and attests boot integrity. It does not run anti-malware, sign user files, or detect runtime compromise. Microsoft's BitLocker countermeasures page [@ms-learn-bitlocker-countermeasures] is explicit that BitLocker is a data-protection feature, not an anti-malware feature; the same logic applies to the TPM that underwrites it. Pluton implements TPM 2.0 plus Microsoft-specific extensions. From Windows's perspective it *is* a TPM with a different update story (Windows Update instead of UEFI capsule) and a different trust anchor (Microsoft as firmware signer). Whether the OEM exposes Pluton "as the TPM" or alongside a discrete TPM is an OEM choice [@ms-learn-pluton-as-tpm].

Return to June 24, 2021. The PR backlash about a Trusted Platform Module made the chip visible for the first time to a consumer audience that had owned one for a decade. The technical rationale Microsoft gave was four words long; the actual rationale is the rest of this article.

A passive cryptoprocessor designed in 1999 quietly became the load-bearing pillar of half of Windows security. Twenty-five years of engineering refined a single primitive -- measure, extend, seal, quote -- into something one chip could underwrite. Twenty-five years of attacks, from a $40 FPGA on an LPC bus to a voltage glitch against the AMD PSP, argued empirically about how passive that chip can be allowed to be. The current state of the art is on the CPU die, in Rust, signed by Microsoft, patched through Windows Update -- and post-quantum migration is the next argument.

The TPM is not a checkbox. It is the point at which Windows decided integrity must be measurable. It is not a panacea -- the runtime-compromised OS still wins once the key is unsealed -- but it is a primitive, with a clean boundary. Now you know what it can prove, and what it cannot. The chip is the cheapest part of the system. The cost was twenty-five years of getting it right.