Parag Mali - tag: tpm

The Card That Wasn't a Card: How Windows Authentication Outgrew the Smart Card Metaphor

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

**The Windows smart card story is the story of a metaphor.** Roland Moreno's 1974 "card with a secret" became Windows 2000's `SCardSvr.exe`, then Windows 8's TPM Virtual Smart Card (a software card with the same PC/SC interface), then Windows Hello for Business (which threw the card edge away and talks to the TPM directly), then FIDO2 (which added the origin binding the card was never designed for). The cryptographic primitive -- a non-exportable asymmetric key under a local gesture -- survives every transition. The 2014 disclosure that smart-card-required accounts still mint a harvestable NTLM hash is closed not by any change to the card but by Microsoft's 2024-2026 NTLM removal plan. The card was always cryptographically sound; the protection terminated at the act of signing.

1. A Smart Card Login That Mints an NTLM Hash

Picture May 2014. A Department of Defense contractor pushes her Common Access Card into a Windows 7 workstation, types a six-digit PIN, and watches the lock screen melt into her desktop. The RSA-2048 private key that just signed her Kerberos pre-authentication blob lives inside a tamper-resistant secure element she cannot extract from the card. The cryptography is excellent. Three hours later, an attacker on the same network owns her domain account without ever touching the card [@dirteam-aorato] [@kb-2871997].

How is that even possible? Hold that question. The answer is the spine of this article.

The contractor here is a composite figure, not a documented incident. The mechanism (CAC + Windows 7, RSA-2048 signing inside the card, an NT hash recoverable from LSASS three hours later) is the one Aorato disclosed in 2014 [@dirteam-aorato] and Microsoft documented in KB 2871997 [@kb-2871997]. The scenario is faithful to the published attack chain; the person and the office park are illustrative.

The protocol that ran when she logged in is PKINIT, defined by RFC 4556 [@rfc-4556] and profiled for Windows in [MS-PKCA] [@ms-pkca]. PKINIT lets a Kerberos client present an X.509 certificate as pre-authentication for the Authentication Service Request (AS-REQ), with a digital signature proving possession of the matching private key. In a Windows smart card logon the signing happens inside the card. The Microsoft Smart Card Key Storage Provider hands the card a hash; the card returns a signed AuthPack containing a PKAuthenticator (timestamp, nonce, paChecksum) and Diffie-Hellman parameters; that signed AuthPack rides in the PA-PK-AS-REQ pre-authentication data of the AS-REQ [@rfc-4556] [@ms-pkca].

So far, so good. The Key Distribution Center (KDC) verifies the signature, validates the certificate chain, mints a Ticket-Granting Ticket (TGT), and returns it. Our contractor sees her desktop.

But the KDC has a second job she does not know about. Her account is flagged "smart card required for interactive logon," so she has no password. Windows must still authenticate her to a legacy SMB1 server or any network application that speaks only NTLM. The clean answer would be "it cannot." The answer Microsoft shipped in Windows 2000 is: the KDC silently maintains an NTLM-equivalent secondary credential for every smart-card-only user, rotating it at logon, so legacy services keep working [@kb-2871997] [@msrc-kb-2871997].

That secondary credential is an NT hash. Once her session is live, an NT hash sits in the Local Security Authority Subsystem (LSASS) memory of every machine she touches. The smart card never sees it. The card cannot police it. It is sixteen bytes of MD4 output that the OS minted around the cryptographic operation the card refused to delegate.

A non-NTLM-derived NT hash that Windows maintains for accounts configured to log on with a smart card or other non-password credential, so that legacy NTLM-accepting services (SMB1, pre-Windows-2000 applications, some printers) continue to authenticate the user. The hash is computed from a random secret, not the card key, and is rotated by the KDC. From a pass-the-hash attacker's perspective, it is indistinguishable from a password-derived hash and equally replayable.

Three hours later, an attacker who has phished a privileged helpdesk account runs sekurlsa::logonpasswords from a copy of mimikatz [@mimikatz-gh] against the LSASS process on a server the contractor logged into earlier that day. The output looks like NTLM : a1b2c3.... The attacker pipes that NT hash into a pass-the-hash against any NTLM-accepting service in the forest. Because RFC 4757 [@rfc-4757] makes the RC4-HMAC Kerberos long-term key identical to the NT hash, the attacker can also forge Kerberos pre-authentication for the smart-card-required account and request its TGT. The card sat in a reader the attacker never touched. None of that mattered.

This is the inversion the article exists to explain. The card protected the key. The card did not, and could not, protect the identity. Microsoft documented the gap on May 13, 2014 as KB 2871997, "Update to improve credentials protection and management" [@kb-2871997]; the Microsoft Security Response Center followed with a blog overview of the threat model and the defence-in-depth response [@msrc-kb-2871997]. The disclosure came from Tal Be'ery and his team at Aorato, a Tel Aviv security startup Microsoft would acquire six months later. The period-accurate operator analysis lives in Sander Berkouwer's July 15, 2014 writeup, cited here because the original Aorato post is offline [@dirteam-aorato].

How did Windows arrive at an architecture where a tamper-resistant cryptographic token could leave the user's identity wide open? To answer that we go back to a 1974 patent in Paris.

2. How Cards Got a Chip

Roland Moreno was twenty-nine when he filed his first smart-card patent family in 1974. A self-taught Parisian, a former pinball-machine fixer and humorist who had washed out of the Sorbonne, he wired an off-the-shelf microchip to a ring of contacts on a small plastic substrate and walked the result over to INPI, the French patent office. The patent family -- known in the secondary literature as carte a memoire -- did not invent the integrated circuit, the credit-card form factor, or even the idea of embedding silicon in plastic. What Moreno added was a property: the card holds a secret the cardholder cannot extract [@wp-moreno] [@wp-smart-card].

That property is the entire story.

Helmut Groettrup, a West German engineer, got there first. He filed German patents DE1574074 and DE1574075 in February 1967 for a tamper-proof identification switch based on a semiconductor device, and added a joint Austrian filing with Juergen Dethloff in September 1968 [@bmpos-history] [@wp-smart-card]. The standard French historiography credits Moreno with the secured-memory refinement rather than the form factor. The inventor question depends on which property you treat as load-bearing.

Three other people belong in this section. In 1977 Michel Ugon, an engineer at Honeywell Bull's CP8 division in France, built the first microprocessor smart card -- a card with a CPU on it, not just memory. In 1978 Bull filed the SPOM patent that collapsed CPU and EEPROM onto one chip, the architectural change that made mass production tractable [@bmpos-history] [@cnam-pdf]. And from 1987 to 1995 the International Organization for Standardization froze the card edge into a vendor-neutral wire format with the four parts of ISO/IEC 7816 [@wp-smart-card]: physical characteristics, electrical and transmission protocols, and -- the part that would matter most for Windows -- the command set.

The international standard for contact smart cards, in four parts that interest software architects: Part 1 covers physical characteristics, Part 3 covers electrical interface and the T=0 and T=1 transmission protocols, and Part 4 covers the organisation, security, and command set for interchange. ISO/IEC 7816-4:2020 is the current edition of Part 4. Application Protocol Data Unit. The request/response unit a host application exchanges with a smart card. The command APDU starts with a four-byte header `CLA INS P1 P2` (class, instruction, two parameter bytes), followed by an optional length byte `Lc` and `Lc` bytes of data, and an optional expected-response-length byte `Le`. The response APDU is `[data] SW1 SW2`, where the two status word bytes encode success or a card-side error.

A worked APDU example makes this concrete. To select the PIV application on a smart card, a host sends 00 A4 04 00 0B A0 00 00 03 08 00 00 10 00 01 00. The first byte is CLA = 00 (interindustry class). The second is INS = A4 (SELECT). P1 = 04 indicates that the parameter is an application identifier. P2 = 00 selects the first occurrence. Lc = 0B says eleven data bytes follow, and those eleven bytes are the full PIV AID per NIST SP 800-73-4 [@sp-800-73-4-upd1]: nine bytes for the registered application identifier (A0 00 00 03 08 00 00 10 00) followed by the two-byte PIV application version identifier (the PIX, 01 00, per SP 800-73-4 Part 1 §2.2). The card replies with optional file control information and the status word 90 00, which means success. Every operation the Windows smart card stack performs decomposes, eventually, into a sequence of these short frames.

timeline title Card-as-authenticator timeline 1967-1968 : Groettrup and Dethloff file IC-on-card patent 1974 : Moreno files carte a memoire family 1977-1978 : Ugon and Bull build CPU smart card and SPOM 1987-1995 : ISO/IEC 7816 parts 1, 3, 4 published 1996 : PC/SC Workgroup founded 2000 : Windows 2000 ships SCardSvr.exe 2007 : Microsoft Base Smart Card CSP and minidriver model 2011 : Windows 7 SP1 inbox PIV/GIDS minidriver 2012 : Windows 8 ships Virtual Smart Card 2015 : Windows Hello announced 2024 : NTLMv1 removed in Windows 11 24H2

By 1996 the card edge was settled. Three thousand-odd APDU specifications and proprietary applets later, the only remaining question was: how does a personal computer talk to a card reader? Smart card readers lived in two operationally incompatible worlds, the bank-teller world and the workstation world, and the workstation world was held back by a vendor-driver swamp. So in 1996 a consortium called the PC/SC Workgroup formed. The contemporary record names Microsoft, IBM, Hewlett-Packard, Sun Microsystems, Siemens Nixdorf, and Bull as founders, with Schlumberger and other card vendors joining shortly after [@wp-pcsc] [@sc-architecture].

The PC/SC specification series ("Interoperability Specification for ICCs and Personal Computer Systems") names exactly the right abstractions: a Smart Card Resource Manager that brokers access to attached readers, an Interface Device Handler that abstracts reader hardware, and a Service Provider that exposes a uniform programming surface to applications [@sc-architecture]. A personal computer talks to a smart card by speaking PC/SC, in user-mode, through whatever service the OS provides.

Personal Computer/Smart Card. The 1996 industry consortium and its specification series that define how a smart card reader is exposed to a desktop operating system. PC/SC factors the stack into reader hardware (Interface Device), an Interface Device Handler driver, a Smart Card Resource Manager (a system service brokering access), and a Service Provider exposing a uniform API to applications.

Microsoft answered the implementation question in February 2000 with SCardSvr.exe, the Smart Cards for Windows service that shipped in Windows 2000 [@sc-architecture]. And immediately created a new problem: every card vendor still wanted to own the cryptographic provider.

3. From SCardSvr to Base CSP: Eleven Years to a Vendor-Neutral Stack

Windows 2000 shipped smart card logon as a vendor-neutral primitive. Within months, the operational reality bit. Every card vendor shipped a different CryptoAPI plug-in, every plug-in needed installing per machine, per card, sometimes per user.

Walk down the stack. At the bottom is the reader, attached over USB or, in early-2000s deployments, an internal serial port. Above the reader is the Interface Device Handler driver supplied by the reader vendor. Above the driver is SCardSvr, Microsoft's Smart Card Resource Manager service. SCardSvr exposes a user-mode API called WinSCard: SCardEstablishContext, SCardConnect, SCardTransmit, SCardDisconnect [@winscard-api]. WinSCard is the C-level entry into PC/SC; an application that wants to send raw APDUs to a card uses WinSCard directly [@sc-architecture].

The Windows user-mode API surface for PC/SC. Canonical entry points include `SCardEstablishContext`, `SCardListReaders`, `SCardConnect`, `SCardTransmit`, and `SCardDisconnect`. An application sending raw APDUs to a smart card uses WinSCard; higher-level Windows components (Kerberos client, certificate enrolment, the lock-screen credential provider) reach the card indirectly through the Cryptographic Service Provider or Key Storage Provider layers.

Cryptographic clients do not want to write APDU sequences. They want to call CryptSignHash or NCryptSignHash and have a signature appear. Translating those API calls into the card's APDU command set is the job of a Cryptographic Service Provider in the CryptoAPI 1.0 world and a Key Storage Provider in the CNG (Cryptography Next Generation) world. From 1996 to 2007, almost every card vendor wrote its own CSP. The Schlumberger CSP. The Gemalto CSP. The Axalto CSP. The ActivIdentity CSP. Each was an in-process DLL that talked to the card through WinSCard, applied vendor-specific quirks, and exposed a CSP interface to Windows.

A plug-in for CryptoAPI 1.0 that provides cryptographic services (key generation, signing, hashing, key storage) to applications. CryptoAPI loads a CSP in-process. For smart cards, the CSP translates CryptoAPI calls into card-specific APDUs through WinSCard. Microsoft Base Smart Card CSP, shipped in 2007, replaced the per-vendor CSP with a single CSP that delegated card-specific behaviour to a much smaller minidriver. The CNG-era plug-in that provides key storage and asymmetric cryptographic operations. CNG separates algorithm providers (BCrypt: hashing, symmetric, signature primitives) from key storage providers (NCrypt: key lifecycle, key-protected operations). The Microsoft Smart Card Key Storage Provider is the CNG-side path for smart card and Virtual Smart Card keys; the Microsoft Platform Crypto Provider is its sibling that talks to the TPM directly.

The architecture had two problems by 2003. First, an N x M combinatorial. Every new card vendor multiplied integration cost for every cryptographic application, and vice versa. Large enterprises ran two or three CSPs per workstation; subtle bugs in signature padding or PIN caching only surfaced when an application built for vendor A's CSP met a card configured for vendor B's. Second, a security problem: each CSP ran in-process with every CryptoAPI client, so a buggy or compromised third-party CSP could reach critical OS components.

Microsoft's answer was the Smart Card Minidriver Specification, finalised around the Vista launch in 2006-2007. Microsoft would ship one CSP -- the Microsoft Base Smart Card CSP -- containing the cryptographic state machine common to all PIV-style cards. Per-card behaviour would live in a much smaller DLL called a minidriver, loaded by the Base CSP when it recognised the card. The specification, dn631754, currently maintained at v7.07, says exactly this: "The Microsoft Smart Card Base CSP and KSP is a refinement of the architecture that separates commonly needed CAPI-based CSP and CNG-based KSP functionality, respectively, from the implementation details that must change for every card vendor" [@sc-minidrivers] [@sc-minidriver-spec].

The CNG-side sibling, the Microsoft Smart Card Key Storage Provider, plugs into the same minidriver layer. CNG is the post-Vista cryptographic platform: BCrypt for algorithm primitives, NCrypt for key lifecycle and storage [@cng-storage]. The Smart Card KSP supports DH 512-4096, ECDH P256/P384/P521, ECDSA P256/P384/P521, and RSA 512-16384 [@cng-ksp-list]. Both the legacy Base CSP and the modern KSP route through the same minidriver, so a card vendor writes one DLL and gets compatibility with both CryptoAPI 1.0 and CNG applications.

flowchart TD A[Reader hardware] --> B[IFD driver] B --> C[SCardSvr Smart Card Resource Manager] C --> D[WinSCard user-mode API] D --> E[Microsoft Base Smart Card CSP and Smart Card KSP] E --> F[Card minidriver DLL] F --> G[ISO 7816-4 APDU on the card] H[CryptoAPI 1.0 client] --> E I[CNG NCrypt client] --> E

CryptoAPI's CryptSignHash walks the Base CSP; CNG's NCryptSignHash walks the Smart Card KSP; both end up issuing the same APDU sequence through the same minidriver to the same card.

Property	CryptoAPI Base CSP	CNG Smart Card KSP
Era	CryptoAPI 1.0, pre-Vista to present (legacy support)	CNG, Vista onward
Entry point	`CryptAcquireContext`, `CryptSignHash`	`NCryptOpenStorageProvider`, `NCryptSignHash`
Implementation DLL	`basecsp.dll`	`microsoft smart card key storage provider` registered through `ncrypt.dll`
Per-card extension	Smart card minidriver	Same smart card minidriver
Algorithm range	RSA, basic ECC	RSA, full Suite B ECC, large key ranges

By 2008 the architecture was elegant. But every PIV card still needed a minidriver acquired from somewhere -- a CD, a vendor ftp site, an enterprise distribution share. And in 2004 the US federal government was about to make the smart card mandatory for several million people who could not wait for a vendor disk.

4. PIV, GIDS, CAC, and the Inbox Driver That Removed the Last Install Step

On August 27, 2004, President George W. Bush signed Homeland Security Presidential Directive 12, a one-page policy with one operational sentence: there shall be "a mandatory, government-wide standard for secure and reliable forms of identification issued by the federal government to its employees and contractors" [@hspd-12]. HSPD-12 did not specify how. It pointed at the National Institute of Standards and Technology and said "make it so."

NIST's response was FIPS 201, the Personal Identity Verification standard, first published in February 2005. The current revision, FIPS 201-3, was published in January 2022, superseding FIPS 201-2 from 2013 [@fips-201-3] [@fips-201-3-pdf]. Where FIPS 201 specifies the credential -- what a PIV card is, biometrically, biographically, visually -- the companion NIST SP 800-73 specifies the card-edge interface: file system, data objects, APDU command set [@sp-800-73-4-upd1].

The US federal smart card identity credential defined by FIPS 201 and its companion NIST Special Publications. FIPS 201 defines what a PIV credential is; NIST SP 800-73 defines the card-edge interface (file structure, data objects, APDU command set) so any host can talk to any PIV-compliant card; SP 800-78 covers cryptographic algorithms; SP 800-76 covers biometrics; SP 800-79 covers card issuer accreditation.

The numbers are striking. NIST reports "close to five million PIV Cards today provide multifactor authentication to federal IT resources and facilities" [@nist-piv-home]. The largest single cohort is the DoD Common Access Card (CAC), which by 2002 numbers had reached more than one million card readers across more than 1,000 issuance sites in more than 25 countries [@wp-cac].

Microsoft, watching from Redmond, faced two choices: negotiate a separate minidriver for the GSC-IS card-edge applet some federal agencies were using, or ship an inbox class minidriver that auto-discovered PIV-compliant cards out of the box -- and for completeness, supported a Microsoft-defined alternative called the Generic Identity Device Specification.

GIDS, Microsoft's complementary card-edge profile, shipped v1.0 in April 2010 and v2.0 in October 2012 [@gids-spec]. It was a profile for card vendors and TPM integrators who wanted a Microsoft-blessed alternative to PIV, and it would become important to Windows 8's Virtual Smart Card design.

The Generic Identity Device Specification, a Microsoft-published smart card profile for identity credentials. GIDS v1.0 published April 2010; v2.0 published October 2012. GIDS coexists with PIV at the inbox minidriver layer: Windows' inbox `msclmd.dll` recognises both, allowing zero-install integration for any card that implements either applet.

The inbox driver shipped in Windows 7 SP1 in February 2011. Microsoft Learn is direct: "Windows provides an inbox generic class minidriver that supports Personal Identity Verification (PIV)-compliant smart cards and cards that implement the Generic Identity Device Specification (GIDS) card edge" [@inbox-minidriver]. The auto-discovery sequence is sequential: msclmd.dll issues a SELECT for the PIV AID; if the card returns 90 00, Windows treats it as PIV. If the PIV select fails, the driver tries the GIDS AID; if that succeeds, Windows treats the card as GIDS. If both selects return a "neither-AID-exists" status, Windows still proceeds as if the card were GIDS, and the inbox driver continues to handle it. Only an unknown SELECT error makes the inbox driver decline and Windows fall back to a vendor minidriver [@inbox-minidriver]. The effect: any PIV-compliant card (CAC, Yubico YubiKey 5 [@yubico-piv], any FIPS 201-compliant federal credential) worked on a stock Windows 7 SP1 install with zero additional software.

Before Windows 7 SP1, deploying a CAC to a workstation required an out-of-band CSP install: a vendor disk, an enterprise distribution share, or a manual download. Some classified networks could not reach the vendor distribution channels at all. The inbox `msclmd.dll` removed that friction. A workstation that had never been online could authenticate a CAC user on first boot, provided it was joined to a domain whose KDC chain it could reach for PKINIT validation. Many DoD operational deployments lived inside the airgap, and many of them only became deployable at scale once the inbox minidriver had landed.

With the card-edge problem solved and the install problem closed, what remained was the protocol Windows logon would use. That protocol is PKINIT.

Public Key Cryptography for Initial Authentication in Kerberos. Specified by [RFC 4556](#) [@rfc-4556] and profiled for Windows by `[MS-PKCA]` [@ms-pkca]. PKINIT lets a Kerberos client present an X.509 certificate, and prove possession of the private key, as pre-authentication for the Authentication Service Request (AS-REQ), instead of a password-derived shared secret. The Windows AS Exchange remains otherwise unchanged: the client receives a TGT encrypted with a session key established under the public-key exchange. The PKINIT structure that carries the client's proof of possession. It contains a `PKAuthenticator` (cusec, ctime, nonce, paChecksum) and Diffie-Hellman parameters. The client signs the `AuthPack` with the private key corresponding to its certificate, then embeds the signed structure in the `PA-PK-AS-REQ` pre-authentication data of the Kerberos AS-REQ. The granularity matters: the signature covers the `AuthPack`, not the AS-REQ as a whole.

In a Windows smart card logon the path from PIN to TGT runs through eight named components. Walk it once and the rest of the article becomes legible.

sequenceDiagram participant U as User at lock screen participant CP as Credential Provider participant LSA as LSASS Kerberos client participant KSP as Microsoft Smart Card KSP participant MD as Minidriver participant CARD as Smart card participant KDC as Domain Controller KDC

U->>CP: Insert card, type PIN
CP->>LSA: Logon attempt with PIV credential
LSA->>KSP: NCryptSignHash on AuthPack hash
KSP->>MD: Card-specific sign request
MD->>CARD: VERIFY PIN, then SIGN APDU
CARD-->>MD: Signed AuthPack bytes, SW=9000
MD-->>KSP: Signed AuthPack
KSP-->>LSA: Signed AuthPack
LSA->>KDC: AS-REQ with PA-PK-AS-REQ pre-auth
KDC->>KDC: Verify signature, cert chain, freshness
KDC-->>LSA: AS-REP with TGT
LSA-->>CP: Logon success, session keys cached
CP-->>U: Desktop

Notice what the card sees and what it does not. It sees a hash to sign and a PIN to verify. It does not see "I am authenticating to KDC DC01.contoso.local for user jdoe." A PIV card is a signing oracle. The relying party identity, the freshness, the replay window, the binding of signature to context: all of that lives in the protocol above the card, not in the card itself. We come back to this in section 8.

Key idea: The cryptographic primitive at the centre of the smart card metaphor -- a non-exportable asymmetric key, bound to a tamper-resistant element, gated by a local gesture -- is the longest-lived object in this lineage. The interface around the primitive (PC/SC, CryptoAPI, CNG, NCrypt-direct, WebAuthn) is what changes every generation.

By 2013 the cryptographic story was excellent. PKINIT was a clean Kerberos AS exchange. The card protected the key. The KDC issued a TGT. Then, in a few months in 2014, one researcher in Tel Aviv showed that the protection ended at the very moment of signing.

5. KB2871997 and the NTLM Secondary Credential

Tal Be'ery, then Vice President of Research at Aorato, sat down in early 2014 with a question that should have had a boring answer. If an Active Directory account is flagged "smart card required for interactive logon," and the user has no password, is the account immune to pass-the-hash?

The answer is no. Aorato's original disclosure post is offline; Microsoft acquired Aorato in November 2014 and the research became the foundation of what is now Microsoft Defender for Identity. The period-accurate operator analysis that survives in public is Sander Berkouwer's July 15, 2014 dirteam.com writeup, cited here in lieu of the dead original [@dirteam-aorato].

The attack is built from three off-the-shelf parts. The first is the NTLM secondary credential we met in section 1: every smart-card-only account in Active Directory has a usable NT hash on the KDC, maintained for legacy compatibility. The second is the harvesting tool. Benjamin Delpy's mimikatz had reached its 2.0-alpha milestone in April 2014; the README documents sekurlsa::logonpasswords extracting NT hashes from LSASS, plus sekurlsa::pth and golden-ticket forgery for replay [@mimikatz-gh]. The third is the cryptographic identity that makes hashes Kerberos-relevant. RFC 4757 section 2 establishes that the RC4-HMAC long-term key in Kerberos is the NT hash itself, "for compatibility reasons" [@rfc-4757] [@dirteam-aorato].

Compose those three parts. An attacker with administrative footing on any machine the user has touched runs sekurlsa::logonpasswords against LSASS and gets the NT hash. By RFC 4757 the hash is a usable Kerberos RC4-HMAC pre-authentication key for the user; pre-auth is a function of the long-term key, so the attacker can request a TGT. Or they replay the hash directly via SMB. The card sits, intact, in the user's reader. Nothing about it has changed.

The smart card's tamper-resistance was real. But the cryptographic guarantee terminated at the act of signing -- not at the authentication outcome.

This is the article's central inversion. The card was right. The system was wrong. The card protected the key; the OS minted credentials around that key the card could not police; the protection terminated at the signing operation; the identity did not.

Given an interactive shell as Local System or a debug-privileged user, the harvest is two commands:

privilege::debug
sekurlsa::logonpasswords

sekurlsa::logonpasswords walks LSASS sessions and prints any cached NT hashes, including the rotated secondary credential for smart-card-required users. The pass-the-hash replay is one more:

sekurlsa::pth /user:JaneDoe /domain:CONTOSO /ntlm:a1b2c3...

This launches a process whose Kerberos ticket cache accepts the supplied NT hash as the RC4-HMAC pre-auth key for the named principal. Any tool spawned from that process can request service tickets for the user. The smart card need not be in any reader on any machine on the network. KB 2871997 and the Pass-the-Hash mitigations (KB 2984972, 2984976, 2984981) addressed this defence-in-depth; NTLM removal addresses it structurally.

Microsoft's response shipped on May 13, 2014 as Security Advisory KB 2871997, "Update to improve credentials protection and management." It is mostly a registry change and a recommended Group Policy: set HKLM\SYSTEM\CurrentControlSet\Control\Lsa\TokenLeakDetectDelaySecs to 30 seconds [@kb-2871997]. The June 2014 MSRC blog added more context, especially around a new security group called Protected Users [@msrc-kb-2871997].

Protected Users, added to Windows Server 2012 R2 domains and Windows 8.1 clients, blocks NTLM, blocks DES and RC4 in Kerberos pre-authentication, blocks both forms of delegation, and prevents offline sign-in caching [@protected-users]. Add a privileged account to Protected Users and you force it off the RC4-HMAC code path. An attacker who steals the NT hash no longer has a usable Kerberos pre-auth key, even though the hash itself is still recoverable.

Microsoft's later response was Credential Guard, which isolates credential material in a Virtualization-Based Security (VBS) container called LSAISO, separated from LSASS by a Hyper-V trust boundary. On Windows 11 22H2 and Server 2025, Credential Guard is enabled by default on domain-joined, non-DC systems that meet hardware requirements, protecting NTLM hashes, Kerberos TGTs, and stored domain credentials [@credential-guard].

Note: The KB 2871997 family (TokenLeakDetectDelaySecs, Protected Users, LSA Protection / RunAsPPL, Credential Guard later) is defence-in-depth. It makes hash theft harder, the harvested hash less universally useful, and lateral movement more visible. None of those measures removes the secondary NT hash itself. The structural fix is to remove NTLM. That work began in earnest with the 2023 "evolution of Windows authentication" announcement and reached its first hard milestone with the NTLMv1 removal in Windows 11 24H2 and Windows Server 2025 [@evolution-windows-auth] [@ntlmv1-removal].

Two sentences look identical but mean very different things: "the card protected the key" and "the system protected the user." The first is a statement about a piece of hardware and the cryptographic discipline of its operation; it was true in 1996, true in 2014, true today. The second is a statement about the authentication subsystem that uses the card. In 2014 it was false, and the falsehood had been present for fourteen years, hidden under the assumption that strong cryptography at the card edge guaranteed a corresponding strength of identity assertion. The 2014 disclosure was a forcing function for distinguishing the two. Every subsequent design (VSC, WHfB, FIDO2) can be evaluated by where it draws that line.

If the card alone could not deliver the protection, perhaps the right move was to throw away the physical card entirely. Microsoft had shipped exactly that experiment eighteen months earlier.

6. Virtual Smart Cards in Windows 8

On October 26, 2012, Microsoft shipped Windows 8. Buried in the new features, alongside the Start screen redesign and the Hyper-V client, was a command-line tool named tpmvscmgr.exe that created a smart card without any plastic. The tool is still there. Open an elevated prompt on a current Windows installation and type tpmvscmgr create /name vsc1 /AdminKey DEFAULT /PIN PROMPT, and the system manufactures a new entry under ROOT\SMARTCARDREADER\ that any PC/SC client sees as a freshly inserted card [@tpmvscmgr].

The pitch is mechanical. Every Windows 8+ device with a Trusted Platform Module already has the cryptographic substrate of a smart card on the motherboard: a tamper-resistant chip, a non-exportable key store, dictionary-attack resistance, an isolated execution environment for crypto. Why not implement the smart card abstraction in software, with the TPM as the backing chip [@vsc-overview] [@vsc-understanding]?

The Microsoft Learn "Virtual Smart Card Overview" makes the framing crisp. The three core properties of a smart card -- non-exportability, isolated cryptography, anti-hammering -- map directly onto TPM capabilities. Non-exportability becomes TPM key wrapping. Isolated cryptography becomes signing inside the TPM. Anti-hammering becomes the TPM's dictionary-attack counter [@vsc-overview] [@vsc-understanding].

A TPM-backed software smart card introduced in Windows 8 (October 2012). A VSC exposes the same PC/SC card edge as a physical card -- the same WinSCard API, the same Base CSP, the same Microsoft Smart Card KSP, the same minidriver model. The chip backing the card is the TPM, soldered to the motherboard, rather than a removable IC on a plastic substrate. From the perspective of any application using the WinSCard API, a VSC is indistinguishable from a permanently-inserted physical smart card.

Note: Windows 8 shipped Virtual Smart Cards in October 2012. The Trusted Computing Group did not ratify TPM 2.0 until 2014. VSCs are therefore a TPM-binding policy technology, not a TPM-2.0-bound technology; Microsoft Learn lists TPM 1.2 as the documented minimum. TPM 2.0 works and is the practical choice on modern Windows 11 installations, but the architecture predates it [@vsc-overview] [@vsc-understanding].

The beauty of the design is that nothing above the chip changed. Applications still call CryptSignHash or NCryptSignHash. The Base CSP and Smart Card KSP still route through a minidriver. The minidriver still sends APDUs through WinSCard to a reader. The only differences: the reader is a software pseudo-device named Microsoft Virtual Smart Card, and the card behind it is the TPM dressed up as an ISO 7816-4 applet.

flowchart LR subgraph Physical [Physical smart card] A1[Application] --> B1[CSP/KSP] B1 --> C1[Minidriver] C1 --> D1[WinSCard] D1 --> E1[USB reader] E1 --> F1[Plastic card IC] end subgraph Virtual [Virtual smart card] A2[Application] --> B2[CSP/KSP] B2 --> C2[Minidriver] C2 --> D2[WinSCard] D2 --> E2[Virtual reader] E2 --> F2[TPM on motherboard] end

The cryptographic substrate underneath the abstraction is the TPM, and the binding policy is per-device. The Microsoft Learn "Understanding and Evaluating Virtual Smart Cards" article is precise: "Non-exportability: Because all private information on the virtual smart card is encrypted by using the TPM on the host computer, it can't be used on a different computer with a different TPM" [@vsc-understanding]. The property that makes a VSC tamper-resistant also makes it un-migratable. A TPM clear destroys the keys irrecoverably. We return to that in section 8.

The canonical primary source for the architecture is the "Understanding and Evaluating Virtual Smart Cards" whitepaper on the Microsoft Download Center. The download page reports Version: July 2014, Date Published: 7/15/2024 [@vsc-whitepaper]. The 2014 revision is canonical.

The card was a metaphor. Microsoft kept the byte-for-byte PC/SC interface and put the TPM behind it.

A worked provisioning example brings the design to ground. The tpmvscmgr create command takes four arguments that matter for security policy: the administrative key (/AdminKey {DEFAULT | PROMPT | RANDOM}), the PIN policy (/PIN PROMPT or /PIN DEFAULT), the attestation mode (/attestation {AIK_AND_CERT | AIK_ONLY}), and the card's reader instance, surfaced under ROOT\SMARTCARDREADER\000n in Device Manager [@tpmvscmgr].

{` function provisionVSC(opts) { const adminKeyMap = { DEFAULT: '0102030405060708' + '0102030405060708' + '0102030405060708', PROMPT: '[user-supplied 48 hex chars]', RANDOM: '[random 24-byte key the admin must record]', }; const attestationNote = { AIK_ONLY: 'Identity-binding only; no platform certificate chain stored on the card.', AIK_AND_CERT: 'Full AIK-and-EK-cert chain stored; supports federated re-enrolment.', NONE: 'No attestation; the card is identity-only.', }; return { cardName: opts.name, adminKey: adminKeyMap[opts.adminKey] || 'invalid', pin: opts.pin === 'PROMPT' ? '[user-typed PIN, min 8 chars, alphanumeric+special allowed]' : '12345678', attestation: attestationNote[opts.attestation || 'NONE'], advice: opts.adminKey === 'DEFAULT' ? 'WARN: default admin key is documented; treat as factory-default.' : 'OK: admin key not factory-default.', }; }

console.log(provisionVSC({ name: 'vsc-jdoe', adminKey: 'RANDOM', pin: 'PROMPT', attestation: 'AIK_AND_CERT', })); `}

The default administrative key 010203040506070801020304050607080102030405060708 is documented in the public tpmvscmgr page [@tpmvscmgr]. Any VSC provisioned with /AdminKey DEFAULT should be treated as factory-default; in production, supply (PROMPT) or randomise (RANDOM) the admin key and store it separately.

The provisioning chain has four hard-to-script steps: run tpmvscmgr create as administrator; request and install an authentication certificate from a PKI the domain trusts (typically Microsoft Certificate Services with an enterprise CA and a smart card auto-enrolment template); set the user PIN; log the user out and back in. Each step is a place an enterprise rollout can stall.

Key idea: Microsoft kept the PC/SC card edge byte-for-byte and put the TPM behind it. The Virtual Smart Card was, technically, exactly that: a software smart card whose chip happened to be soldered to the board. The cryptographic primitive at the centre did not change; only the form factor of the chip carrying it did.

VSCs solved the physical-distribution problem. They did not solve the user-experience problem -- and they introduced a new one no Windows feature had ever produced quite this way: a credential a hardware reset could permanently destroy.

7. WHfB, FIDO2, and the Card Edge That Got Discarded

On March 17, 2015, Joe Belfiore announced Windows Hello on the Windows Experience Blog: "I'd like to introduce you to Windows Hello -- biometric authentication which can provide instant access to your Windows 10 devices" [@windows-hello-blog]. The consumer pitch was face and fingerprint. The mechanism underneath, in the enterprise variant called Windows Hello for Business (WHfB), was the same TPM-bound asymmetric key the Virtual Smart Card had used -- except there was no virtual reader, no virtual minidriver, and no virtual APDU.

WHfB talks to the TPM directly through the Microsoft Platform Crypto Provider, a CNG Key Storage Provider that calls into the TPM rather than into a smart card minidriver [@whfb-overview] [@whfb-how-it-works]. The PC/SC card edge had been removed from the path entirely. The cryptographic primitive (non-exportable TPM-bound asymmetric key, gated by a local gesture, used to sign an authentication request) survived; the interface around the primitive simplified.

Microsoft Learn describes WHfB in five phases: device registration, provisioning, key synchronisation, certificate enrolment (cert-trust only), authentication. The public key is registered with the identity provider and mapped to the user account; the private key never leaves the device [@whfb-how-it-works]. WHfB ships in three deployment models -- cloud-only, hybrid, on-premises -- and two trust types: key-trust and cert-trust [@whfb-deploy].

Key-trust is cloud-first. The TPM-bound public key is registered with Microsoft Entra ID; authentication is a public-key proof of possession to Entra, which mints whatever downstream artifacts a federated service needs (PRT, refresh token, optional Kerberos TGT via the cloud Kerberos service). No X.509 certificate sits in the user's path. Cert-trust adds an X.509 wrapper for downstream services that require one: an enterprise PKI issues a smart-card-logon-style certificate bound to the TPM key, and the WHfB authentication produces a Kerberos PKINIT exchange against an on-premises DC, just as a physical smart card would. The certificate is the adapter to brownfield infrastructure that still expects a smart-card-shaped credential [@whfb-deploy].

So far the lineage has been Windows-specific. FIDO2 is not. WebAuthn 2 is a W3C Recommendation; CTAP 2.1 is a FIDO Alliance specification [@webauthn-2] [@ctap-2-1]. Together they specify a cross-vendor protocol for public-key authentication to web relying parties, with one load-bearing property the smart card lineage never had: origin binding.

The property that a WebAuthn credential is scoped to a specific relying party identifier (the RP ID, typically a domain name) and the authenticator will refuse to sign an assertion for any other RP ID. The W3C WebAuthn 2 specification states: "the public key credential can only be accessed by origins belonging to that Relying Party. This scoping is enforced jointly by conforming User Agents and authenticators" [@webauthn-2]. A PIV smart card has no equivalent property; it will sign whatever the host hands it.

Origin binding is the structural fix to a class of relay attacks. A PIV smart card cannot tell whether it is signing a Kerberos AuthPack for the legitimate KDC or a maliciously crafted blob for an attacker-controlled relay; the card has no notion of "what is this signature for." A WebAuthn authenticator does. It hashes the RP ID into the signed assertion, the relying party verifies the RP ID matches its own origin, and a phishing site cannot trick the authenticator into producing a signature it will accept.

Microsoft Entra ID supports FIDO2 in two flavours. Device-bound passkeys live on a FIDO2 security key (a YubiKey 5 [@yubico-piv]) or in Microsoft Authenticator and cannot be extracted. Synced passkeys are credentials a platform synchronises across the user's devices through a cloud passkey provider [@entra-passkeys-howto] [@entra-passwordless]. The trade-off is sharp: device-bound passkeys support attestation (the relying party can verify authenticator hardware at registration); synced passkeys do not.

For workforce identity, Microsoft's passwordless strategy describes a four-step journey: deploy a password-replacement option, reduce user-visible password surface, transition to passwordless, eliminate passwords [@passwordless-strategy]. WHfB and FIDO2 are the two recommended replacements.

What about smart cards? The Microsoft Learn Virtual Smart Card Overview now opens with a Warning box that reads, in full: "Windows Hello for Business and FIDO2 security keys are modern, two-factor authentication methods for Windows. Customers using virtual smart cards are encouraged to move to Windows Hello for Business or FIDO2. For new Windows installations, we recommend Windows Hello for Business or FIDO2 security keys" [@vsc-overview]. The deprecation signal could not be more explicit. Physical PIV and CAC cards are not deprecated -- the federal government is not switching off PIV -- but the structural recommendation for greenfield is now WHfB or FIDO2.

Why did Virtual Smart Cards not survive into the WHfB era? Three reasons.

The first is provisioning UX. A VSC requires four steps (tpmvscmgr create, certificate enrolment, PIN set, logon round-trip) where WHfB requires one (a setup wizard the user runs at first sign-in). Each VSC step can fail in idiosyncratic ways: the enterprise CA template not configured for VSCs, the user's certificate request rejected, the PIN policy mismatched between the GPO and the card. Even when every step succeeds, the user sees a "smart card" UI -- card reader prompts, PIN entries -- that does not match the device they are holding.

The second is recovery. A TPM clear destroys VSC keys irrecoverably. Microsoft Learn states the constraint plainly [@vsc-understanding]: "all private information on the virtual smart card is encrypted by using the TPM on the host computer." Recovery would have to be re-enrolment under a federated attestation chain. The AIK-and-EK-cert attestation mode in tpmvscmgr exists [@tpmvscmgr], but it never grew into a productised re-enrolment story; the practical answer was always "issue a new card."

The third is the multi-device world. VSCs bind one credential to one device. By 2017 most enterprise users had at least two devices: a laptop and a phone. By 2022 most had three. A credential metaphor borrowed from the era of one workstation per user could not stretch.

Where do physical smart cards still belong in 2026? Three places. First, federal PIV / DoD CAC: the badge IS the credential, the issuance lifecycle is owned by an external organisation, and the cards have to work cross-platform and cross-application in a way a Windows-only credential cannot. Second, high-assurance regulated industries (banking, healthcare imaging, court systems) where existing PKI investment and signed-document workflows make the card the institutional artifact, not just an authentication factor. Third, "smart card removal locks workstation" cases (operating-room PCs, trading-floor terminals) where the physical act of pulling the card out of the reader is the security control.

Where does Entra Certificate-Based Authentication fit? Entra CBA is the cloud-native PIV/CAC path. A federal user logs into Entra ID directly with their PIV/CAC card, bypassing the on-premises ADFS infrastructure that was the traditional cloud-bridge for federal organisations. Entra CBA preserves the PIV credential while replacing the on-premises STS, and is the practical answer to "we have to keep PIV, but also we are migrating to cloud."

The table below condenses the comparison.

Method	Where the key lives	Origin binding	NTLM secondary	Provisioning steps	Multi-device	Phishing resistance	Recovery	Suitable for new deployments
Physical PIV / CAC	Removable IC	No (relay possible)	Yes (until NTLM removed)	High (PKI + issuance)	Yes (cross-device by physical movement)	Conditional	Re-issue card	Federal/DoD only
TPM Virtual Smart Card	On-device TPM	No	Yes (until NTLM removed)	High (4-step)	No (bound to one TPM)	Conditional	Re-enrol	Not recommended (deprecation Warning)
WHfB key-trust	On-device TPM	Limited (RP=Entra)	Reduced (cloud Kerberos)	Low (in-OS wizard)	Per-device enrolment	Yes (relative)	Re-enrol via device registration	Yes (cloud/hybrid)
WHfB cert-trust	On-device TPM	Limited (RP=AD)	Yes (until NTLM removed)	Medium (PKI required)	Per-device enrolment	Conditional	Re-enrol; CA-issued cert	Yes (brownfield PKI)
FIDO2 security key	External authenticator (e.g., YubiKey)	Yes (WebAuthn RP ID)	Not applicable (no Kerberos)	Low	Yes (key is portable)	Yes (origin-bound)	Spare key or backup credential	Yes (high-assurance)
Entra device-bound passkey	TPM or external authenticator	Yes (WebAuthn RP ID)	Not applicable	Low	Per-device	Yes	Re-enrol	Yes
Entra synced passkey	Cloud-synced (no attestation)	Yes (WebAuthn RP ID)	Not applicable	Low	Yes (cloud-synced)	Yes (origin-bound)	Cloud provider recovery	Yes (consumer, low-friction)

The architecture is now mature. But the lineage has a hard ceiling no architecture can cross: a signing oracle cannot tell you what it signed for.

8. What a Card Edge Can and Cannot Mediate

Set aside provisioning UX. Set aside NTLM legacy. Set aside everything Windows-specific. What are the structural limits any card-edge-or-equivalent design must accept? Six, by my count, and each one is anchored to a primary source.

The card edge is a signing oracle, not a transcript witness. A PIV card receives a hash and returns a signature. It does not know what protocol the signature is for, what relying party requested it, or whether the same hash has been requested two minutes ago by an attacker on a wireless network. PKINIT's vulnerability to relay was open from 2006 (RFC 4556) until 2017 (RFC 8070, which added a freshness token to the AS exchange) [@rfc-4556] [@rfc-8070]. The fix had to live in the protocol, not in the card. The card cannot prove what it signed for.

The card has no notion of relying-party identity. This is the structural defect WebAuthn fixes. A WebAuthn authenticator includes the RP ID in the signed assertion and refuses to release a signature for the wrong RP. The W3C specification states this property explicitly [@webauthn-2]. A PIV card does not. To add an equivalent property to the smart card lineage would have meant changing the SP 800-73 command set; it was easier to throw the PC/SC card edge away and start over with FIDO2.

Cryptographic protection at the card edge cannot reach downstream OS-minted credentials. This is the 2014 NTLM-secondary lesson at its most general. The card protects a key; the OS may mint credentials around that key the card cannot police. Microsoft KB 2871997 closed the leak with defence-in-depth retrofits (TokenLeakDetectDelaySecs, Protected Users, RunAsPPL, eventually Credential Guard) [@kb-2871997] [@msrc-kb-2871997] [@protected-users] [@credential-guard]; the structural close had to wait for the 2024-2026 NTLM removal programme [@ntlmv1-removal]. Any future credential the OS mints around the card's key is, by construction, outside the card's authority.

Revocation must be reachable, and the card cannot tell you when it is not. A PIV card's certificate is a relying-party-side concept; revocation status is a property of the issuing PKI, not the card. CRL distribution points and OCSP responders are the relying party's problem to reach. When a domain controller cannot reach the CRL, the policy choice is to fail open or fail closed; either policy carries risk. The [MS-PKCA] Windows profile specifies server-side certificate-validation processing -- including revocation checking -- as a property of the KDC, not the credential the card presented [@ms-pkca]. The card signed correctly either way.

Certificate-to-user mapping must be strongly bound, and again the card cannot help. When a domain controller receives a PKINIT request, it must map the presented certificate to an Active Directory account. The Certifried CVE class disclosed in May 2022 (CVE-2022-26923, CVE-2022-26931, CVE-2022-34691) showed that weak mapping -- by Subject Alternative Name UPN without a strong identifier bound into the certificate -- lets an attacker who can enrol against an over-permissive template impersonate any account [@kb-5014754]. The card signed exactly what it was asked to sign; the structural defect was at the KDC's mapping step. Microsoft KB 5014754 closed the mapping defect by requiring strong certificate-to-account binding; we return to its multi-year deployment timeline in §9 [@kb-5014754].

Hardware-bound keys cannot be teleported -- and this is both feature and limit. Non-exportability is the central promise of the entire lineage. It is also the bound. A TPM clear or a hardware replacement destroys the key. The recovery story has to be re-enrolment, not restore. Microsoft Learn states the constraint for VSCs and the same constraint applies, structurally, to every TPM-bound or external-authenticator credential -- including FIDO2 device-bound passkeys [@vsc-understanding]. Synced passkeys recover this property by giving up attestation; you cannot have both.

Non-exportability is the property. It is also the bound.

Key idea: An ideal card-lineage authenticator refuses to sign without RP-issued freshness, refuses to release a signature outside its RP scope, leaves no downstream-cacheable credential material, attests to its hardware at registration, and supports identity portability via re-enrolment-under-attestation rather than key portability. No shipping authenticator delivers all five of these authenticator-side properties in a workforce-grade product today; the two RP-side limits (revocation reachability, certificate-to-user mapping) are necessarily closed at the relying party, not the authenticator. The combination is the work of the next decade.

Limit	What it forbids	Primary source
Signing oracle, not transcript witness	Card cannot prove signature was for the intended protocol context	RFC 4556 / RFC 8070 [@rfc-4556] [@rfc-8070]
No RP identity	Card cannot refuse a relay; relay window must close in protocol	WebAuthn 2 [@webauthn-2]
No reach to downstream OS credentials	Card protects key, not identity around the key	KB 2871997, MSRC [@kb-2871997] [@msrc-kb-2871997]
Revocation is not self-asserting	Card cannot vouch for its own validity; KDC must reach the PKI	[MS-PKCA] [@ms-pkca]
Strong cert-to-user mapping is not card-asserted	Relying party must bind certificate to AD account; card has no view of the mapping	KB 5014754 [@kb-5014754]
Non-exportability bounds portability	Key dies with the chip; recovery must be re-enrolment	VSC Understanding [@vsc-understanding]

Some limits are being closed. The signing-oracle limit is mitigated by RFC 8070 freshness tokens; the RP-identity limit is closed for new credentials by WebAuthn; the downstream-credential limit is being closed by NTLM removal; the strong-mapping limit was closed by KB 5014754 on shipping AD infrastructure between February and September 2025. Others are inherent: a non-exportable key is, by definition, not portable. The next decade of smart-card-lineage work is being shaped by which is which.

9. Open Problems for the Next Decade

Five problems are still open in 2026. Each has a candidate fix in flight; none has shipped to general availability for the workforce case.

PIV / CAC in a post-NTLM Windows estate. NTLMv1 was removed from Windows 11 24H2 and Windows Server 2025 [@ntlmv1-removal]; NTLMv2 is on the deprecation track [@deprecated-features]. What does "smart card required for interactive logon" mean in a forest with no NTLMv1 secondary credential? The historical answer was "the KDC mints an NT hash so legacy services keep working." The new answer must be either "no NT hash; legacy services break" or "an NT hash for NTLMv2 only, restricted by SCRIL rotation and Protected Users membership." Microsoft has not yet published a complete blueprint for what federal PIV deployments look like after NTLMv2 also retires. Credential Guard's role in the transition is to make any residual secondary credential harder to harvest [@credential-guard] [@protected-users].

Three concrete questions a federal IT shop should be asking. First: does our forest have any domain controllers still serving NTLMv1 to legacy clients? After 24H2 / Server 2025, the answer should be no [@ntlmv1-removal]. Second: are our privileged accounts in Protected Users? The group blocks NTLM, DES, RC4 pre-auth, and constrained or unconstrained delegation [@protected-users]; for a smart-card-required account, membership effectively removes the RC4-HMAC-via-NTLM-hash attack surface even before NTLMv2 retirement. Third: is Credential Guard enabled on every member system? On Windows 11 22H2 and Server 2025, it is on by default for hardware-eligible domain-joined non-DC systems [@credential-guard]. These three measures are the practical answer to "what does smart-card-required mean today." The full structural answer waits on NTLMv2 retirement.

The recovery primitive that never shipped. TPM-clear or device replacement destroys TPM-bound keys; this is the cost of non-exportability. AIK-and-EK-cert attestation in tpmvscmgr could in principle support federated re-enrolment with strong proof of platform identity [@tpmvscmgr], and the Entra passkey enrolment flow supports attestation-required policies [@entra-passkeys-howto], but neither path matured into a "your VSC died; here is how the help desk restores you in fifteen seconds" story. Synced passkeys recover this property by giving up attestation. Workforce-grade attestation and easy recovery, together, is still not shipping.

The certificate-based-authentication hardening lag. Microsoft's KB 5014754 hardens certificate-based authentication on Windows domain controllers against the Certifried CVE class (CVE-2022-26923, CVE-2022-26931, CVE-2022-34691) by requiring strong certificate-to-user mapping at the KDC. The CVE class was disclosed on May 10, 2022. The mitigation moved DCs to Enforcement mode by default on February 11, 2025, with a fallback to Compatibility mode still available; the override was finally retired on September 9, 2025 [@kb-5014754]. The KB's own change log records several intermediate slips of the Full-Enforcement target (the original commitment was a 2023 milestone, slipping to February 2025 and then to September 2025) [@kb-5014754]. That is roughly three years from CVE disclosure to default Enforcement and a further seven months to end-of-override on shipping infrastructure -- and the gap from the first published Full-Enforcement target to the actual end-of-override stretches the slip to a multi-year story in its own right. The lesson is sobering: in a brownfield estate, the time from "CVE disclosed" to "hardening fully enforced on every domain controller" is measured in years, not weeks. Separately, RFC 8070 PKINIT freshness tokens (February 2017) are a different hardening programme [@rfc-8070]; Windows has not deployed RFC 8070 freshness as the default in the broad estate, and the article's RunnableCode in §10 illustrates the freshness exchange rather than documenting deployed Windows behaviour. Any protocol-level fix to the smart-card lineage in 2026 will, on the KB 5014754 evidence, take three to four years to land -- and longer if the standards process itself slips, as RFC 8070's still-undeployed status (over nine years since publication) suggests.

Cross-platform card-edge longevity. OpenSC and pcsc-lite still implement NIST SP 800-73 on macOS and Linux; the cross-platform PIV story works for basic logon. But the modern features Windows keeps adding -- attestation chains, device-bound credential extensions, integration with the Entra passkey APIs -- lag on the open-source side. Whether PC/SC outlives the platforms that built it is genuinely uncertain. Some federal organisations will keep PIV alive cross-platform as policy; many private-sector deployments will quietly move off.

Post-quantum signature algorithms on smart cards. PIV's current baseline is RSA-2048 and ECDSA P-256 -- not post-quantum resistant. NIST's post-quantum standardisation selected ML-DSA (Module Lattice DSA, formerly Dilithium) and SLH-DSA (Stateless Hash-Based DSA, formerly SPHINCS+); both have key and signature sizes substantially larger than RSA-2048 or ECDSA P-256, and both will stress the storage and bandwidth budgets of a typical PIV card. SP 800-73-4 has no slots for post-quantum keys today [@sp-800-73-4-upd1] [@fips-201-3]. A future revision will have to accommodate them, and the existing population of $\approx$ five million PIV cards [@nist-piv-home] will not all be PQ-capable at once. The transition runs on a card-issuance cycle: roughly $T_{\text{transition}} \approx T_{\text{issuance}} + T_{\text{rollout}}$, each term in the multi-year range.

Architecture is a question about which problems your design cannot solve. The next section is for the architect who has to choose right now, with all five problems still open.

10. Choosing Between PIV, VSC, WHfB, and FIDO2 in 2026

Four operator-grade callouts. Pick the one that matches your context.

Note: Stay on PIV / CAC for the foreseeable future. FIPS 201-3 is the current standard and SP 800-73 the current card-edge interface; policy mandates are not changing on a tactical timeline [@fips-201-3] [@nist-piv-home]. Add Entra Certificate-Based Authentication for cloud workloads so the same PIV card authenticates to Microsoft 365 and Azure resources without going through on-premises ADFS. For the three operational controls -- Credential Guard, Protected Users membership for privileged accounts, and NTLMv1-removal status -- see the federal-IT checklist in the §9 Aside. Do not rely on the smart card alone to defeat NTLM-secondary-credential abuse until NTLM removal has reached your environment.

Note: Pick WHfB key-trust if you are cloud-first or hybrid, cert-trust if you have an existing on-premises PKI you need to honour [@whfb-deploy] [@whfb-how-it-works]. Add FIDO2 security keys for the populations that need cross-device portability or strict phishing resistance: contractors, executives, IT administrators, anyone whose credential theft would be catastrophic [@webauthn-2] [@passwordless-strategy]. Do not pick Virtual Smart Cards for new deployments; the Microsoft Learn VSC Overview deprecation Warning quoted verbatim in §7 applies [@vsc-overview].

Note: Continue to operate it but plan migration to WHfB. Audit your recovery and re-enrolment process: a TPM clear destroys VSC keys irrecoverably, so any disaster-recovery plan that assumes you can move a credential between devices is wrong [@vsc-understanding]. Do not assume your VSC deployment is "supported" the way it was in 2014; the deprecation Warning quoted in §7 applies here [@vsc-overview]. The cleanest exit path is to enrol the same users into WHfB cert-trust against your existing PKI, then retire the VSC layer once the WHfB credential is operational.

Note: FIDO2 security keys with attested device-bound credentials [@webauthn-2] [@ctap-2-1], paired with Microsoft Entra ID passkeys. Use attestation-required profiles for high-assurance populations (so the relying party can verify the authenticator hardware) and attestation-optional profiles for less sensitive populations who benefit from synced-passkey recovery [@entra-passkeys-howto] [@entra-passwordless]. The trade-off remains: device-bound passkeys are attestable but not portable; synced passkeys are portable but not attestable. Match the profile to the population, not the population to the profile.

For the architect who wants to see how PKINIT freshness enforcement would work if the RFC 8070 extension were enforced, the JavaScript below simulates the nonce check. The KDC issues a freshness token; the client includes it in the signed PKAuthenticator; the KDC verifies that the token in the signed structure matches the one it issued. This is illustrative protocol behaviour, not the Windows default today.

{` function kdcIssueFreshness() { const token = Math.random().toString(16).slice(2, 18); return { token, issuedAt: Date.now() }; }

const issued = kdcIssueFreshness(); const cardSign = (msg) => 'sig(' + msg.length + ')'; const signed = clientSignAuthPack({ freshness: issued, cardSign });

console.log('Honest client:', kdcVerify(signed, issued));

const replayed = { ...signed, pkAuthenticator: { ...signed.pkAuthenticator, freshness: 'stale-token-1234' } }; console.log('Replayed with stale token:', kdcVerify(replayed, issued)); `}

Whichever method you choose, no method alone defeats the legacy compatibility surfaces the card was never designed to police. The structural fix lives in the protocol-removal programme finishing through 2026 and beyond.

11. Frequently Asked Questions

Yes functionally and cryptographically; no physically. A VSC exposes the same PC/SC card edge, Microsoft Smart Card KSP, and minidriver model as a physical card. Above the minidriver layer, every Windows component sees it as a smart card. Tamper-resistance comes from the host TPM rather than a removable IC; Microsoft Learn lists TPM 1.2 as the documented minimum -- VSCs predate TPM 2.0 [@vsc-overview] [@vsc-understanding]. No, by construction. The card signs internally and returns the signature. The only material that leaves during normal operation is the signed output (or, for key exchange, an unwrapped symmetric session key the card has decrypted with the wrapping key). The private key is generated on-card during enrolment and cannot be extracted; that property is the load-bearing security claim of the entire lineage. Legacy NTLM compatibility. Many pre-Windows-2000 services speak only NTLM, and accounts flagged "smart card required for interactive logon" must still authenticate to them. KB 2871997 (May 13, 2014) added auto-rotation of the secondary credential at logon, reducing but not eliminating the attack surface [@kb-2871997]. The structural fix is NTLM removal: NTLMv1 has now been removed in Windows 11 24H2 and Windows Server 2025 [@ntlmv1-removal]. Yes. The YubiKey 5 series exposes a PIV applet that the inbox `msclmd.dll` minidriver recognises out of the box [@yubico-piv] [@inbox-minidriver]. Insert the YubiKey and Windows treats it as a PIV-compliant smart card; the same enrolment, PKINIT, and lock-screen workflows apply. The YubiKey 5 can act as a FIDO2 authenticator concurrently, which is the practical way to bridge smart-card and origin-bound passkey workflows on the same device. Conditionally. PKINIT signs an `AuthPack` containing a nonce and a paChecksum; with the RFC 8070 freshness extension and a correctly validated KDC certificate, an attacker cannot trivially replay or relay an `AuthPack` signed by the client's smart card [@rfc-4556] [@rfc-8070]. But PKINIT is not origin-bound in the WebAuthn sense -- the card has no notion of which KDC the signature is for. If a trust assumption fails (an attacker plants a certificate in the client's NTAuth store, for example), the card will happily sign for the wrong KDC. WebAuthn's RP-ID-bound assertion is a stronger guarantee [@webauthn-2]. See the §6 Callout "VSCs predate TPM 2.0" for the full timeline. TPM 1.2 is the documented minimum; TPM 2.0 is the practical choice on Windows 11, which itself requires TPM 2.0 for the OS [@vsc-overview]. Three reasons, all expanded in §7: provisioning UX, TPM-clear recovery, and the multi-device world. Windows Hello for Business delivered the same TPM-bound-key benefits without the PC/SC abstraction cost (no virtual reader, no virtual minidriver, no APDU layer); FIDO2 then added cross-device portability and origin binding, neither of which the VSC architecture could deliver. The Microsoft Learn VSC Overview deprecation Warning quoted verbatim in §7 makes the recommendation explicit [@vsc-overview] [@passwordless-strategy]. Both are CNG Key Storage Providers. The Smart Card KSP routes calls through the minidriver to either a physical card or a TPM VSC; the cryptographic operation is APDU-encoded and sent to the card. The Platform Crypto Provider routes calls directly to the TPM via TPM Base Services; there is no card abstraction in the path. Windows Hello for Business uses the Platform Crypto Provider for TPM-bound key operations [@cng-ksp-list] [@whfb-how-it-works].

The card was always a metaphor. The cryptographic primitive at its centre -- a non-exportable asymmetric key, bound to a tamper-resistant element, gated by a local gesture -- is the longest-lived object in this lineage. Every generation transition (PC/SC -> CryptoAPI/CNG -> inbox PIV/GIDS -> Virtual Smart Card -> WHfB -> FIDO2) was a transition of the interface around that primitive, not of the primitive itself. The May 2014 contractor whose CAC signed the right blob and lost her account anyway was the canary; the fix she needed was not on her card but in a decade-long programme to remove the OS-minted secondary credentials that lived outside the card's authority. Windows is most of the way through that programme now. The card that wasn't a card outgrew its metaphor -- and the protection it always promised is, finally, arriving at the authentication outcome.

BitUnlocker: When Microsoft's Recovery Environment Becomes the Master Key

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

**In July 2025, Microsoft's own internal red team disclosed a four-CVE chain called BitUnlocker that bypasses TPM-only BitLocker in under five minutes from a USB stick, regardless of whether the device uses a discrete TPM, fTPM, or Pluton.** The attack works because the Windows Recovery Environment is given the BitLocker auto-unlock state legitimately during repair operations, and STORM found four parsers inside that trust boundary whose flaws let an attacker *be* the recovery environment. Patches shipped in KB5062553, but until the Secure Boot revocation infrastructure removes the pre-patch boot manager from the trust set, the chain remains exploitable on most fielded Windows 11 devices. The only mitigation that changes the threat model independently of patch state is the same recommendation Microsoft has been making since Vista: enable a pre-boot PIN.

1. Hold Shift, click Restart, lose your disk

Hold Shift. Click Restart. Plug in a USB stick carrying a pre-patch boot manager [@ms-winre-ref] [@garatc-poc]. Under five minutes later, on any device whose Secure Boot trust set still includes the 2011 root, the encrypted drive that protected your laptop is mounted in plaintext. No PIN ever entered. The TPM none the wiser. The researchers who showed how to do this work at Microsoft.

This is not a hypothetical. The proof of concept is on GitHub [@garatc-poc]. The end-to-end attack takes less than five minutes against a fully patched Windows 11 device that has not yet deployed the Secure Boot revocation infrastructure -- which is to say, most of them.

The attack is called BitUnlocker. It is a four-CVE chain disclosed and patched by Microsoft on July 8, 2025 in cumulative update KB5062553 [@kb5062553], then presented to the public a month later at Black Hat USA 2025 and DEF CON 33 with a Microsoft Security Blog write-up published August 13 to 14, 2025 [@ms-bitunlocker]. The four vulnerabilities are CVE-2025-48804 (System Deployment Image parsing) [@nvd-cve-2025-48804], CVE-2025-48800 (tttracer.exe offline scanning) [@nvd-cve-2025-48800], CVE-2025-48003 (SetupPlatform.exe and a Shift+F10 hotkey) [@nvd-cve-2025-48003], and CVE-2025-48818 (Boot Configuration Data target-OS impersonation) [@nvd-cve-2025-48818].

The researchers are Netanel Ben Simon and Alon Leviev of STORM, Microsoft's internal red team [@itnews-bitunlocker]. Leviev is the same researcher who disclosed Windows Downdate at Black Hat USA 2024 [@safebreach-downdate], so the line of work has provenance: a Microsoft engineer who understands the Windows update pipeline well enough to undo it, now turned on the recovery pipeline that runs when the update pipeline fails.

A five-minute physical bypass against BitLocker is not a research curiosity in 2026. ShrinkLocker, the BitLocker-as-ransomware-payload family disclosed by Kaspersky in May 2024, was used to extort organisations in Mexico, Indonesia, and Jordan [@kaspersky-shrinklocker]. APT41 paired ProxyLogon access with BitLocker as the workstation-encryption layer of a 2021 ransomware operation [@cymulate-apt41]. Romania's national water authority lost about 1,000 systems to a BitLocker-based ransomware incident over a December 2025 weekend [@therecord-romania-water]. BitLocker's installed base is where the defensive stakes live. BitUnlocker is what the offensive stakes look like.

STORM stands for Security Testing and Offensive Research at Microsoft [@itnews-bitunlocker]. It is the internal red team that publishes coordinated disclosures against Microsoft's own products.

The default BitLocker configuration on Windows 11 consumer and most enterprise installs. The Trusted Platform Module releases the Volume Master Key automatically at boot when the Platform Configuration Registers match an expected profile, with no human interaction. There is no pre-boot PIN, no startup key, no challenge -- the only authentication is the boot chain's measurement.

The pre-boot PIN configuration -- TPM+PIN, in Microsoft's terminology -- defeats every attack in this article, including BitUnlocker. Microsoft has been recommending TPM+PIN in some form since BitLocker shipped with Windows Vista on its January 30, 2007 consumer general-availability date [@ms-bitlocker-countermeasures] [@ms-vista-launch]. Eighteen years later, that recommendation has not changed.

What has changed is the consequence of ignoring it.

Key idea: TPM-only BitLocker assumes the boot chain is trustworthy. The boot chain has been the dominant BitLocker attack surface for three years and counting. The Windows Recovery Environment is part of the boot chain.

Note: The July 8, 2025 patches close the four code paths inside WinRE. They do not, by themselves, revoke the pre-patch boot manager that BitUnlocker downgrades to. Until the Secure Boot revocation under KB5025885 (the "REVISE" rollout) is deployed on a device, the BitUnlocker entry vector remains usable [@neodyme-bitpixie-no-fix] [@kb5025885].

To understand why a four-CVE chain inside the recovery environment is enough to mount the entire encrypted volume in plaintext, we have to go back to a design decision Microsoft made in 2006. That decision is still shipping in every copy of Windows.

2. Why the recovery environment has the keys

BitLocker shipped with Windows Vista on its consumer general-availability date, January 30, 2007 [@ms-bitlocker-countermeasures] [@ms-vista-launch]. Niels Ferguson's August 2006 cipher specification described the cryptographic core -- AES in CBC mode plus a custom diffuser called Elephant, designed to resist exactly the kind of disk-sector chosen-plaintext games that an attacker with full-disk read/write access could otherwise play [@ms-ferguson-cipher] [@archive-ferguson]. Four protector modes shipped with Vista: TPM-only, TPM+PIN, TPM plus a USB startup key, and TPM plus startup key plus PIN [@ms-bitlocker-countermeasures]. Each successive mode added a pre-boot human-presence check that the TPM-only default deliberately omitted.

The cipher specification is the public part of the design. The part that mattered for the rest of the story is the part that is barely documented at all: how recovery works.

The key-encrypting key that wraps the Full Volume Encryption Key. When a user changes their password or recovery configuration, only the VMK wrapping changes -- the entire volume does not need re-encryption. The TPM seals the VMK to a profile of boot-time measurements. The symmetric key that encrypts each sector of the BitLocker-protected volume. The FVEK is never directly handled by the user; it sits behind the VMK and is rewrapped only during operations like algorithm change or full re-encryption. A small bootable image, based on Windows PE, that the boot manager hands off to when normal Windows fails. WinRE provides Push Button Reset, Startup Repair, System Image Recovery, Reset This PC, and the offline scanning tools that the rest of this article will treat as a trust boundary [@ms-winre-ref].

The recovery problem Microsoft was solving in 2006 was unromantic but unavoidable. If full-disk encryption is to be default-on for an operating system that ships on a billion devices, the recovery environment has to read the OS volume during a repair pass without re-prompting the user for a recovery key every time a Windows update hiccups. The 24x7 help desk for a Fortune 500 cannot dispatch a forty-eight-character recovery key to every user whose system needs Startup Repair. So the Windows boot manager passes the unlock state along to WinRE, which inherits the ability to mount the encrypted volume during legitimate recovery operations [@ms-winre-ref].

The behavior is documented in every WinRE technical reference Microsoft has shipped since Vista. The rationale -- the original engineering memo about why auto-unlock is the right answer, given the help-desk requirement -- is not public. That gap matters because the rationale is the load-bearing wall of the threat model. The choice is consistent with every Microsoft document about WinRE; the engineering decision itself is folk knowledge.

The trade-off that runs through this entire article is simple to state. If the recovery environment can mount the volume without user input, the recovery environment is part of the encryption's trust boundary. If the recovery environment requires user authentication on every entry, you have effectively re-implemented the pre-boot PIN -- you have just moved its name. Microsoft picked the first option in 2006 because the second option breaks help-desk recoverability. Eighteen years later, that is still the choice. BitUnlocker is what the bill looks like.

Windows 8 removed the Elephant diffuser but kept AES-CBC alone. XTS-AES did not become BitLocker's default for new fixed drives until Windows 10 v1511 in November 2015 [@ms-bitlocker-configure]. The two-key VMK/FVEK hierarchy survived every cipher transition. So did WinRE's auto-unlock behavior.

Twenty months after Vista shipped, a Princeton research group would discover that "powered off" did not actually mean "key gone." The published attack literature against BitLocker was about to begin.

3. Eighteen years, six generations, one recommendation

The first attack specifically demonstrated against BitLocker as the named target appeared in 2008, the year after Vista's general availability -- though earlier generic memory primitives like FireWire DMA (Ruxcon 2006) became applicable to BitLocker as soon as Vista shipped. The most recent pre-2022 BitLocker bypass appeared in February 2024, when a four-dollar microcontroller pulled the keys off a Lenovo ThinkPad in 43 seconds [@hackaday-pico]. Between those two endpoints sit six attack generations. Each one moved one layer up the trust stack. Each one was answered by Microsoft with the same operational recommendation.

gantt title BitLocker bypass generations, 2006-2025 dateFormat YYYY-MM axisFormat %Y

section Hardware-adjacent
Cold boot (Halderman et al)        :2008-07, 60d
FireWire/PCI DMA (Boileau, Inception) :2006-10, 1825d
TPM bus sniff (marcan, Andzakovic)   :2019-01, 365d
Pi Pico TPM sniff (StackSmashing)    :2024-02, 30d
TPM+PIN bus bypass (SCRT, Compass)   :2024-02, 270d

section Software boot chain
Stoned, Vbootkit 2                   :2009-07, 90d
Self-Encrypting Deception (Meijer)   :2018-11, 180d
Bitpixie discovery (Rairii)          :2022-08, 30d
Bitpixie disclosure (CVE-2023-21563) :2023-02, 30d
BlackLotus (CVE-2022-21894)          :2023-03, 90d
BitUnlocker (KB5062553)              :2025-07, 60d

section Paradigms
Evil Maid framing (Rutkowska)        :2009-10, 30d

The structural reading of that timeline matters more than any individual entry, so here is the layer-by-layer walk:

Generation 1 -- Cold boot (2008). J. Alex Halderman and collaborators at Princeton and the EFF showed that DRAM retains its contents for seconds to minutes after power loss, longer if chilled with canned air. The AES key schedule has enough redundancy to be reconstructed from a partial dump, which means a powered-off BitLocker laptop with a still-warm DIMM is not actually at rest [@halderman-coldboot] [@halderman-coldboot-pdf]. Microsoft's structural answer was the Memory Overwrite Request (MOR) bit [@ms-bitlocker-countermeasures] and the eventual move to DDR generations that lose state faster. The user-facing answer was a pre-boot PIN [@ms-bitlocker-countermeasures].

Generation 2 -- FireWire and PCI DMA (2006 onward). Adam Boileau demonstrated at Ruxcon 2006 -- in a talk titled Hit By A Bus: Physical Access Attacks With Firewire -- that any host with an active FireWire port would let an unauthenticated peripheral read or write physical memory without involving the CPU [@boileau-ruxcon-2006]. Carsten Maartmann-Moe productionised the primitive as Inception, extending it to Thunderbolt, ExpressCard, and any other PCI-bus port that did not gate DMA behind the IOMMU [@inception-readme]. Microsoft's structural answer accumulated in stages: DMA-related Group Policy controls during the Windows 8.1 era, then a named Kernel DMA Protection feature shipped with Windows 10 1803 -- with the explicit exclusion that 1394 FireWire is not covered by KDP, so the legacy bus has to be disabled in firmware [@ms-kdp]. The user-facing answer was a pre-boot PIN.

Generation 3 -- Classical bootkits (2009). Peter Kleissner's Stoned and the Kumar brothers' Vbootkit 2, both presented at Black Hat USA 2009, showed that a Master Boot Record bootkit could load above the BitLocker pre-boot environment, hook the key-release path, and never trip the TPM's Platform Configuration Registers because nothing had measured the MBR yet [@wack0-taxonomy]. Microsoft's structural answer was UEFI Secure Boot plus Measured Boot's PCR 7, which moved the trust anchor from the MBR into the firmware. The user-facing answer was a pre-boot PIN.

Threat-model rename -- Evil Maid (2009). Joanna Rutkowska and Alex Tereshkin published a one-minute USB-stick infector against TrueCrypt that established a threat-model name rather than a primitive [@rutkowska-evilmaid]. Rutkowska's earlier January 2009 post had already named BitLocker as the disk encryption she missed after moving to macOS [@rutkowska-miss-bitlocker]; her October 2009 follow-up named the category of attacks that everybody now calls Evil Maid. The Microsoft Countermeasures page now uses the same threat-model tier she articulated.

Generation 4 -- Self-Encrypting Deception (2018-2019). Carlo Meijer and Bernard van Gastel showed at IEEE S&P 2019 that BitLocker had been silently delegating cryptography to the SSD firmware on self-encrypting drives -- and that the firmware was broken across several major vendor families, with Samsung 840/850 EVO and Samsung T3/T5 among the affected lines [@meijer-sed] [@researchr-meijer]. Microsoft's structural answer (KB4516071) was to stop delegating. This is the rare frontier Microsoft closed rather than mitigated incrementally: software encryption became the default again, and the "trust the drive" path was retired.

Generation 5 -- TPM bus sniffing (2019-2024). On a discrete TPM, the LPC or SPI bus between the CPU and the TPM chip carries the unsealed VMK in cleartext for a few microseconds. Hector Martin (marcan) first demonstrated extraction in January 2019 [@syss-tpm-sniffer]; Denis Andzakovic published the first written technical account later in 2019 [@andzakovic-tpmsniff] [@zdnet-bitlocker-attack] [@wack0-taxonomy]. StackSmashing's February 2024 Raspberry Pi Pico kit reproduced the same primitive against a Lenovo ThinkPad X1 Carbon for under ten dollars of hardware in 43 seconds of wall clock [@hackaday-pico] [@stacksmashing-pico]. Microsoft's structural answer was firmware TPM (AMD fTPM, Intel PTT) on modern CPUs and Pluton on Pluton-equipped chipsets [@ms-pluton]. The user-facing answer was a pre-boot PIN.

The Pi Pico reproduction reduced the hardware cost by an order of magnitude from Andzakovic's 2019 FPGA setup [@andzakovic-tpmsniff] [@hackaday-pico]. Same primitive; different price point.

Generation 5.5 -- TPM+PIN hardware bypass (2024). SCRT in Switzerland and Compass Security independently published that even with TPM+PIN configured, the Intermediate Key released after PIN validation still traverses the bus in clear on discrete-TPM hardware [@scrt-tpm-pin] [@compass-2024]. The structural defeat is Pluton, where the bus does not exist on-die [@ms-pluton]. The user-facing answer for everyone else stayed: a pre-boot PIN, plus discrete-TPM replacement or BIOS-level TPM bus protection.

By default, Microsoft BitLocker protected OS drives can be accessed by sniffing the LPC bus, retrieving the volume master key when it's returned by the TPM, and using the retrieved VMK to decrypt the protected drive. -- Denis Andzakovic, Pulse Security, 2019 [@andzakovic-tpmsniff]

Six generations. One recommendation. Pre-boot PIN. Microsoft has shipped real structural mitigations -- MOR, IOMMU, Secure Boot, Measured Boot, fTPM, Pluton, dbx revocation -- but the user-facing recommendation has not changed for eighteen years.

All six generations attack the layer below the boot manager. The boot manager itself, signed by Microsoft, has been treated as the trust anchor. In 2022, the first attack to make the boot manager itself the surface arrived. Its name was Bitpixie, and it is BitUnlocker's immediate ancestor.

4. The boot manager itself becomes the surface (2022-2025)

In August 2022, an independent researcher posting under the handle Rairii discovered that the Microsoft-signed Windows boot manager itself had a logic flaw: under a specific PXE soft-reboot sequence, the BitLocker Volume Master Key remained in physical memory and was never zeroed when control transferred [@rairii-mastodon] [@martanne-bitpixie]. The bug was assigned CVE-2023-21563. The patch shipped in the January 10, 2023 Patch Tuesday cumulative [@nvd-cve-2023-21563] [@msrc-cve-2023-21563]; Rairii made the discovery public on Mastodon the following month [@rairii-mastodon]. The old signed binary remained chain-loadable. It still is.

Thomas Lambertz of Neodyme published the canonical technical write-up of "Bitpixie" in late 2024, then presented the work at 38C3 in December 2024 [@neodyme-bitpixie] [@38c3-bitpixie]. His follow-up post asked an uncomfortable question -- why no fix? -- and answered it: the patch closed the code path, but the pre-patch boot manager was signed under Microsoft's Windows Production CA 2011, and that certificate was still in the Secure Boot allow-list (db) on most fielded Windows devices [@neodyme-bitpixie-no-fix]. A physically present attacker could supply an old, signed, vulnerable copy of bootmgfw.efi and the firmware would still load it.

This article uses "REVISE" as a convenience handle for Microsoft's verbosely-named "Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932" rollout. Microsoft does not market the work under the REVISE name -- the technical content here is what matters. The UEFI `db` is the allow-list of trusted signing certificates and signed binary hashes; the `dbx` is the corresponding deny-list. KB5025885's current (April 2024+) approach is certificate-based: it adds the Windows Production PCA 2011 signing certificate to `dbx`, which untrusts every boot manager signed by it, and ships a new UEFI CA 2023 certificate to replace the 2011 root. (The original May 2023 mitigations used a hash-by-hash strategy against specific boot manager binaries that was superseded for being too narrow.) The rollout is opt-in across multiple phases (currently five) because pushing a `dbx` change at scale can brick devices [@kb5025885]. Microsoft Windows Production CA 2011. The intermediate certificate that signs the Windows boot manager and every other Microsoft-trusted EFI binary loaded under Secure Boot. The 2011 root is set to expire in waves starting June 2026, which is the structural reason REVISE / UEFI CA 2023 must complete before then [@kb5062553].

The REVISE rollout under KB5025885 ships across opt-in phases (currently five: Initial Deployment, Second Deployment, Evaluation, Deployment, Enforcement), each gated by a registry-bitmask AvailableUpdates opt-in.Within the currently-active Evaluation and Deployment phases, the mitigations roll out in three actions: (1) install the new UEFI CA 2023 cert into db and trust-roll to the 2023-signed boot manager; (2) push the Windows Production PCA 2011 signing certificate into dbx -- the moment that "patched" becomes "revoked" on that device; (3) write a Secure Version Number into the firmware so the boot manager can self-revoke older copies of itself [@kb5025885]. The named Phase 1 (Initial Deployment, May 9, 2023) used a now-superseded hash-by-hash revocation approach against specific boot manager binaries. Each phase is an irreversible state change once Secure Boot stays on, which is why Microsoft has gated the schedule on operator readiness rather than calendar pressure.

Compass Security's May 2025 follow-up reproduced the Bitpixie exploit in a WinPE-based variant signed entirely by Microsoft components -- replacing the third-party Linux shim that secured-core PCs disable by default -- end-to-end in roughly five minutes via PXE [@compass-bitpixie-winpe]. Five minutes is a useful benchmark because BitUnlocker's USB-deliverable PoC clocks at the same number against the same chain-load downgrade primitive, with a different post-exploitation strategy and a different delivery vector.

Two other 2022-2024 bootkits frame the era. ESET disclosed BlackLotus in March 2023, the first in-the-wild UEFI bootkit observed bypassing Secure Boot on a fully patched Windows 11 by abusing CVE-2022-21894 "Baton Drop" [@eset-blacklotus] [@msrc-cve-2022-21894]. ESET's November 2024 Bootkitty disclosure brought the first publicly analysed UEFI bootkit aimed at Linux, although ESET's follow-up note clarified the artefact was a Korean Best of Best student project rather than in-the-wild malware [@eset-bootkitty]. Both used the same observation that underwrites Bitpixie and BitUnlocker: a Microsoft-signed binary with a logic flaw stays trusted until Microsoft adds it to dbx, which is a multi-year programme.

flowchart TD A["Microsoft-signed binary
with a logic flaw"] --> B["Stays trusted
until dbx revokes its cert
or its hash"] B --> C1["Bitpixie (CVE-2023-21563)
PXE soft-reboot leaks VMK
from physical memory"] B --> C2["BlackLotus (CVE-2022-21894)
Baton Drop drops a
UEFI bootkit"] B --> C3["BitUnlocker (4 CVEs)
Downgrade boot manager,
be the recovery environment"] C1 --> D["Patched is not revoked"] C2 --> D C3 --> D D --> E["REVISE / UEFI CA 2023
is the structural fix"]

Note: Each of Bitpixie, BlackLotus, and BitUnlocker depends on the same lemma. Microsoft can ship a patch that fixes a Microsoft-signed binary. Until that binary's signing certificate lands in dbx, the old signed copy keeps working on every Windows device whose Secure Boot policy still trusts PCA 2011 -- which, in mid-2026, is most of them. The dbx update is a separate, opt-in, multi-phase operation that has to complete before June 2026 because that is when PCA 2011 starts to expire on its own terms.

Same researcher, two pipelines: Leviev disclosed Windows Downdate at Black Hat USA 2024 and co-disclosed BitUnlocker at Black Hat USA 2025 [@safebreach-downdate]. Update pipeline one year, recovery pipeline the next.

Bitpixie scavenges the VMK from RAM after a buggy soft reboot. BlackLotus drops a UEFI bootkit. Both depend on the same observation: a Microsoft-signed binary with a logic flaw stays trusted until Microsoft revokes it. In July 2025, four Microsoft engineers asked a sharper question. What if you do not have to find a logic flaw at all? What if the recovery environment is given the keys legitimately, and all you have to do is be the recovery environment?

5. Four parsers, one trust boundary

WinRE already has the keys. That is the design.

STORM's insight was not to attack the seal. It was to observe that every parser inside WinRE sits inside the BitLocker auto-unlock trust boundary, and to ask which of those parsers is buggy. Once you reframe the problem from "find a way to make the TPM release the key" to "the recovery environment is given the key by design, so make me the recovery environment," the question stops being cryptographic and becomes a code-audit question. STORM found four answers. There are almost certainly more.

The four CVEs map to four parsers. The first is the entry vector; the next two are escalations inside the boundary; the fourth is the unconditional decryption finisher that turns the chain from a privileged shell into a permanently disabled BitLocker volume. Each subsection below follows the same template: what gets parsed, where the integrity check goes wrong, what falls out of the parser, why that primitive ends the chain.

sequenceDiagram participant U as Attacker (USB) participant FW as UEFI firmware participant BM as Pre-patch bootmgfw.efi (PCA 2011) participant SDI as Boot.sdi parser participant WRE as Malicious WinRE participant V as BitLocker volume U->>FW: Boot USB stick FW->>BM: Loads Microsoft-signed boot manager (downgraded) BM->>SDI: Hash-and-execute SDI image SDI-->>SDI: Hash covers original bytes SDI-->>SDI: Execution targets appended WIM SDI->>WRE: Hands control to malicious WinRE WRE->>V: Inherits auto-unlock from boot context WRE->>U: Shell on the cleartext volume

5.1 CVE-2025-48804 -- SDI parsing as the entry vector

WinRE boots from a System Deployment Image (Boot.sdi) bundled with a Windows Imaging file (.wim). The boot manager hashes the SDI for integrity before transferring control. STORM noticed that the integrity check covered the on-disk original bytes of the SDI, but the runtime that consumed the image followed an internal offset pointer that the attacker could shift to point at appended bytes after the hashed region [@nvd-cve-2025-48804] [@itnews-bitunlocker]. Append a malicious WIM at the tail of a legitimate SDI, manipulate the offset, and the hash still passes -- but execution targets your bytes.

The garatc proof of concept assembles this into a USB-bootable payload that downgrades to a pre-patch bootmgfw.efi signed under PCA 2011 (still trusted on most fielded devices), then parses an SDI of its own construction. Total prerequisites listed in the PoC README: physical access, TPM-only protector, PCR 7 plus PCR 11 trusted, and Microsoft Windows PCA 2011 in the Secure Boot db [@garatc-poc]. The wall clock for end-to-end exploitation: under five minutes.

{` // Schematic of the CVE-2025-48804 integrity-vs-execution split. // The hash covers the on-disk SDI bytes; execution follows an // offset pointer that the attacker can move past the hashed region.

const sdi = readFromDisk("Boot.sdi"); const hash = sha256(sdi); // integrity check sees ORIGINAL bytes if (hash !== expectedHash) throw "abort";

const offset = readOffsetFromHeader(sdi); // attacker-controlled in malicious SDI const wim = sdi.slice(offset); // points PAST the hashed region executeWim(wim); // runs appended malicious WIM

// Lesson: the hashed range and the executed range are not the same range. // The fix in KB5062553 binds them so that execution can only target // bytes that the integrity hash actually covered. `}

Once the malicious WinRE is running, it inherits the BitLocker auto-unlock state from the boot context. The encrypted volume is now mountable. The remaining three CVEs are about what an attacker can do from within WinRE that the original threat model did not expect WinRE to enable.

5.2 CVE-2025-48800 -- tttracer.exe as a proxy executor

WinRE's Offline Scanning operation invokes antivirus tooling from within the recovery environment. The set of trusted binaries WinRE will execute during scan is enumerated in ReAgent.xml -- WinRE's app-registry equivalent -- and includes Microsoft-signed diagnostic utilities. Among them is tttracer.exe, Microsoft's Time Travel Tracing debugger, included because it is occasionally invoked during diagnostics [@nvd-cve-2025-48800].

tttracer.exe is a proxy executor: by design, it launches an arbitrary process under tracing instrumentation. The LOLBAS project documents the exact invocation as tttracer.exe {PATH_ABSOLUTE:.exe}, mapped to MITRE ATT&CK technique T1127, with the launched process running as a child of tttracer.exe [@lolbas-tttracer]. Inside the WinRE auto-unlock boundary, with the live OS volume mounted, "arbitrary process" is the same primitive as "shell on the cleartext volume." Combine an attacker-controlled ReAgent.xml with tttracer.exe's proxy-execution semantics and Offline Scanning becomes Offline Pwning.

Time Travel Tracing is a Microsoft debugger most readers will not have seen named. It records process execution as a deterministic replayable trace and is a standard tool inside Microsoft's reliability engineering. Being on the WinRE trusted-app registry is a reasonable choice when the threat model is "diagnose a broken boot," not "an attacker is in the recovery environment."

5.3 CVE-2025-48003 -- SetupPlatform.exe and Shift+F10

SetupPlatform.exe, the Windows Setup host, remains on the WinRE trusted-app registry after upgrades and registers a Shift+F10 hotkey that opens cmd.exe. The Shift+F10 chord has been a long-standing Windows Setup feature for OEM imaging and unattended diagnostics, where it is harmless because there is no encrypted volume mounted yet [@nvd-cve-2025-48003] [@hackacademy-bitunlocker].

Inside WinRE, after auto-unlock has happened, Shift+F10 opens cmd.exe on the cleartext OS volume. STORM observed that manipulating the WinRE Apps Scheduled Operation entries in ReAgent.xml creates an unbounded trigger window -- the hotkey stays armed long enough for an attacker to use it. The shell that opens has the privileges of SetupPlatform under WinRE, with the OS volume mounted underneath it.

5.4 CVE-2025-48818 -- BCD target-OS impersonation

The first three CVEs assume the attacker has gotten WinRE to boot. The fourth one closes the loop and turns the access from a privileged shell on the volume into an unconditional, persistent decryption -- without any further interaction.

WinRE enumerates disk volumes in a specific order when deciding which Boot Configuration Data (BCD) store to consume as the description of the "operating system to recover." STORM placed an attacker-controlled BCD store on the recovery partition that gets enumerated before the legitimate one [@nvd-cve-2025-48818] [@hackacademy-bitunlocker]. WinRE treats the attacker volume as the trusted OS to recover, then invokes Push Button Reset with the DecryptVolume directive -- a legitimate sub-operation of PBR that disables BitLocker entirely. After Push Button Reset completes, BitLocker is not bypassed; it is off.

A legitimate WinRE sub-operation invoked during recovery when the target volume must be fully decrypted before being re-imaged or returned to a clean state. The directive removes the BitLocker protectors and rewrites every sector of the volume in plaintext. When invoked by a legitimately-recovered OS, this is correct behavior. When invoked by an impersonated target-OS BCD entry, it is a permanent encryption removal.

5.5 The structural pattern

flowchart TD subgraph WB["WinRE auto-unlock trust boundary"] WP["Boot.sdi parser"] RP["ReAgent.xml parser"] BP["BCD store enumerator"] TP["Trusted-app registry"] end C1["CVE-2025-48804
SDI offset confusion"] --> WP C2["CVE-2025-48800
tttracer.exe proxy"] --> RP C2 --> TP C3["CVE-2025-48003
SetupPlatform Shift+F10"] --> RP C3 --> TP C4["CVE-2025-48818
BCD impersonation"] --> BP WB --> VMK["BitLocker VMK released
to whatever runs inside"]

Four parsers; one boundary. The structural pattern reads:

Key idea: Every CVE attacks a different parser. Every parser sits inside the same auto-unlock trust boundary. Patching individual parsers does not close the boundary; it shrinks it. The boundary is the bug class.

Note: TPM bus sniffing fails against fTPM and Pluton because there is no exposed bus to sniff -- the seal is computed and released on-die. BitUnlocker does not attack the seal. The seal works exactly as designed: PCR 7 plus PCR 11 match the expected boot-chain measurements, and the TPM releases the VMK to the boot manager. The boot manager passes the unlock state into WinRE. WinRE then runs an attacker's code because one of its parsers had a bug. Nothing about fTPM or Pluton intervenes, because the entire attack is upstream of the silicon that the seal would protect.

Microsoft shipped patches for all four CVEs in KB5062553 on July 8, 2025 [@kb5062553]. The patches fixed the four code paths. They did not change the trust boundary. They did not, by themselves, even revoke the pre-patch boot manager that the chain depends on. To see what the July patches actually changed, and what they did not, we have to look at REVISE.

6. What KB5062553 changed, and what REVISE will

On the same Patch Tuesday that fixed BitUnlocker, Microsoft also reminded administrators that the Secure Boot certificate underwriting the entire Windows boot chain begins to expire in June 2026 [@kb5062553]. The two facts are not independent.

KB5062553 closed the four BitUnlocker code paths inside the Windows 11 24H2 build 26100.4652 cumulative. The SDI parser was bound so that the integrity hash and the execution range now agree. The trusted-app registry semantics for tttracer.exe and SetupPlatform.exe were tightened so neither acts as a proxy executor inside WinRE. The BCD enumeration order was reworked so the recovery partition cannot present a target-OS impersonator before the legitimate one. Those are real fixes for real bugs.

What KB5062553 did not change is the trust set. The pre-July-2025 bootmgfw.efi is still signed under PCA 2011, and PCA 2011 is still in the Secure Boot db on most fielded Windows devices. A physically present attacker can supply that old, signed, vulnerable boot manager from a USB stick. The firmware will load it. The four code paths are fixed in the new boot manager, but the old boot manager is still on the trust list. This is the same downgrade pattern that keeps Bitpixie exploitable [@neodyme-bitpixie-no-fix].

The structural defence is REVISE, shipped under KB5025885 and the CVE-2023-24932 advisory [@kb5025885]. REVISE adds the Windows Production PCA 2011 signing certificate to the Secure Boot dbx, which untrusts every boot manager signed by it, and ships a new UEFI CA 2023 certificate to replace the 2011 root. After REVISE deploys, the firmware refuses to load the pre-patch boot manager. The rollout is opt-in across multiple phases (currently five) because a dbx update at fleet scale carries real brick risk: any device that ends up trying to boot a binary whose signing certificate has just been moved to the deny-list will not boot. KB5025885 explicitly warns that once the mitigation is enabled on a device, it cannot be reverted while Secure Boot remains on.

This lemma appears in three places already in this article -- Bitpixie, BlackLotus, and BitUnlocker -- and it is worth stating once explicitly.

A Microsoft-signed binary stays in the trust set as long as its signing certificate is in db and neither its hash nor its signing certificate sits in dbx. Microsoft can ship a code-path patch that supersedes the old binary, but nothing in the trust set changes automatically. The dbx push is a separate operation, gated on a separate update, with its own opt-in semantics because pushing a wrong dbx value bricks devices.

The result is that "the bug is patched in the latest cumulative" and "an attacker with physical presence can no longer load the vulnerable signed binary" are not the same statement. The first is true after KB5062553. The second is true only after REVISE, only on devices where REVISE's dbx-revocation phase has run -- the phase that moves the PCA 2011 signing certificate into dbx so the deny-list overrides the allow-list. The June 2026 PCA 2011 expiration is the natural backstop -- after that date, the certificate no longer signs anything new, and the migration completes on its own timetable.

Until then, BitUnlocker's entry vector remains usable on every TPM-only device whose REVISE phase has not advanced.

flowchart LR A["Pre-July-2025 bootmgfw.efi
(PCA 2011 signed)"] --> B["KB5062553 patches
the four CVEs in the NEW
boot manager"] A --> C["REVISE adds PCA 2011
signing cert to dbx"] B --> D["New devices: closed code paths"] C --> E["Firmware refuses to load
the vulnerable signed binary"] D --> F["BitUnlocker fixed on patched device"] E --> G["BitUnlocker entry vector blocked
across the fleet"]

Note: PCA 2011 begins to expire in waves starting June 2026 [@kb5062553]. The UEFI CA 2023 migration must complete before then. Administrators of devices that have not yet reached REVISE's dbx-revocation phase should treat the June 2026 date as a hard deadline, not a goal: any device that misses the migration risks losing Secure Boot trust entirely on its next firmware update.

Patches close code paths. REVISE closes trust. Neither closes the WinRE auto-unlock surface itself. That is a different question, and the comparison Microsoft never likes to make is what other desktop operating systems chose to do about it.

7. How other platforms make the same trade-off

Windows is the only major desktop operating system that ships an auto-unlocking recovery environment on a TPM-sealed key. The other three -- macOS, ChromeOS, and Linux with LUKS -- make different choices at the same trade-off point. Looking at those choices shows what is actually possible.

Platform	Recovery primitive	Key availability during recovery	Auto-unlock from physical-presence path	Failure mode if compromised
Windows + BitLocker + WinRE	Push Button Reset, Startup Repair, Reset This PC	VMK released by TPM, inherited by WinRE	Yes -- Shift+Restart -> recovery menu	BitUnlocker class: parser bugs leak the cleartext volume to attacker code running inside WinRE
macOS + FileVault + macOS Recovery	macOS Recovery (boot to recovery partition)	Data Volume NOT mounted; user password or recovery key required	No	Recovery cannot read user data without authentication
ChromeOS + Verified Boot + Powerwash	Recovery USB / `chrome://recovery`	None -- recovery wipes user data	No	Recovery destroys the protected data set
Linux + LUKS / dm-crypt	initramfs / rescue shell	None -- every boot prompts for passphrase	No	Recovery cannot proceed without passphrase

Windows + BitLocker + WinRE is the only row in that table where the recovery environment can read user data without re-prompting the user. BitUnlocker is what the trade-off looks like once that property gets weaponised.

macOS chose a different recovery model. FileVault encrypts the Data Volume; the signed System Volume Snapshot does not. macOS Recovery boots into the signed system volume and presents a Disk Utility view of the Data Volume that requires a user password or recovery key to mount. The recovery environment is not given the keys. A macOS-side analogue of CVE-2025-48804 would still need to coerce Recovery into surfacing authentication UI -- the recovery primitive does not run with the user volume already mounted.

ChromeOS chose the most aggressive recovery model. Verified Boot enforces signature chains all the way to the kernel; recovery from a corrupted state means powerwash, which wipes the user partition. There is no equivalent of WinRE that needs to read the encrypted volume. The trade-off is enforced by sacrificing the data, which is acceptable because user data on ChromeOS is mostly remote.

LUKS / dm-crypt is the simplest model. Every boot, including recovery, prompts for the passphrase. There is no auto-unlock state to inherit. The trade-off is help-desk burden: a forgotten passphrase is a wiped drive. This is the model that the Microsoft Countermeasures page implicitly recommends for the "skilled attacker with lengthy physical access" threat tier when it suggests TPM+PIN [@ms-bitlocker-countermeasures].

Windows defines recovery as *transparent repair*. macOS defines it as *authenticated rebuild*. ChromeOS defines it as *wipe and restart*. LUKS defines it as *the same authentication you would do on a normal boot*. Each is internally consistent with the rest of its security model. None of them is wrong in isolation. They differ in what trade-off they make between fleet recoverability and recovery-environment exposure -- and BitUnlocker is what the most-usable-recovery choice costs.

Recovery-key escrow to Microsoft Entra ID, Active Directory, or a local user account is a separate confidentiality boundary from the BitUnlocker surface. Forbes reported in January 2026 on a Guam FBI warrant served to Microsoft for BitLocker recovery keys, illustrating the legal-process pathway [@forbes-guam-bitlocker]. Different threat surface; same product.

The trade-off Microsoft made in 2006 was the right one for a fleet that needs help-desk recoverability and the wrong one for a threat model with physical access. Eighteen years and seven attack generations later, the trade-off has not been revisited. The next section asks whether it can be.

8. Why patching cannot close the surface

In complexity theory, an impossibility result tells you what cannot be done no matter how hard you try. BitUnlocker is not that kind of result. It is the next thing over: a structural consequence of the threat model that no quantity of parser patches can close.

State the recovery-versus-confidentiality dilemma carefully. As long as a system auto-unlocks an encrypted volume for repair purposes without user-presence verification at the moment of recovery, the recovery environment's trust boundary equals the encryption's trust boundary. This is not a theorem in the published literature. It is the structural reading of the Microsoft Countermeasures threat-model tiers [@ms-bitlocker-countermeasures], and it follows almost mechanically from how the WinRE auto-unlock state is inherited.

The dilemma admits exactly two engineering exits. The first is to deprecate WinRE auto-unlock and require a recovery key for every WinRE entry. Microsoft has not done this and will not do this, because the help-desk recoverability story collapses without it -- fleet administrators rely on WinRE entry being silent for routine repair. The second is to make TPM+PIN the default for non-Entra-enrolled devices, which forces a pre-boot human-presence check that WinRE structurally cannot satisfy. Microsoft has not done this either, presumably because of the help-desk cost of forgotten PINs at consumer scale.

Until one of those two changes, the next BitUnlocker is a question of when, not whether. The four CVEs are an existence proof for the bug class "Microsoft-signed binary on the WinRE trusted-app registry whose parsing of unsigned configuration data can be coerced." The cardinality of that bug class is not four. STORM found four. There are more.

Key idea: As long as a system auto-unlocks an encrypted volume for repair purposes without user-presence verification at the moment of recovery, the recovery environment's trust boundary equals the encryption's trust boundary. The bug class is not the parsers. The bug class is the boundary that contains them.

Note: You cannot have unattended recovery and confidentiality at the same time against an attacker with physical presence. Every desktop operating system that has tried has either added authentication to recovery (macOS) or has been broken at recovery (BitUnlocker, multiple times). The choice is a product decision, not a software bug.

Microsoft is not unaware of this. Quick Machine Recovery -- the cloud-orchestrated recovery primitive that reached general availability in 2025 -- extends the WinRE-equivalent surface rather than retracting it [@ms-qmr]. The trade-off pricing is ongoing. So is the audit.

The next section is the question that follows from the boundary framing: what else is inside the boundary that STORM did not get to?

9. What STORM did not audit

STORM published four CVEs. The Windows Recovery Environment contains more than four parsers.

Four open questions follow directly from the boundary framing:

The remaining WinRE trusted-app surface. STORM exploited tttracer.exe and SetupPlatform.exe. The WinRE Apps Scheduled Operation in ReAgent.xml registers other Microsoft-signed binaries. None of those binaries was written under the assumption that an attacker would be the one calling them with the OS volume mounted. How many similar inheritances remain unaudited is unknown, and the population is the unstated denominator of every subsequent BitUnlocker-class CVE.

PCA 2011 trust on most fielded devices. Until REVISE deploys at fleet scale, the pre-July-2025 bootmgfw.efi remains chain-loadable on any device that still trusts PCA 2011. The June 2026 PCA 2011 expiration is the structural milestone [@kb5062553]. Between mid-2025 and mid-2026, the BitUnlocker entry vector is a deployment question, not a code question.

Quick Machine Recovery extending the WinRE-equivalent surface. Cloud-orchestrated recovery on encrypted volumes occupies the same trust boundary as WinRE -- by design, since the point of QMR is to do silent fleet repair on devices that cannot reach a desk [@ms-qmr]. No published security audit comparable to STORM's BitUnlocker work has appeared for QMR. The next BitUnlocker-shaped CVE may live there.

Pluton hardware bypass. No published practical hardware attack on Pluton exists in the open literature as of mid-2026. The SCRT/Compass-class TPM+PIN bypasses are limited to discrete-TPM hardware where the bus between CPU and TPM is exposed [@scrt-tpm-pin] [@compass-2024] [@ms-pluton]. Whether Pluton admits decapping, laser-fault-injection, or microarchitectural side-channel attacks is an open question that nobody outside Microsoft and a handful of three-letter agencies has the budget to answer at scale.

Quick Machine Recovery's 2025 general availability puts it inside the BitUnlocker disclosure timeline [@ms-qmr]. Microsoft is expanding the WinRE-equivalent attack surface in the same calendar year that STORM is publishing the four CVEs.

And one orthogonal question that every BitLocker survey is asked: who has the recovery key? A serious defender has to think about the recovery-key escrow surface too -- see below.

Note: Cloud escrow of the BitLocker recovery key is a confidentiality surface that BitUnlocker does not touch. BitUnlocker is a parser-level chain that gives a physically-present attacker the cleartext volume without ever needing the recovery key. The keyholder question is orthogonal. Both surfaces exist; both are worth thinking about; neither closes the other.

The open-problems list above is what is unaudited as of mid-2026. The actionable question -- what do I, as an administrator, do tomorrow? -- is the subject of the next section.

10. Six things defenders should do this week

If you administer a Windows fleet, six concrete actions change the threat model. They are listed here in priority order, not severity order. The first one is the structural mitigation; the others are patch hygiene around it.

1. Enable TPM+PIN. The PowerShell-equivalent invocation is manage-bde -protectors -add C: -tpmandpin [@ms-manage-bde]. This is the only mitigation that changes the threat model independently of patch state -- it forces a pre-boot human-presence check that WinRE structurally cannot satisfy. The honest trade-off: users forget PINs and help-desk burden goes up. The honest counterpoint: the recommendation has been in the Microsoft Countermeasures page in some form since Vista, and BitUnlocker is what eighteen years of ignoring it has produced [@ms-bitlocker-countermeasures].

Note: manage-bde -protectors -add C: -tpmandpin -- one PowerShell command, one PIN per user, one threat model permanently changed. This defeats Bitpixie, BitUnlocker, and any future BitUnlocker-class attack that lives upstream of the TPM seal. It does not defeat hardware TPM+PIN bus-sniff attacks on discrete TPMs [@scrt-tpm-pin] [@compass-2024], which are a separate class.

2. Apply KB5062553 or any later cumulative. The July 8, 2025 cumulative closes the four BitUnlocker code paths [@kb5062553]. By the time you read this, several later cumulatives have shipped; deploy the latest. This addresses the post-entry portion of the chain but not the entry vector.

3. Deploy REVISE / migrate Secure Boot to UEFI CA 2023. This is the dbx-side defence that revokes the pre-patch bootmgfw.efi [@kb5025885]. Until REVISE has run on a device, "patched" is not "revoked." The deployment is opt-in across multiple phases (currently five) because a bad dbx push at scale bricks devices; the June 2026 PCA 2011 expiration is the hard deadline.

4. Restrict WinRE access where the threat model permits. On kiosks, lab machines, lights-out servers, and other devices where there is no fleet-recovery requirement, reagentc /disable closes the WinRE entry surface entirely. This costs you Push Button Reset and Startup Repair on those devices, which is acceptable for devices that are re-imaged centrally [@hackacademy-bitunlocker].

5. Harden the firmware delivery surface. Enable Secure Boot, set a firmware password, disable USB and PXE boot in firmware on devices that are not expected to be re-imaged in the field [@hackacademy-bitunlocker]. This closes the delivery vector independently of the WinRE patch state. It does nothing against an attacker who can boot from internal disk, which is why this is one of six items rather than the first one.

6. Surface BitLocker protection state in management telemetry. Intune, Microsoft Defender for Endpoint, and Entra ID can all report on whether a device has a TPM-only or TPM+PIN protector and whether the CVE-2023-24932 dbx revocation has applied (the per-device Secure Boot dbx update status field surfaced in Intune / Defender for Endpoint). Make those fields first-class in your fleet dashboards. PIN-on / PIN-off and dbx-revoked / not-revoked should both be visible at the fleet level, not buried inside a per-device drill-down.

{` // Logical equivalent of: manage-bde -protectors -get C: // Run this against the parsed output to confirm the // device is using TPM+PIN rather than TPM-only.

function classifyProtectors(protectorTypes) { const hasPIN = protectorTypes.includes('TpmPin') || protectorTypes.includes('TpmPinStartupKey'); const hasTPM = protectorTypes.some((t) => t.startsWith('Tpm')); if (!hasTPM) return 'NoTPM -- not in scope of BitUnlocker'; if (hasPIN) return 'TPM+PIN -- defeats BitUnlocker entry vector'; return 'TPM-only -- vulnerable to BitUnlocker entry vector'; }

// Example: the default Windows 11 consumer configuration console.log(classifyProtectors(['Tpm', 'RecoveryPassword'])); // -> "TPM-only -- vulnerable to BitUnlocker entry vector" `}

If you genuinely cannot deploy TPM+PIN (kiosks running unattended, OT workloads, accessibility-driven exemptions), the partial mitigation stack is REVISE's dbx-revocation phase + firmware password + USB/PXE disabled in firmware + Kernel DMA Protection. Together these close the BitUnlocker entry vector on the patched code paths *and* the downgrade path *and* the firmware delivery channel. None of them changes the WinRE auto-unlock boundary -- only TPM+PIN does that -- so the next BitUnlocker-class CVE may still be exploitable on these devices until the corresponding patch ships. Treat this stack as a temporary mitigation, not a permanent answer.

None of these are new recommendations. The pre-boot PIN line in particular has been in the Microsoft Countermeasures page in some form since Vista [@ms-bitlocker-countermeasures]. What has changed is the operational consequence of not following it. BitUnlocker is what the consequence looks like today.

11. Frequently asked questions

BitUnlocker has produced a predictable list of misconceptions. Each question below names a common misconception about BitUnlocker and gives the correct framing -- because the wrong answers are where threat models get built quietly.

Yes against both -- the attack is upstream of the TPM seal, so the bus-elimination property of fTPM and Pluton does not help here. See §5.5 for the full mechanism and the contrast with TPM bus sniffing, which *does* fail against fTPM and Pluton because there is no exposed bus to sniff. No. BitUnlocker was *patched* on July 8, 2025 in KB5062553 [@kb5062553]. It was *disclosed* at Black Hat USA 2025 and DEF CON 33 in early August 2025, with the Microsoft Security Blog write-up published August 13 to 14, 2025 [@ms-bitunlocker]. Coordinated disclosure timelines mean the patch ships before the talk. Useful date to remember: KB5062553 = fix, August 2025 = public technical detail. Only against an attacker who cannot chain-load the pre-July-2025 `bootmgfw.efi`. Until REVISE / KB5025885 is deployed on a given device, the old signed boot manager remains trusted [@kb5025885] and the BitUnlocker entry vector remains usable from a USB stick. The patch closes the code paths in the new boot manager; the dbx update closes the old one's trust. They are different operations on different schedules. Yes against the BitUnlocker CVE class. A pre-boot PIN forces a human-presence check that WinRE structurally cannot satisfy from a boot-time recovery context. The Compass Security and SCRT TPM+PIN bypasses [@compass-2024] [@scrt-tpm-pin] are a separate, hardware-physical class that targets the bus between CPU and discrete TPM; they do not apply to fTPM or Pluton. For a TPM+PIN on Pluton or fTPM, none of the published attacks in this article succeed. No. The chain uses Microsoft-signed binaries throughout. The pre-patch `bootmgfw.efi` is Microsoft-signed under PCA 2011. `tttracer.exe`, `SetupPlatform.exe`, and the WinRE binaries inside the trust boundary are all Microsoft-signed. The bug class is logic flaws in the parsing of *unsigned data* (Boot.sdi, ReAgent.xml, BCD) by signed binaries. Secure Boot is doing exactly what it is designed to do; the boundary it enforces is not the boundary BitUnlocker crosses. No. Bitpixie scavenges the VMK from RAM via a soft-reboot bug in the pre-patch `bootmgfw.efi` (CVE-2023-21563, discovered August 2022 by Rairii, disclosed February 2023) [@neodyme-bitpixie]. BitUnlocker boots a malicious WinRE that inherits auto-unlock on the live volume. The shared structural pattern is that both are upstream of the TPM seal, both are defeated by TPM+PIN, and both work against fTPM and Pluton. The mechanism is different; the lesson is identical. STORM is the *Security Testing and Offensive Research at Microsoft* team -- Microsoft's internal red team. Alon Leviev, one of the BitUnlocker co-authors, also disclosed Windows Downdate at Black Hat USA 2024 [@safebreach-downdate]. The Downdate research showed that the Windows update pipeline could be coerced into installing older, vulnerable code paths. BitUnlocker is a different mechanism by the same researcher, one year later, on the recovery pipeline rather than the update pipeline.

The Shift+Restart chord ships in every copy of Windows. The recommendation that defeats it -- enable a pre-boot PIN -- has been on the Microsoft Countermeasures page since Vista. STORM's contribution is not that they found four bugs. It is that they made what happens when the recommendation is ignored impossible to look away from. The next move is the reader's.

To defend against malicious reset attacks, BitLocker uses the TCG Reset Attack Mitigation, also known as MOR bit. -- Microsoft Learn, BitLocker Countermeasures [@ms-bitlocker-countermeasures]

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

CNG Architecture: BCrypt, NCrypt, KSPs, and How Windows Picks Its Algorithms

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

Since Windows Vista, every piece of cryptography in Windows -- TLS, BitLocker, Authenticode, Windows Hello, DPAPI -- flows through the **Cryptography API: Next Generation (CNG)**. CNG splits the world into two layers. **BCrypt** does primitives: AES, SHA, HMAC, RNG, key derivation. **NCrypt** routes calls to a **Key Storage Provider (KSP)** that owns the long-lived private keys: software, TPM, smart card, or a third-party HSM. Algorithm selection is governed by a registered provider-priority list, the Schannel cipher-suite order, and a single FIPS-mode toggle that flips Windows into its validated subset. Windows 11 24H2 added the first post-quantum primitives (ML-KEM, ML-DSA) to the same surface, with no API break. This article walks through how that machine works, why Microsoft designed it that way, and where it leaks.

1. From CAPI to CNG: why Microsoft started over

In the late 1990s, Microsoft shipped its first general cryptographic API. The original Cryptographic Service Providers (CAPI) model [@learn-microsoft-com-service-providers] arrived in Windows NT 4.0 Service Pack 4 in 1998 and defined a plug-in unit called a Cryptographic Service Provider, or CSP. A CSP was a monolithic DLL: it owned the algorithm implementations, the key storage, and the export-control posture all at once. If you wanted to add hardware-backed RSA on Windows NT, you wrote a CSP. If you wanted to add a new hash function, you also wrote a CSP. The model worked for the algorithms Microsoft had in mind when it designed it.

Then the algorithms changed.

AES was standardized in 2001, after CAPI's design was already frozen. Microsoft retrofitted AES into the original architecture by shipping the Microsoft Enhanced RSA and AES Cryptographic Provider [@learn-microsoft-com-cryptographic-provider] as a separate CSP, sitting alongside the original Microsoft Base Cryptographic Provider. Elliptic-curve cryptography was even more awkward: CAPI's algorithm identifiers and key-blob formats had no place for ECC curves. Every new algorithm required a new CSP or a new release of an existing one. The plug-in surface was rigid, the FIPS validation story was painful, and the API was relentlessly C-shaped in ways that made auditing hard.Microsoft was not alone. The same era produced Intel's Common Data Security Architecture (CDSA) [@en-wikipedia-org-os-2] and several short-lived crypto frameworks for OS/2 and other platforms. Most of them disappeared. CAPI's longevity owed more to Windows market share than to its design.

By 2005, Microsoft started over. The result was the Cryptography API: Next Generation, or CNG, which shipped with Windows Vista and Windows Server 2008 in January 2007 [@learn-microsoft-com-cng-portal]. CNG was not a refactor. It was a clean second system, designed from a different set of assumptions: algorithms would keep arriving, key storage needed to be a separate concern, FIPS validation had to be a first-class output, and the same API had to work in user mode and kernel mode.

The Windows cryptographic API introduced in Vista (2007) as the long-term replacement for CAPI. CNG splits cryptography into a primitives layer (`bcrypt.h`, `bcryptprimitives.dll`) and a key-storage layer (`ncrypt.h`, `ncrypt.dll`), each pluggable through registered providers. Used by every modern Windows component that touches cryptography. The plug-in unit of the legacy CAPI architecture (1998-onward). A CSP bundled algorithms, key storage, and FIPS posture into a single DLL. Largely superseded by CNG providers, but still present on the system for backwards compatibility.

The three design pillars Microsoft committed to in the CNG portal documentation were modularity, cryptographic agility, and FIPS-compliance readiness [@learn-microsoft-com-cng-features]. All three would matter twenty years later when post-quantum cryptography arrived without warning the protocol authors. We will get to that.

Throughout this article, "BCrypt" refers to Microsoft's CNG primitives header `bcrypt.h` and its companion DLL `bcryptprimitives.dll`. It is not the Provos-Mazieres password-hashing function of the same name, which is unrelated and uses a different spelling in most academic literature ("bcrypt"). The naming collision is unfortunate but firmly entrenched in Windows.

2. BCrypt: the symmetric stack and the ephemeral key

Open a Visual Studio project, include <bcrypt.h>, link bcrypt.lib, and you have access to almost every cryptographic primitive Windows ships. AES in CBC, CFB, ECB, GCM, and CCM modes. SHA-1, SHA-256, SHA-384, SHA-512, the SHA-3 family, and the cSHAKE128 and cSHAKE256 extendable-output functions added in Windows 11 24H2 [@learn-microsoft-com-algorithm-identifiers]. HMAC over any of those hashes. PBKDF2. The NIST SP 800-108 key-derivation construction. The DRBG-based random number generator drawn from NIST SP 800-90 [@csrc-nist-gov-1-final]. Ephemeral asymmetric operations -- RSA encrypt, ECDSA sign, ECDH key agreement -- on key handles that vanish when the process exits.

The canonical BCrypt opening dance is four calls.

{` // Pseudocode mirroring the BCryptOpenAlgorithmProvider flow. // In real C: NTSTATUS values, BCRYPT_ALG_HANDLE, etc.

const algId = "AES"; // wide string const impl = null; // null -> walk the priority list const flags = 0;

const hAlg = BCryptOpenAlgorithmProvider(algId, impl, flags); BCryptSetProperty(hAlg, "ChainingMode", "ChainingModeGCM");

const hKey = BCryptGenerateSymmetricKey(hAlg, keyBytes); const ciphertext = BCryptEncrypt(hKey, plaintext, authInfo);

BCryptDestroyKey(hKey); BCryptCloseAlgorithmProvider(hAlg, 0); `}

The interesting parameter is impl. When it is NULL, BCryptOpenAlgorithmProvider "attempts to open each registered provider, in order of priority, for the algorithm specified by the pszAlgId parameter and returns the handle of the first provider that is successfully opened" [@learn-microsoft-com-bcrypt-bcryptopenalgorithmprovider]. That sentence is the whole story of CNG provider priority in nineteen words.

Algorithm identifiers are wide strings. L"AES", L"SHA256", L"RSA", L"ML-KEM", L"ML-DSA", L"CHACHA20_POLY1305", L"CSHAKE128". Each string is registered in CNG's configuration store under HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\, with a per-algorithm ordered list of providers that claim to implement it. Add a new algorithm and you add a new string. Add a new provider and you append to its priority list. The API surface does not change.

Note: The algorithm-identifier string is the seam where cryptographic agility lives. As long as your protocol can encode "use whatever the spec calls AES-256-GCM," and as long as a CNG provider answers to that name, you can swap implementations without touching the calling code. Protocols whose wire format hard-codes the algorithm (the old SSL 3.0 cipher list, for example) do not get this benefit no matter what crypto API they call.

Underneath the API is a single implementation library. Microsoft's SymCrypt [@github-com-microsoft-symcrypt] has been the actual workhorse since Windows 10 version 1703: "SymCrypt is the core cryptographic function library currently used by Windows... Since the 1703 release of Windows 10, SymCrypt has been the primary crypto library for all algorithms in Windows." SymCrypt is open source. It carries hand-tuned assembly for AES-NI, VAES, SHA-NI, and PCLMULQDQ on x64, plus ARM64 SHA and AES intrinsics. On a modern Xeon, AES-GCM throughput from BCrypt routinely sits in the 4 to 8 GB/s range per core.

SymCrypt's open-source release in 2019 was a quiet event for a Microsoft library: the algorithms that protect Windows are reviewable by anyone willing to read C and ARM/x64 assembly.

BCrypt keys are ephemeral by construction. A BCRYPT_KEY_HANDLE lives in your process and dies with it. If you want to keep a private key around between processes, between reboots, or between machines, you do not use BCrypt. You use NCrypt.

That distinction is the first thing developers get wrong when they meet CNG. The second thing they get wrong is forgetting that BCrypt's GCM API does not allocate nonces for you. The NIST SP 800-38D specification of Galois/Counter Mode [@nvlpubs-nist-gov-nistspecialpublication800-38dpdf] is famously brittle under nonce reuse: a single repeated nonce under the same key destroys both confidentiality (XOR of plaintexts leaks) and authenticity (the GHASH authentication key becomes recoverable). With 96-bit random nonces the birthday bound limits safe usage to roughly $2^{32}$ invocations per key before collision probability becomes meaningful. Counter-based nonces sidestep the birthday bound entirely but require persistent state. CNG does neither for you. That part is your problem.

Note: First, GCM nonce reuse: BCryptEncrypt with BCRYPT_CHAIN_MODE_GCM accepts whatever 12 bytes you hand it. Counter or random, but never twice. Second, algorithm string drift: BCRYPT_SHA256_ALGORITHM is the macro for L"SHA256". L"SHA-256" returns STATUS_NOT_FOUND. Third, kernel-mode pseudo-handles: the convenient BCRYPT_AES_ALG_HANDLE shortcut is user-mode only per the BCryptOpenAlgorithmProvider remarks [@learn-microsoft-com-bcrypt-bcryptopenalgorithmprovider]; kernel drivers must use real handles.

Windows 10 added pseudo-handles -- pre-baked handle constants like BCRYPT_AES_ALG_HANDLE and BCRYPT_SHA256_ALG_HANDLE -- that skip the provider lookup for the built-in algorithms. The 24H2 release extended that list to include BCRYPT_MLKEM_ALG_HANDLE and the cSHAKE handles. Microsoft now recommends pseudo-handles over BCryptOpenAlgorithmProvider for new code [@learn-microsoft-com-bcrypt-bcryptopenalgorithmprovider] when the algorithm is built in. The motivation is performance: pseudo-handles bypass the per-call provider walk and the configuration-store lookup.

That covers the primitives. Now we need a place to keep the keys.

3. NCrypt: where the long-lived secrets live

The ncrypt.h header opens a different door. Every function in the NCrypt API surface [@learn-microsoft-com-api-ncrypt] -- NCryptOpenStorageProvider, NCryptCreatePersistedKey, NCryptOpenKey, NCryptSignHash, NCryptDecrypt, NCryptKeyDerivation, NCryptExportKey, NCryptProtectSecret -- begins by routing the call through ncrypt.dll, which acts as a router rather than an implementation. The router decides which Key Storage Provider handles the operation and forwards the call.

That routing layer is the architectural distinction Microsoft has insisted on for two decades. Microsoft's Key Storage and Retrieval documentation [@learn-microsoft-com-and-retrieval] describes it like this: the NCrypt router "conceals details, such as key isolation, from both the application and the storage provider itself." Translation: the application calls NCryptSignHash and gets back a signature. It does not know -- and should not need to know -- whether the key lives in %APPDATA%, inside a TPM chip on the motherboard, on a smart card halfway across the room, or in a network-attached hardware security module in a data center on a different continent.

A registered plug-in DLL that owns persistent private-key material and exposes it through the NCrypt API. Microsoft ships four built-in KSPs (Software, Platform/TPM, Smart Card, and the CNG-DPAPI provider); third parties ship KSPs for HSM appliances, USB security keys, and cloud key services. Selecting a KSP is a matter of passing the right name string to `NCryptOpenStorageProvider`.

The mechanical flow for creating a persisted key looks like this.

sequenceDiagram participant App as Application participant Router as ncrypt.dll (NCrypt router) participant KSP as Microsoft Software KSP participant LSA as LSA key-isolation process participant Disk as %APPDATA%\Microsoft\Crypto\Keys\

App->>Router: NCryptOpenStorageProvider("Microsoft Software Key Storage Provider")
Router-->>App: hProvider
App->>Router: NCryptCreatePersistedKey(hProvider, "RSA", "MyKey", 2048, ...)
Router->>KSP: dispatch via registered KSP entry points
KSP->>LSA: LRPC: generate key, return handle
LSA->>Disk: write DPAPI-wrapped private blob
LSA-->>KSP: ok
KSP-->>Router: hKey
Router-->>App: hKey
App->>Router: NCryptSignHash(hKey, digest)
Router->>KSP: forward
KSP->>LSA: LRPC: sign with isolated key
LSA-->>KSP: signature
KSP-->>Router: signature
Router-->>App: signature

Two facts about that diagram matter. First, the private key bits never enter the calling process. They are generated inside the LSA process and the calling application only ever receives a handle and the eventual signature. Second, the LRPC hop is real: it costs roughly 30 to 100 microseconds per call on modern hardware. For bulk symmetric encryption you would not want this overhead, which is why CNG's design pushes you toward BCrypt for symmetric work and reserves NCrypt for the rarer, smaller, and more sensitive operations on long-lived asymmetric keys.The LSA key-isolation process is lsaiso.exe on systems with Credential Guard enabled, hosted inside the Virtualization-Based Security (VBS) trustlet boundary. On systems without VBS, the role is played by lsass.exe itself. Either way, key material does not enter the application's address space.

NCrypt is also where the asymmetric algorithms live in their persistent form. The Microsoft Software Key Storage Provider claims RSA keys from 512 to 16384 bits in 64-bit increments, DSA, DH, and ECDSA/ECDH on the NIST P-256, P-384, and P-521 curves [@learn-microsoft-com-and-retrieval]. Windows 11 24H2 added ML-KEM at the 512, 768, and 1024 parameter sets and ML-DSA at the 44, 65, and 87 parameter sets to the Software KSP's repertoire.

The split between BCrypt and NCrypt is sometimes confusing because there is overlap. You can sign with BCrypt's BCryptSignHash if you generated an ephemeral key pair. You can also sign with NCrypt's NCryptSignHash if the key is persisted in a KSP. The rule of thumb is: if the key needs to survive the process, use NCrypt; if it does not, use BCrypt. Real-world Windows code skews heavily toward NCrypt for asymmetric operations because almost every interesting asymmetric key has an associated certificate, and certificates outlive processes.

Note: The four Microsoft KSP name strings are MS_KEY_STORAGE_PROVIDER (Software), MS_PLATFORM_KEY_STORAGE_PROVIDER (TPM/Pluton), MS_SMART_CARD_KEY_STORAGE_PROVIDER, and MS_NGC_KEY_STORAGE_PROVIDER (Next Generation Credentials, used by Windows Hello). Typo any of these and you silently fall through to the Software KSP, which is a recurring source of "why is my key on disk instead of in the TPM" incident reports.

The router lets the application speak one language and have the storage backend vary. That makes the KSP plug-in model the most interesting piece of the architecture, and it deserves its own section.

4. The KSP model: one API, many places to keep keys

A KSP is a DLL on disk and an entry in the registry. The DLL exports a fixed set of function pointers that mirror NCrypt's API. The registry entry under HKLM\SOFTWARE\Microsoft\Cryptography\Providers\Microsoft Software Key Storage Provider (and its siblings) tells ncrypt.dll which DLL to load when an application asks for a provider by name. That is the whole interface contract. If you can produce a DLL that implements the entry points and you can install a registry entry, you have a CNG KSP.

The platform comes with four. They sit on a spectrum from "your operating system is the entire trust boundary" to "the keys live on a separate piece of silicon and only signatures come back."

flowchart LR A["Microsoft Software KSP -- private keys on disk -- (DPAPI-wrapped)"] --> B["Microsoft Platform Crypto Provider -- TPM 2.0 or Pluton -- on-CPU silicon"] B --> C["Microsoft Smart Card KSP -- removable hardware token -- (PIV, CAC, Yubikey)"] C --> D["Third-party HSM KSP -- Thales Luna, Entrust nShield, -- YubiHSM 2, AWS CloudHSM"] A -.-> A1["~10^4 RSA-2048 sign/sec -- FIPS 140-2 L1"] B -.-> B1["~1-10 sign/sec -- TPM vendor cert"] C -.-> C1["~1-5 sign/sec -- card vendor cert"] D -.-> D1["~10^2-10^4 sign/sec -- FIPS 140-2/-3 L3 typical"]

4.1 The Microsoft Software KSP

The default. If you pass NULL for the provider name in NCryptOpenStorageProvider, you get this one. It stores per-user private keys at %APPDATA%\Microsoft\Crypto\Keys\ and per-machine keys at %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\SystemKeys\, with each file-level blob further protected by DPAPI under either the user master key or the LocalSystem (S-1-5-18) master key. The private-key operations dispatch through LRPC into the LSA key-isolation process so that even with administrator privileges on the machine, naive code-injection into the application's address space does not yield key bits.

The Microsoft Software KSP is also the only KSP that runs inside the LSA key-isolation process. Third-party KSPs run in the calling application's process. That difference matters enormously for the threat model. Microsoft notes this explicitly: third-party KSPs "do not run inside the LSA process" [@learn-microsoft-com-and-retrieval]. If you are a third-party KSP that talks to remote HSM hardware, the isolation comes from the HSM itself, not from any Windows process boundary.

4.2 The Microsoft Platform Crypto Provider (TPM and Pluton)

The KSP that answers to MS_PLATFORM_KEY_STORAGE_PROVIDER is the TPM's face to CNG. When you call NCryptCreatePersistedKey against it, the TPM 2.0 chip itself [@learn-microsoft-com-tpm-fundamentals] generates the key under the protection of its Storage Root Key. The private bits never leave the chip. The application gets back a handle whose only operations are sign, decrypt, and key derivation -- the private key cannot be exported, and that property is enforced by physics, not by software policy.

Key idea: The Platform Crypto Provider is the place where CNG stops trusting the operating system and starts trusting a separate piece of silicon. Every TPM-backed key in Windows -- BitLocker's Volume Master Key wrapping, Windows Hello credentials, AD CS attestation-enrolled machine identities -- enters and exits through this single KSP name.

Microsoft Pluton, the security processor that shipped in 2022 on AMD Ryzen 6000, Snapdragon 8cx Gen 3, and Intel Core Ultra Series 2 silicon, is exposed to Windows as a TPM 2.0 device behind the same Platform Crypto Provider name [@learn-microsoft-com-security-processor]. Application code that worked against a discrete TPM works against Pluton with no changes. Pluton's wins are at the supply-chain layer (no SPI bus to physically tap between the chip and the CPU) and the firmware-update layer (Pluton firmware ships via Windows Update). The Windows-facing API is intentionally identical.

4.3 The Microsoft Smart Card KSP

MS_SMART_CARD_KEY_STORAGE_PROVIDER is a single KSP that routes to whichever vendor minidriver claims the inserted card. The minidriver model is Microsoft's plug-in layer below the KSP layer: smart-card vendors do not write CNG KSPs, they write minidrivers, and Microsoft's single KSP fans the calls out to them via the APDU protocol. Cards that follow Microsoft's Generic Identity Device Specification (GIDS) [@learn-microsoft-com-device-specification] work without a vendor minidriver. Cards that do not, including most US federal PIV cards before about 2015, ship vendor-specific minidrivers.

This is the layer that powers Windows Hello for Business "virtual smart card" credentials, which present a TPM-backed key through the smart-card path because so much enterprise software already knew how to talk to PIV-style cards.

4.4 Third-party HSM and security-key KSPs

YubiHSM 2, Thales Luna, Entrust nShield, AWS CloudHSM Client for Windows, and various cloud-KMS bridges all ship CNG KSPs. The KSP DLL pretends to be a local provider and proxies operations across whatever transport the device uses -- USB for a YubiHSM, PCIe or TCP for a Luna, HTTPS for a cloud HSM. Latency varies from microseconds for a USB device to a few milliseconds for a network HSM. The application code that calls NCryptSignHash does not change.

For an internal Active Directory Certificate Services CA, the KSP choice is the entire trust story. A CA whose root key lives in the Software KSP can have that key extracted by any administrator. A CA whose root lives in a FIPS 140-2 Level 3 HSM KSP requires physical access to the HSM (often with multi-person key ceremonies) to recover the key. The application code in `certutil` is identical in both cases. The audit story is not.

5. The TPM KSP, attestation, and the hardware boundary

A TPM-bound key is a useful key, but a TPM-bound key with an attestation statement is a different kind of asset entirely. The Trusted Platform Module supports a primitive called key attestation: the TPM can sign a statement that says, "this key was generated inside me, I will never let it out, and here is a chain of trust back to my Endorsement Key that proves I am a real TPM made by a real vendor." A certificate authority that requires this attestation can refuse to issue a certificate for any key that did not come from inside a TPM.

Active Directory Certificate Services supports exactly this flow as "TPM key attestation" [@learn-microsoft-com-key-attestation]. The flow involves three keys: an Endorsement Key (EK) burned into the TPM at manufacture, an Attestation Identity Key (AIK) derived from the EK and certified by Microsoft or by the enterprise PKI, and the application key being attested. The AIK signs a statement covering the application key's properties; the CA verifies the AIK certificate chain and the statement, and only then issues a certificate.

flowchart TD EK["Endorsement Key (EK) -- burned into TPM at manufacture -- vendor cert from Intel/AMD/etc."] AIK["Attestation Identity Key (AIK) -- generated in TPM, certified by -- Microsoft EK CA or enterprise PKI"] APPK["Application key -- generated in TPM via -- NCryptCreatePersistedKey"] STMT["Attestation statement -- signed by AIK"] CA["Enterprise CA (AD CS) -- verifies AIK chain -- and attestation"] CERT["X.509 certificate -- issued to application key"]

EK --> AIK
AIK --> STMT
APPK --> STMT
STMT --> CA
CA --> CERT

The CNG-facing API for this is the property bag on a NCRYPT_KEY_HANDLE. After creating the key, the application calls NCryptGetProperty with NCRYPT_KEY_ATTESTATION_PROPERTY (and friends) to retrieve the attestation blob. The CA receives the blob in the certificate request and validates it against Microsoft's published EK CA roots. The whole protocol fits inside the standard certificate-enrollment flow.

Key idea: A software KSP can promise that a key is non-exportable. A TPM KSP can prove it.

Throughput is the price. A typical TPM 2.0 chip performs single-digit RSA-2048 signatures per second. Pluton-based platforms are in the same neighborhood. Any architecture that wants to do a TPM signature on every HTTP request will fall over almost immediately. The TPM is the right home for one signature per session, per boot, or per logon -- not one per packet.Key migration between TPMs is essentially impossible by design. Replace a motherboard, and any keys that were sealed to the old TPM's Storage Root Key are gone. This is the same property that makes BitLocker safe against motherboard theft (the recovery key, escrowed elsewhere, is the only way back) and the same property that makes TPM-bound device identities a key-management headache during hardware refresh cycles.

There is a deeper, more philosophical reason to use the TPM that the API does not advertise. Software keys are bounded by the kernel's process-isolation guarantees. Any kernel-level attacker, any user with SeDebugPrivilege, or any code injected into lsass.exe can in principle reach key material. The provably stronger bound -- keys that no OS-level code can ever read -- requires an off-CPU hardware boundary. CNG's own design notes acknowledge this when they say CNG "is designed to be usable as a component in a FIPS level 2 validated system" [@learn-microsoft-com-cng-features]: software-only isolation maps to FIPS 140-2 Levels 1 and 2; hardware boundaries are required for Level 3 and above.

6. FIPS 140 mode, compliance, and the one-bit toggle

There is a registry value at HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled. When it is set to 1 (or when the equivalent Group Policy "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" is enabled), Schannel and CNG callers refuse to use algorithms that fall outside the FIPS-approved set. RC4 disappears. MD5 disappears. SHA-1 disappears for new signatures (though not for legacy verification). TLS suites that rely on any of those are removed from the negotiation list.

The toggle is a runtime gate, not a code path. The underlying modules -- bcryptprimitives.dll and cng.sys [@learn-microsoft-com-140-windows11] -- are the same modules either way. They have been submitted to the Cryptographic Module Validation Program [@csrc-nist-gov-modules-search] and validated against the FIPS 140-2 standard [@csrc-nist-gov-2-final]. The toggle simply tells those modules that the calling environment expects FIPS-mode behavior, and the modules then refuse the non-approved algorithms.

A US federal certification program (Federal Information Processing Standard 140) that subjects a cryptographic module to laboratory testing and NIST review. Validated modules receive a public CMVP certificate. Federal agencies, FedRAMP/CMMC contractors, and most regulated industries can only use validated modules in approved configurations. FIPS 140-2 and the newer FIPS 140-3 differ mainly in test methodology and the standard's own ISO/IEC alignment.

Two current Windows 11 certificate numbers are worth memorizing. CMVP certificate #4825 covers bcryptprimitives.dll [@csrc-nist-gov-certificate-4825]. CMVP certificate #4766 covers cng.sys [@csrc-nist-gov-certificate-4766], the kernel-mode primitives. Both are FIPS 140-2 Level 1 modules with a sunset date of September 21, 2026 under the CMVP's transition rules. Microsoft maintains the per-version FIPS validation portal for Windows 11 [@learn-microsoft-com-140-windows11], which lists the active certificates per build and the algorithms each one covers.

The cadence mismatch is the open story here. Windows ships H1 and H2 feature updates roughly every six months. CMVP validation of a new build's primitives DLL and kernel module typically takes 12 to 24 months. Federal customers, FedRAMP-bound cloud tenants, and CMMC contractors cannot run a Windows build that does not have an active FIPS certificate covering its cryptographic modules. Microsoft submits 140-3 evidence for newer modules, but as of mid-2026 no public 140-3 certificate is visible on CMVP for the bcryptprimitives.dll shipping in Windows 11 24H2.

Note: Setting FIPSAlgorithmPolicy\Enabled = 1 is necessary for FIPS compliance, but not sufficient. The validated configuration also requires that Windows be a covered build (with an active certificate), that you avoid third-party crypto libraries that have not been validated, and that algorithm choices stay inside the per-certificate Approved Mode list. A Windows version without an active certificate is not in compliance even with the toggle on.

The toggle also does not change the SymCrypt implementations. AES-GCM is still AES-GCM. What changes is which APIs the caller is allowed to reach. From the application's point of view, the symptom of FIPS mode is STATUS_NOT_SUPPORTED on BCryptOpenAlgorithmProvider(L"RC4", ...). From an auditor's point of view, the symptom is the absence of any disallowed primitive call in the binary.

7. The post-quantum slide: ML-KEM, ML-DSA, and the agility test

The piece of CNG that earns its "agility" billing is the post-quantum transition.

NIST opened the Post-Quantum Cryptography standardization process in 2016 and ran four rounds of public evaluation [@csrc-nist-gov-quantum-cryptography] before issuing the first final standards in August 2024. FIPS 203 standardizes ML-KEM (formerly CRYSTALS-Kyber), a module-lattice key encapsulation mechanism [@nvlpubs-nist-gov-fips-nistfips203pdf]. FIPS 204 standardizes ML-DSA (formerly CRYSTALS-Dilithium), a module-lattice digital signature algorithm [@csrc-nist-gov-204-final]. Microsoft Research had been working on lattice cryptography for years [@microsoft-com-quantum-cryptography], and the public CNG implementations followed quickly: Windows 11 24H2 ships ML-KEM and ML-DSA as first-class CNG algorithms.

Here is the surprising part: the CNG API surface did not change. Adding ML-KEM was a matter of registering new algorithm identifier strings -- BCRYPT_MLKEM_ALGORITHM, the parameter sets BCRYPT_MLKEM_PARAMETER_SET_512, BCRYPT_MLKEM_PARAMETER_SET_768, BCRYPT_MLKEM_PARAMETER_SET_1024 -- in the CNG algorithm-identifier registry [@learn-microsoft-com-algorithm-identifiers]. The opening dance for an ML-KEM key encapsulation looks exactly like the opening dance for an ECDH key agreement, except for the string.

{` // Mirrors the BCrypt pattern shown in the Microsoft sample // "Using ML-KEM with CNG for Key Exchange"

const hAlg = BCryptOpenAlgorithmProvider("ML-KEM", null, 0);

const hKeyPair = BCryptGenerateKeyPair(hAlg, 0, 0); BCryptSetProperty(hKeyPair, "ParameterSetName", "ML-KEM-768"); BCryptFinalizeKeyPair(hKeyPair, 0);

const pubBlob = BCryptExportKey(hKeyPair, "MLKEMPUBLICBLOB");

// Sender side: encapsulate to recipient's public key const recipPub = BCryptImportKeyPair(hAlg, "MLKEMPUBLICBLOB", pubBlob); const { ciphertext, sharedSecret: ssA } = BCryptEncapsulate(recipPub);

// Recipient side: decapsulate with the matching private key const ssB = BCryptDecapsulate(hKeyPair, ciphertext);

// ssA === ssB `}

That code is structurally identical to a 2007-era ECDH session. The string changes, the blob format changes, and the wire-format sizes change considerably. ML-KEM ciphertexts at the 512, 768, and 1024 parameter sets are 768, 1088, and 1568 bytes respectively, with public keys of 800, 1184, and 1568 bytes per FIPS 203 [@csrc-nist-gov-203-final]. ML-DSA signatures at parameter sets 44, 65, and 87 are 2420, 3309, and 4627 bytes per FIPS 204 [@csrc-nist-gov-204-final]. For comparison, an ECDSA P-256 signature is 64 bytes and an X25519 public key is 32 bytes. The PQC blowup is roughly an order of magnitude, and that has knock-on consequences for every protocol that carries certificates or handshakes on the wire.

The reason ML-KEM matters before any large quantum computer exists is the harvest-now, decrypt-later attack: an adversary recording today's TLS sessions can decrypt them years from now if the long-lived key-exchange material was only protected by RSA or ECDH. Long-lived secrets transmitted over the wire today -- medical records, source code, government cables -- have a confidentiality lifetime measured in decades. The motivation for hybrid PQ key exchange is that you cannot un-record traffic.

The wire-format problem is why most TLS-PQ deployments use hybrid groups: classical X25519 combined with ML-KEM-768, with the shared secret derived from both. If either component breaks, the other one still holds. The IETF draft draft-kwiatkowski-tls-ecdhe-mlkem [@learn-microsoft-com-mlkem-examples] defines the X25519MLKEM768 group with IANA codepoint 0x11EC, and Chrome, Cloudflare, and AWS shipped support in production in 2024. OpenJDK JEP 527 [@openjdk-org-jeps-527] tracks the equivalent work for Java's TLS stack. Schannel in Windows 11 24H2 can negotiate ML-KEM through CNG, but Microsoft has not publicly committed to a default-on hybrid group at the Schannel layer as of mid-2026.

On a Windows 11 24H2 machine, the following PowerShell snippet asks CNG for its registered algorithms:

[System.Security.Cryptography.CngAlgorithm]::new("ML-KEM")
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\Default\0010'

The first line forces a CngAlgorithm lookup. The second walks the configuration store. If the keys ML-KEM and ML-DSA appear, your kernel-mode and user-mode primitives are 24H2-current.

The bigger structural lesson is that two decades of "cryptographic agility" claims actually paid off. The PQC transition required a 24H2 update, not a CNG redesign.

8. Where CNG actually shows up: TLS, BitLocker, and friends

The argument for an OS-level cryptographic API stands or falls on what runs on top of it. Every modern Windows component that touches cryptography is a CNG consumer.

The Windows implementation of TLS and DTLS, exposed through the SSPI (Security Support Provider Interface). Schannel handles the TLS protocol state machine, certificate validation, and cipher-suite negotiation, then delegates the actual cryptography to BCrypt and NCrypt. The cipher-suite priority list and protocol-version controls are configured per Windows version, often via Group Policy.

Schannel, the Windows TLS stack, sits directly above CNG. The Schannel cipher-suite list is its own per-version object, documented at the Schannel cipher-suites portal [@learn-microsoft-com-in-schannel]. For TLS 1.2 and earlier, the order is administered via the registry key HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002 (the "Functions" value) or the Group Policy "SSL Cipher Suite Order." For TLS 1.3, the three suites (TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256) are not user-orderable; Schannel hard-codes the priority. TLS 1.0 and TLS 1.1 are off by default in Windows 11 23H2 and later, per Microsoft's August 2023 deprecation announcement [@techcommunity-microsoft-com-windows-3887947].

flowchart TD App["Application -- (WinHTTP, HttpClient, browser, ...)"] SSPI["SSPI / CredSSP layer"] Schannel["Schannel -- protocol state machine -- cipher-suite negotiation"] BCrypt["BCrypt -- AES-GCM, SHA-2/3, HKDF, RNG"] NCrypt["NCrypt -- server cert private key sign -- client cert auth"] KSP["KSP (Software / TPM / -- Smart Card / HSM)"]

App --> SSPI
SSPI --> Schannel
Schannel --> BCrypt
Schannel --> NCrypt
NCrypt --> KSP

BitLocker is the canonical NCrypt-and-TPM consumer. The Full Volume Encryption Key (FVEK) is generated and stored encrypted on disk. The Volume Master Key (VMK) wraps the FVEK and is itself wrapped by one or more "protectors": the TPM, a recovery password, a startup PIN, a USB startup key. The TPM protector is an NCrypt-style operation against the Platform Crypto Provider, sealed to a set of Platform Configuration Register (PCR) measurements that capture the boot state. If anything in the early boot chain changes, the PCRs do not match, the TPM refuses to unwrap the VMK, and BitLocker falls back to recovery.

Authenticode, the signature format on Windows binaries, is a NCrypt-driven workflow at signing time and a BCrypt-driven workflow at verification time. The Windows kernel verifies driver signatures, the Windows loader verifies binary signatures, and WinVerifyTrust exposes the same machinery to applications. The hash algorithm in modern Authenticode is SHA-256, which means every signed executable on the system has a SHA-256 digest computed by BCrypt at some point during validation.

Credential Guard runs the LSA isolated process (lsaiso.exe) inside the Virtualization-Based Security trustlet boundary on systems with VBS enabled. Credential Guard does not replace CNG; it relocates the Microsoft Software KSP into a stronger isolation boundary. NTLM password hashes and Kerberos TGT session keys live inside that boundary, accessible only through the standard CNG calls dispatched into the trustlet.

Windows Hello for Business uses the Platform Crypto Provider as the home for the user's gesture-protected authentication key. The biometric (or PIN) unlocks a key in the TPM; that key signs an attestation that is consumed by Azure AD or AD FS. The biometric never leaves the device.

DPAPI and DPAPI-NG are themselves built on CNG, and they deserve their own section because they are the easiest place to see how the layering pays off.

Schannel, BitLocker, EFS, Authenticode, Credential Guard, Windows Hello, DPAPI-NG, IPsec, SMB encryption, Kerberos PKINIT -- every modern Windows component is a CNG consumer.

9. DPAPI-NG: a worked example of the NCrypt model

The original Data Protection API (DPAPI), shipped with Windows 2000, was a per-user secret-protection mechanism. An application called CryptProtectData, passed a blob of secret data, and got back an encrypted blob that only the same user on the same machine could later unwrap. The mechanism was anchored in the user's logon credentials, with a master key per user and a complex backup mechanism for password resets. It worked. It also locked the secret to a single machine, which became a problem the moment users started living on more than one device.

DPAPI-NG, introduced in Windows 8 and Windows Server 2012, is the cloud-era rebuild. The CNG DPAPI documentation [@learn-microsoft-com-cng-dpapi] describes the three calls: NCryptCreateProtectionDescriptor, NCryptProtectSecret, and NCryptUnprotectSecret. The protection descriptor is a small string that names who can unwrap the data. Examples include SID=S-1-5-21-... for an Active Directory user or group, LOCAL=user for the legacy single-user behavior, WEBCREDENTIALS=... for a credential vault entry, and combinations connected by AND or OR operators.

flowchart LR Plain["plaintext secret"] --> Protect["NCryptProtectSecret(descriptor, plain)"] Desc["descriptor: -- SID=group GUID -- OR -- LOCAL=user"] --> Protect Protect --> Blob["opaque blob"] Blob --> Unprotect["NCryptUnprotectSecret(blob)"] Unprotect -.->|"resolves descriptor -- via AD DC backup keys"| AD["Active Directory DC -- (DPAPI backup keys)"] Unprotect --> Out["plaintext secret -- on any authorized machine"]

The architectural win is that DPAPI-NG is just NCrypt with a particular protection-descriptor schema. Any KSP that can serve the key referenced by the descriptor can satisfy the unwrap. In an Active-Directory-joined environment, the AD domain controller's DPAPI backup keys allow any machine where the user (or any member of the named group) authenticates to recover the secret. The application that called NCryptProtectSecret does not need to know about backup keys, replication topology, or recovery flows. It calls NCrypt; the router and the relevant KSP do the rest.

This is the design payoff of the two-tier model. A new key-management capability (cross-machine recovery via AD-stored backup keys) becomes a new descriptor type, not a new API. The Windows team has used the same descriptor extensibility to add web-credential descriptors, container-bound descriptors, and the descriptors that protect Group Managed Service Account passwords. Each one is a private key-management concern; none of them broke the public API.The DPAPI-NG descriptor language is small enough to read in one sitting and powerful enough to express "any member of this AD group, on any machine where that member can authenticate." That is the cloud-era access-control story that the original DPAPI never had.

10. Engineering takeaways: choosing the right tool

The decision tree for CNG usage in production code is short.

flowchart TD Q1{"Need persistent -- private key?"} Q1 -- No --> B["BCrypt -- (ephemeral key, pseudo-handle)"] Q1 -- Yes --> Q2{"Threat model?"} Q2 -- "Machine identity, -- hardware-rooted" --> P["Microsoft Platform -- Crypto Provider -- (TPM / Pluton)"] Q2 -- "User-bound PKI, -- removable hardware" --> S["Microsoft Smart Card KSP -- (PIV / virtual smart card)"] Q2 -- "High signing rate, -- regulated custody" --> H["Third-party HSM KSP -- (YubiHSM / Luna / nShield)"] Q2 -- "Default, -- portable, fast" --> SW["Microsoft Software KSP"]

For algorithm choice in mid-2026, the defensible defaults look like this. Symmetric encryption: ChaCha20-Poly1305 or AES-256-GCM. Hashing: SHA-256 or SHA-3 family. Signatures: ECDSA P-256 or P-384 today, with ML-DSA-65 in the back pocket for the inevitable hybrid transition. Key encapsulation: X25519 today, with X25519+ML-KEM-768 hybrid as soon as your peers support it. RSA-2048 only for legacy interoperability. RC4, 3DES, and SHA-1 only behind explicit deprecation policy, and only for verification of historical artifacts.

Key idea: The hardest thing about CNG is not learning the API. It is choosing the right KSP. That single decision -- where the private key actually lives -- determines almost everything about your threat model, your throughput, your compliance posture, and your operational complexity.

A few engineering rules survive in any setting.

Do not put persistent keys in BCrypt. Every BCrypt key handle dies with the process. The architectural separation exists for a reason. If the key needs to survive a reboot, it belongs in NCrypt under a named KSP.

Do not assume the Software KSP. Code that calls NCryptOpenStorageProvider(NULL) ends up with whatever the default is. On a server with an HSM KSP configured as the default, this might be what you want; on a developer workstation, it might be the Microsoft Software KSP. Be explicit. Pass the name string. Test the negative case where the KSP you named is not registered.

Audit which KSP your certificates actually use. A certificate enrolled with the Platform Crypto Provider behaves identically to a certificate enrolled with the Software KSP from certutil's point of view. The difference is invisible until you ask. Use certutil -store -v My to dump certificate properties, and look for the provider field.

Treat FIPS mode as a deployment fact, not a development toggle. Code that works fine on a developer workstation can break in surprising ways on a FIPS-enabled production server. Run your CI on a FIPS-toggled image periodically. Catch the STATUS_NOT_SUPPORTED returns before customers do.

Watch the PQC roadmap. The ML-KEM and ML-DSA primitives are in 24H2. Hybrid TLS in Schannel is not on by default at the OS level as of mid-2026 (the most recent Microsoft public posture in the cipher-suite documentation does not yet list a default-on hybrid group), but downstream protocol updates will come. Code that uses the BCrypt and NCrypt patterns shown here picks up the new algorithms with a string change.

Note: The single most useful CNG diagnostic command on a modern Windows system is certutil -csptest, which enumerates registered providers and the algorithms each one claims to support. Run it before you suspect a configuration drift, not after.

The story of CNG is the story of two architectural bets that paid off. The first bet was that algorithms would keep arriving, so the API should be a registry of strings rather than a hard-coded set of functions. The second bet was that key storage was a separate concern from algorithm implementation, so the same primitives could run against software, TPM, smart cards, and HSMs without changing the application. In 2007 those bets looked over-engineered. In 2026, with ML-KEM shipping behind the same BCryptEncapsulate call that an ECDH consumer would have used, they look like exactly the right design.

Frequently asked questions

No. Microsoft's BCrypt is the `bcrypt.h` primitives header in CNG, providing AES, SHA, HMAC, RNG, and related primitives. The Provos-Mazieres bcrypt is a password-hashing function based on the Blowfish cipher, with no connection to Windows. The naming collision is unfortunate but firmly entrenched. When in doubt, BCrypt with a capital "B" usually means Microsoft's CNG header; lowercase bcrypt usually means the password-hashing function. On Windows, yes. .NET's `System.Security.Cryptography` namespace wraps CNG directly: `RSACng`, `ECDsaCng`, `AesGcm`, `SHA256.HashData()`, `CngKey`. Go, Rust, and Python bindings exist as third-party crates and packages (the Rust `windows` crate exposes both BCrypt and NCrypt, for example). OpenSSL on Windows does not transparently use CNG; you need the `openssl-cng` provider or direct CNG calls if you want the OS-validated primitives to do the work. Both can do RSA, ECDSA, and (in 24H2) ML-DSA signatures. The difference is lifetime. BCrypt key handles are ephemeral: they live in your process and disappear when it exits. NCrypt keys are persisted in a KSP and survive process exit, reboots, and (for AD-replicated descriptors via DPAPI-NG) the loss of a single machine. Use BCrypt for one-shot ephemeral operations (signing a single message, deriving a session key); use NCrypt for anything with a certificate attached or anything that has to be around tomorrow. Possibly, depending on what algorithms it calls. Setting `HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled = 1` causes CNG to refuse RC4, MD5, SHA-1 for new signatures, and a handful of other non-approved algorithms. Anything that relied on those returns `STATUS_NOT_SUPPORTED`. The fix is to switch to approved algorithms (AES, SHA-2 family, RSA, ECDSA, ML-KEM, ML-DSA), not to disable the toggle. The toggle is also necessary but not sufficient for FIPS compliance: you also need a Windows build with an active CMVP certificate covering the cryptographic modules. As of mid-2026, the public Schannel documentation does not list a default-on hybrid group like `X25519MLKEM768`. The ML-KEM primitive is in CNG in 24H2, and Schannel can use it through the standard cipher-suite negotiation, but Microsoft has not publicly committed to enabling a hybrid group out of the box at the OS level. Chrome, Cloudflare, and AWS have already shipped hybrid PQ TLS in production at the application layer. Expect Schannel to follow once IETF standardization stabilizes and CMVP validation of the new modules catches up. For a certificate in the user or machine store, run `certutil -store -v My` (or `My` replaced with the store name) and look at the "Provider" field of each certificate. `Microsoft Software Key Storage Provider` means the key is on disk under `%APPDATA%` or `%ALLUSERSPROFILE%`. `Microsoft Platform Crypto Provider` means the key lives inside the TPM (or Pluton). `Microsoft Smart Card Key Storage Provider` means the key is on a card. Third-party HSM KSPs will show the vendor's provider name. For a freshly-created key via `NCryptCreatePersistedKey`, the provider name you passed to `NCryptOpenStorageProvider` is the source of truth. Because private keys do not live in the calling process. For the Microsoft Software KSP, key material lives in the LSA key-isolation process (`lsaiso.exe` under VBS, `lsass.exe` otherwise), and every operation that touches private bits has to cross that process boundary. The cost is around 30 to 100 microseconds per call. That is acceptable for signing or key derivation (operations that happen a handful of times per session); it would be punishing for bulk symmetric encryption. The architectural answer is to keep bulk crypto in BCrypt and let only the persistent-key operations pay the LRPC cost.

<StudyGuide slug="cng-architecture-bcrypt-ncrypt-ksps-and-windows-crypto" keyTerms={[ { term: "CAPI (Cryptographic Application Programming Interface)", definition: "The original Windows cryptographic API (1998-onward). Plug-in unit was the CSP. Superseded by CNG starting in 2007 but still present for backwards compatibility." }, { term: "CNG (Cryptography API: Next Generation)", definition: "The Windows cryptographic API since Vista (2007). Two-tier split: BCrypt for primitives, NCrypt for key storage. The basis for all modern Windows cryptography." }, { term: "CSP (Cryptographic Service Provider)", definition: "The CAPI-era plug-in unit. Monolithic DLL bundling algorithms, key storage, and FIPS posture." }, { term: "KSP (Key Storage Provider)", definition: "The CNG-era plug-in unit for persistent key storage. Microsoft ships four; third parties ship many more. Selected by name string passed to NCryptOpenStorageProvider." }, { term: "Microsoft Software Key Storage Provider", definition: "The default KSP. Stores DPAPI-wrapped keys on disk and dispatches operations through the LSA key-isolation process via LRPC." }, { term: "Microsoft Platform Crypto Provider", definition: "The TPM-and-Pluton-backed KSP. Keys are generated and used inside the TPM chip; private bits never leave the silicon." }, { term: "TPM key attestation", definition: "A three-key chain (EK -> AIK -> application key) that lets a CA verify a key was generated inside a real TPM. Supported by Active Directory Certificate Services since Windows Server 2012 R2." }, { term: "FIPS 140", definition: "US federal certification program for cryptographic modules. Validated modules receive a public CMVP certificate. Windows 11's bcryptprimitives.dll holds CMVP certificate #4825, cng.sys holds #4766." }, { term: "ML-KEM (FIPS 203)", definition: "Module-Lattice Key Encapsulation Mechanism. The NIST-standardized post-quantum KEM, formerly known as CRYSTALS-Kyber. Shipped in Windows 11 24H2." }, { term: "ML-DSA (FIPS 204)", definition: "Module-Lattice Digital Signature Algorithm. The NIST-standardized post-quantum signature scheme, formerly known as CRYSTALS-Dilithium. Shipped in Windows 11 24H2." }, { term: "DPAPI-NG", definition: "The CNG-era rebuild of the original Data Protection API. Uses NCrypt protection descriptors to bind protected data to AD principals (users, groups, web credentials) rather than to a single machine." }, { term: "SymCrypt", definition: "Microsoft's open-source cryptographic implementation library. The actual workhorse behind BCrypt and NCrypt since Windows 10 version 1703 (2017)." } ]} />

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 anchored in the TPM at manufacture (in TPM 2.0, derived from a persistent endorsement seed). Its public half is the chip's long-term 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 produces signed attestation documents, verified against an AWS-operated X.509 certificate chain, that contain enclave measurements (PCRs) and instance/module 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 200V (Lunar Lake) in 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 using an anonymous group-signature attestation (ECDAA or EPID) is, in ISO-speak, executing a 20009-2 mechanism that wraps a 20008-2 signature; ordinary TPM-backed Kerberos and key-attestation flows use non-anonymous keys and are separate protocol designs.

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.3 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 finds dozens of 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 CNG 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	Centralized (refuse / CRL / OCSP)	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.

Inside the Primary Refresh Token: The Cryptographic Seam Between Windows Logon and Microsoft Entra ID

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

The **Primary Refresh Token (PRT)** is the cryptographic seam where a Windows logon becomes a Microsoft Entra ID transaction. It is a JWT issued by Microsoft Entra ID to the CloudAP plugin in `lsass` at first interactive sign-in on an Entra-registered, Entra-joined, or Entra-hybrid-joined device. The PRT is signed at issuance by a TPM-bound **device key** (`dkpriv`); every downstream artifact -- the `x-ms-RefreshTokenCredential` browser cookie, app-token requests via WAM, Conditional Access claim flow -- is signed by a session key returned encrypted under the device's **transport key** (`tkpub`). In 2020, Dirk-jan Mollema and Lee Christensen showed that even with TPM-bound keys, admin on the live device could mint cookies anywhere -- the Pass-the-PRT class. Microsoft closed off-device replay with **KDFv2** (CVE-2021-33779, July 2021), then layered Continuous Access Evaluation, Token Protection, and Cloud Kerberos Trust on top. On-device Cookie-on-Demand attacks remain the open residual.

1. Three sign-ins, one credential

A user signs into a freshly enrolled Entra-joined laptop with Windows Hello for Business. Ten seconds later they open Outlook, which silently authenticates against Microsoft 365. An hour later they type outlook.office.com into Edge -- and they are already signed in there too.

Three sign-ins, one credential. The credential was issued during the Windows logon itself, and the user has never seen it.

This article is about that credential -- the Primary Refresh Token -- and about the cryptographic seam where Windows logon stops being a local NT-style event and becomes a Microsoft Entra ID transaction.

A device-bound JSON Web Token issued by Microsoft Entra ID to the Cloud Authentication Provider in `lsass.exe` at first interactive sign-in on a Microsoft Entra-registered, Entra-joined, or Entra-hybrid-joined device. The PRT is the artifact every other token broker on the device references to mint app access tokens, browser SSO cookies, and Conditional Access claims for the lifetime of the sign-in session [@prt-msft-learn].

The questions worth asking are concrete. What does that token actually contain? How did it get from lsass to a browser cookie without the user ever pasting it? Why is the cookie that rides in the browser called x-ms-RefreshTokenCredential when the PRT itself never leaves the device? And -- the question that will define everything in §5 and §6 -- if the credential is bound to a TPM, how did three independent researchers in the summer of 2020 mint cookies anywhere they wanted to?

The plan is to answer those questions in order. We will name every load-bearing primitive in the stack. We will walk a token request end-to-end. We will explain what the July 2021 KDFv2 patch actually changed at the byte level. And we will be honest about what the PRT cannot do -- because the rest of this series is about the identity surfaces that run alongside it, not under it.

Before we can read the PRT itself, we have to understand the problem it was built to solve. That means going back to 2013, before Azure AD Join was a thing.

2. The cloud-identity gap, 2011 to 2014

Windows authentication, in 2011, did not speak cloud. NTLM resolved against a local SAM database. Kerberos resolved against an on-prem Key Distribution Center. Both predate the notion of a cloud identity provider by more than a decade. When a Windows endpoint authenticated, it talked to a domain controller it could see on the network -- and if it could not see a domain controller, it talked to the local SAM and called it a day.

For a cloud-only workload, that left a gap shaped like a question. Where, exactly, does the user's identity live when there is no on-prem domain to resolve it against?

The first answer was OAuth. RFC 6749 had shipped in October 2012, edited by Dick Hardt while at Microsoft, with refresh tokens explicitly modeled as long-lived bearer credentials redeemed at a token endpoint for short-lived access tokens [@rfc-6749]. Microsoft's Active Directory Authentication Library -- ADAL -- took the obvious next step: every application that wanted to talk to Microsoft's cloud APIs got its own client, its own redirect, and its own refresh token. SSO was approximated by sharing the underlying password prompt or, on a domain-joined machine, by hoping Integrated Windows Authentication smuggled the right Kerberos ticket to the right endpoint.

That patchwork held for a while. It also taught Microsoft two things.

The first lesson was about Conditional Access. If every app maintained its own refresh-token cache and re-presented credentials independently, the policy engine could only see what each token request happened to surface. Whether the request came from a managed Surface or from an unmanaged consumer laptop was anyone's guess. The device, in other words, was invisible.

The second lesson was about the user. Ten apps meant ten silent renewal pipelines, ten password prompts when those pipelines broke, and ten different broker components asking "are you sure?" in slightly different language. The user experience and the security posture were on the same side of the ledger: both wanted a single device-bound credential that every broker could reference.

The first move was small. On 28 June 2013, Adam Hall announced Workplace Join as part of Windows Server 2012 R2: a device-registration primitive that put an X.509 certificate from the Device Registration Service into Active Directory, so that "users can register their device using Workplace Join which creates a new device object in Active Directory and installs a certificate on the device, allowing IT to take into account the user's device authentication as part of conditional access policies" [@workplace-join-2013].

Workplace Join taught the directory that a device existed. It did not make the Windows sign-in itself a cloud event. The artifact it produced was a long-lived certificate, not a session-scoped credential, and it lived on the on-prem AD side of the seam, not the cloud side. For the rest, Microsoft would need a credential the cloud could mint during the sign-in.

That credential arrived in 2015 -- but its design took another year to harden.

3. Workplace Join, Azure AD Join, and the OAuth-refresh-token patchwork

What does it cost a Windows endpoint to authenticate to ten cloud apps if it has no PRT?

Counting tokens is a good way to find out. Each app maintains its own refresh-token cache. Each refresh redeems against the same login.microsoftonline.com endpoint but with a different client_id and a different audience claim. Each app re-asserts the device claim as a separate transaction -- if it can; an app that does not ride a broker can only surface what its own credential flow knows. The architectural failure mode is not that authentication is bad; it is that authentication is redundant, and the policy engine sees a hundred small claims instead of one big one.

Microsoft walked out of that failure mode in three steps.

Step one (June 2013): Workplace Join. A device cert, signed by the Device Registration Service, written to a new device object in Active Directory. Adam Hall's announcement is the load-bearing primary source [@workplace-join-2013]. Nothing about a session: the certificate lives across reboots, across sign-ins, across user accounts. Microsoft now calls this state Microsoft Entra registered -- the same primitive, renamed [@entra-devices-overview]."Workplace Join" was the 2013 marketing name. The same artifact is now called "Microsoft Entra registered" and is the device state used for personal (BYOD) devices that get conditional-access policies applied to corporate workloads. The taxonomy in §3 of the current Microsoft Learn documentation lists three states: Microsoft Entra registered, Microsoft Entra joined, and Microsoft Entra hybrid joined [@entra-devices-overview].

Step two (May 2015): Azure AD Join. On 28 May 2015, Alex Simons and Gary Henderson announced that Windows 10, build 1507, would let a device sign in against a cloud-only Microsoft identity at first boot. "Azure AD join is optimized for users that primarily access cloud resources," the announcement reads -- a quiet way of saying that for the first time, a Windows machine did not need a domain controller on the network to give a user a sign-in surface [@techcomm-azure-ad-join-2015].

This 28 May 2015 Tech Community post is the corrected primary source. An older URL in the same series (.../ba-p/247010) was re-tagged by Microsoft's CMS to a 2010 RemoteFX article and now resolves to unrelated content; the 244005 post is the load-bearing technical announcement.

The Azure AD Join story introduced one more component: CloudAP, the Cloud Authentication Provider, an authentication-package framework hosted inside lsass.exe. CloudAP is the LSASS-resident broker that an enterprise SSO surface talks to from inside the operating system. It is not yet a PRT engine -- in May 2015, it is mostly a routing layer for cloud sign-in primitives. The PRT itself does not exist yet.

A pluggable authentication-package framework introduced inside `lsass.exe` to host cloud-identity sign-in plugins. The Microsoft Entra ID plugin (`aadcloudap.dll`) is the canonical implementation; CloudAP is the LSASS-resident broker that, from Windows 10 1607 onward, owns the device-side PRT lifecycle on Entra-joined and Entra-hybrid-joined machines [@prt-msft-learn].

Step three (August 2016): the first PRT. Windows 10, version 1607 -- the Anniversary Update -- began rolling out on 2 August 2016 [@win10-anniv-1607]. In that build, CloudAP gained an Entra ID plugin that minted a PRT during interactive sign-in, alongside a TPM-bound key pair for proof of possession. From that moment, every other broker on the machine -- the Web Account Manager that backed native apps, Edge for browser SSO, third-party mstsc flows that wanted to redirect a sign-in -- had a single artifact to reference. The architectural gap from §2 closed; the patchwork became a stack.

By the time Microsoft Open Specifications publication MS-OAPXBC went public on 16 October 2015, version 1.0 -- contemporaneous with the Windows 10 1507 release, not three years later -- the protocol scaffolding was already in place [@ms-oapxbc-index]. The PRT itself was the credential the scaffolding had been waiting for.

By 2016, Microsoft had a name for the missing primitive: one device-bound, session-scoped, cloud-issued credential that all brokers could reference. The Anniversary Update made it real. The next question is what that credential is cryptographically -- and to answer that, we need to be precise about two key pairs that most descriptions of the PRT conflate.

timeline title PRT generations, 2013 to 2022 2013 : Workplace Join (Windows Server 2012 R2) : Device cert in AD; no session credential 2015 : Azure AD Join (Windows 10 1507) : CloudAP framework in lsass; no PRT yet 2016 : First PRT (Windows 10 1607) : CloudAP + Entra plugin issue device-bound JWT 2020 : Pass-the-PRT class disclosed : Christensen + Mollema + Syynimaa 2021 : KDFv2 (CVE-2021-33779) : SHA256 of payload mixed into derivation 2022 : CAE GA + Cloud Kerberos Trust + TROOPERS 22 : Composition era begins

4. The two-key cryptographic model

Most descriptions of the PRT online say the cookie is "DKey-signed." That phrase has been wrong since July 2021. Here is the actual cryptographic substrate.

When a Windows device joins Microsoft Entra ID -- by way of the Out-of-Box Experience, by dsreg's join command, or by the implicit registration that happens on a personal device -- the registration component generates two key pairs on the device. One pair signs PRT issuance requests. The other unwraps session keys returned with the PRT. Microsoft's own documentation enumerates the two pairs the dsreg component generates at device registration: Device key (dkpub/dkpriv) and Transport key (tkpub/tkpriv) [@prt-msft-learn].

The first of the two key pairs minted at Microsoft Entra registration. The private half (`dkpriv`) is TPM-resident on supported hardware (TPM 2.0 from Windows 10 1903 onward) and signs the JWT used to *request* a Primary Refresh Token from Microsoft Entra ID. The public half (`dkpub`) is registered with Microsoft Entra ID at join time and is what Entra ID uses to verify that the request originated from the registered device [@prt-msft-learn]. The second registration-time key pair. Entra ID encrypts the freshly minted PRT session key under `tkpub`; only `tkpriv` -- TPM-resident on supported hardware -- can unwrap it. Every downstream signing operation flows through a key derived from that session key, so the transport key is the asymmetric on-ramp to the device's symmetric proof-of-possession surface [@prt-msft-learn]. The Windows component that performs Microsoft Entra registration -- mints the device and transport key pairs, registers `dkpub`/`tkpub` with Entra ID, and produces the device certificate that backs the Microsoft Entra device object. `dsregcmd.exe` is its operator-facing interrogation tool; `dsregcmd /status` reports current state including AzureAdPrt, AzureAdPrtUpdateTime, and AzureAdPrtExpiryTime [@prt-msft-learn].

The two-key model is not a typo, and the second-most-common reading of it is wrong. The device key signs the request for a PRT. The transport key unwraps the session key that arrives with a PRT. Once unwrapped, the session key signs everything from there on -- not the device key.

Note: The device key signs PRT issuance, once per PRT mint. The transport key unwraps a session key. Every downstream artifact -- the x-ms-RefreshTokenCredential browser cookie, every WAM-mediated app-token request -- is signed by a key derived from that session key, not by dkpriv directly.

The eight-step issuance flow makes this explicit.

sequenceDiagram participant User participant CloudAP as CloudAP (lsass) participant TPM participant Entra as Microsoft Entra ID participant CA as Conditional Access participant WAM User->>CloudAP: 1. Interactive sign-in (Hello, password, FIDO2) CloudAP->>TPM: 2. Sign authorization JWT with dkpriv TPM-->>CloudAP: 3. Signed assertion CloudAP->>Entra: 4. Issuance request (signed assertion) Entra->>CA: 5. Evaluate device + user + risk claims CA-->>Entra: 6. Issuance permitted Entra-->>CloudAP: 7. PRT + session_key encrypted under tkpub CloudAP->>TPM: 8. Unwrap session_key with tkpriv Note over CloudAP,WAM: Session key now resident -- WAM, browser SSO, and CAE all derive from it

A user provides an interactive credential -- a Hello gesture, a password, a FIDO2 security key. The CloudAP plugin in lsass constructs a JWT carrying the user's authorization material and asks the TPM to sign it with dkpriv. That signed assertion goes to Microsoft Entra ID. Entra evaluates Conditional Access; if the device, the user, and the risk profile pass policy, Entra returns a PRT (a long-lived JWT) and a fresh session key encrypted under tkpub. The TPM unwraps the session key with tkpriv. The session key now lives on the device, in CloudAP's hot path, available for every broker to use.

The symmetric key Microsoft Entra ID generates per PRT mint and returns to the device encrypted under `tkpub`. After the TPM unwraps it with `tkpriv`, the session key is the *proof-of-possession key* for the PRT lifetime: every renewal request, every `x-ms-RefreshTokenCredential` cookie, and every app-token request signed via the Web Account Manager is HMAC-signed by a key *derived from* the session key via SP800-108 KDF [@prt-msft-learn] [@ms-oapxbc-jwt].

The session key is the part the rest of this article keeps coming back to. It is the artifact that, in 2020, three independent researchers would prove the TPM was not protecting in the way Microsoft's documentation implied.

Once the session key is on the device, the Web Account Manager (WAM) -- the user-mode broker process that handles native-app token requests -- and the browser SSO surface used by Edge, Chrome, and Firefox can mint subordinate artifacts. The most interesting one is a cookie.

The Windows user-mode broker that mediates access-token requests from native applications to Microsoft Entra ID. WAM presents each app-token request alongside a PRT-derived signed assertion, eliminating the per-app refresh-token cache that the pre-2016 ADAL design required. WAM is the Windows analogue of the Microsoft Enterprise SSO plug-in for Apple devices [@prt-msft-learn] [@apple-sso-plugin-learn]. The HTTP cookie Edge, Chrome, and Firefox attach to requests against `login.microsoftonline.com` and a small set of Microsoft cloud surfaces. It carries a JWT signed with `alg: HS256` whose header field `kdf_ver` indicates whether the cookie used KDFv1 or KDFv2 derivation [@ms-oapxbc-jwt]. The cookie is what makes the third sign-in in the §1 hook -- the silent Edge sign-in to `outlook.office.com` -- not require a credential prompt.

Inside that cookie, the signing key is derived from the session key via the SP800-108 key-derivation function. The label is the constant string AzureAD-SecureConversation. The context (ctx) is a per-cookie value chosen by the client. The MS-OAPXBC protocol specification gives the rule verbatim: under KDFv2, "the client MUST use SHA256(ctx || assertion payload) instead of ctx as the context for deriving the signing key" [@ms-oapxbc-jwt]. We will come back to that sentence in §6, because it is the sentence.Microsoft Learn documents TPM 2.0 as the recommended version for all Microsoft Entra device-registration scenarios on Windows 10 or newer, and states that after the Windows 10 1903 update, Microsoft Entra ID no longer uses TPM 1.2 for any of the PRT keys due to reliability issues. In practice, TPM 2.0 is the only supported configuration on Windows 10 1903 or higher [@prt-msft-learn].

On supported hardware, both dkpriv and tkpriv are non-extractable TPM 2.0 keys. On a device with Microsoft Pluton (a TPM 2.0 implementation embedded in the SoC), the same model applies; Pluton is a TPM 2.0 implementation, not a replacement. On non-TPM Windows -- a virtual machine without a vTPM, a desktop where the TPM is disabled, certain consumer SKUs -- DPAPI is the fallback. DPAPI-protected keys live in user-profile state and can be unwrapped with the user's credentials, which is a meaningfully weaker contract than TPM non-extractability. We will come back to that distinction in §9.

The shorthand "the PRT cookie is DKey-signed" was already imprecise before July 2021, and it became actively wrong after the KDFv2 update. The cookie is HMAC-signed with `alg: HS256`, using a symmetric key derived from the *session key* via SP800-108 KDF, not signed with the asymmetric device key. blog.3or.de's reverse-engineering captures the post-2021 mechanic precisely: "Before CVE-2021-33779, the key to sign the PRT Cookie was derived from the session key using a function that only required a client-chosen `ctx` value. Although the session key and derivation process were handled inside the TPM, the derived key was managed outside the TPM" [@dimi-3or-de-kdfv2]. The asymmetric device key only signs the PRT *issuance* request; everything afterwards is HMAC over a derived key.

If both keys live in the TPM and the cookie is signed with a key derived from a TPM-resident session key, the whole architecture should make Pass-the-PRT impossible. In 2020, three independent researchers proved it didn't.

5. When TPM-binding is not enough

In July 2020, two researchers, working independently, asked the same question: if the session key is in the TPM, can I still mint a PRT cookie?

The answer, on the architecture Microsoft shipped at the time, was yes -- and the answer came from three angles in less than two months.

A Primary Refresh Token can be compared to a long-term persistent Ticket Granting Ticket (TGT) in Active Directory... the Primary Refresh Token however can be used to authenticate to any application, and is thus even more valuable. This is why Microsoft has applied extra protection to this token. -- Dirk-jan Mollema, 21 July 2020

Lee Christensen at SpecterOps, mid-July 2020. Christensen's blog post -- "Requesting Azure AD Refresh Tokens on Azure AD-joined Machines for Browser SSO" -- documented a path through a Component Object Model interface, IProofOfPossessionCookieInfoManager.GetCookieInfoForUri, that returned a fully signed x-ms-RefreshTokenCredential cookie to a user-mode caller [@christensen-specterops-2020]. The CLSID is {a9927f85-a304-4390-8b23-a75f1c668600}; the implementation lives in MicrosoftAccountTokenProvider.dll; the workflow rides through BrowserCore.exe over a named pipe. Christensen released the proof-of-concept as RequestAADRefreshToken on GitHub [@gh-requestaadrefreshtoken]. An attacker -- specifically, a process running as the signed-in user -- could call the COM interface, lift the cookie, and paste it into a browser running anywhere on the planet.

The COM-API path did not require admin. It did not require touching the TPM. It did not need to know anything about the session key. The operating system politely produced a signed cookie because that is what the COM API was built to do, and the contract did not distinguish the legitimate browser from the attacker process.

Dirk-jan Mollema, 21 July 2020. A week later, Mollema published "Abusing Azure AD SSO with the Primary Refresh Token" on dirkjanm.io. Mollema's framing was different: he wanted to understand the PRT as a forensic artifact. The blog opens with the TGT analogy quoted above and explicitly attributes parallel discovery to Christensen [@mollema-prt-2020-07]. The toolchain he documented, ROADtoken, lived inside the larger ROADtools framework that he was building for offensive Azure AD research [@gh-roadtools]. The threat model was the same as Christensen's: an attacker on the live device could mint cookies, and the TPM was not in the way.

Mollema, 5 August 2020. This is the blog that mattered most. In "Digging further into the Primary Refresh Token," Mollema reverse-engineered aadcloudap.dll. He isolated the session-key handling, the cookie-construction routine, the SP800-108 derivation call, the eventual BCryptKeyDerivation-then-HMAC flow. And he wrote the sentence that, in retrospect, defined the next year of Microsoft's response: "despite the session key of the PRT is stored in the TPM whenever possible, this doesn't prevent us from extracting the PRT and the required information to create SSO cookies. The result of this is that regardless of whether the PRT is protected by the TPM or not, with Administrator access it is possible to extract the PRT from LSASS and use the PRT on a different device than it was issued to" [@mollema-prt-2020-08].

despite the session key of the PRT is stored in the TPM whenever possible, this doesn't prevent us from extracting the PRT and the required information to create SSO cookies. -- Dirk-jan Mollema, 5 August 2020

The reason is the most important thing in this article. The session key never left the TPM. But the signing key derived from the session key did. The TPM dutifully performed an SP800-108 derivation -- HMAC-SHA256 with the label AzureAD-SecureConversation and the client-chosen ctx value -- and returned the derived key to caller memory. The TPM was protecting the root of the derivation, not the output of it. Once the derived key materialized in lsass, an admin-with-debug-privilege attacker could simply read it.

Around the same time, Benjamin Delpy -- the author of Mimikatz -- picked up Mollema's "challenge" of recovering PRT data from lsass. Two days after Mollema's 5 August post, that collaboration produced the Mimikatz release tagged 2.2.0-20200807, which added the sekurlsa::cloudap and dpapi::cloudapkd modules [@gh-mimikatz]. The tag URL itself was later collapsed in GitHub's modern UI -- it returns 404 today, almost certainly because of repeated takedown requests during the Azure-PRT release period -- but a Wayback Machine snapshot from 20 September 2020 preserves the release page and proves the tag existed at the time [@wayback-mimikatz-tag].The GitHub URL https://github.com/gentilkiwi/mimikatz/releases/tag/2.2.0-20200807 returns HTTP 404 in the current GitHub UI; the modern releases list starts at 2.2.0-20210729. The Wayback snapshot at web.archive.org/web/20200920005113/... preserves the release page (including the "prt3" animated demonstration GIF). Nestori Syynimaa's AADInternals post and Mollema's 5 August 2020 blog both reference the same tag URL, which is how we know the artifact was real [@wayback-mimikatz-tag] [@syynimaa-aadinternals-prt] [@mollema-prt-2020-08].

Nestori Syynimaa and AADInternals, August through September 2020. Syynimaa's AADInternals PowerShell module shipped Get-AADIntUserPRTToken as part of v0.4.1 alongside the disclosure. On 29 September 2020, AADInternals' blog post about the tool gained an inline update: "It seems that PRT tokens must now include the request_nonce. If not, Azure AD sends a redirect with sso_nonce which must be added to the PRT token. This means that without access to session key, PRT tokens can't be used anymore" [@syynimaa-aadinternals-prt]. That update is the first observable Microsoft mitigation: Entra ID began demanding that PRT cookies contain a server-issued nonce. It bought time. It did not solve the architectural problem.

sequenceDiagram participant Attacker participant LSASS participant TPM participant COM as IProofOfPossessionCookieInfoManager participant Entra as Microsoft Entra ID Note over Attacker,LSASS: Attacker has user or admin on the live device Attacker->>LSASS: sekurlsa::cloudap (admin path) LSASS-->>Attacker: PRT + derived signing key + context Note over Attacker: Or, parallel user-only path: Attacker->>COM: GetCookieInfoForUri(target_url) COM-->>Attacker: Pre-baked x-ms-RefreshTokenCredential Note over Attacker: Cookie is now portable Attacker->>Entra: Replay cookie from an attacker-controlled host Entra-->>Attacker: SSO honored, access token issued

Note: With admin on an Entra-joined device in summer 2020, an attacker could lift the PRT and the derived signing key from lsass, mint fresh x-ms-RefreshTokenCredential cookies on any host they controlled, and pass Conditional Access checks that included the cloned DeviceId claim. Even without admin, the COM-API path returned signed cookies to a user-context process. The TPM was busy doing exactly what its contract said, and that contract was insufficient.

The community quickly settled on a name for this class: Pass-the-PRT. By analogy to Pass-the-Hash and Pass-the-Ticket, the attack is "lift a long-lived authentication artifact from one host, present it as your own elsewhere." For a credential that the entire cloud sign-in stack was about to trust, the implications were severe.

By September 2020 Microsoft had bolted a nonce onto the cookie. By July 2021 they had something architecturally different: a single SHA-256 over the cookie's full payload that killed off-device Pass-the-PRT for good.

6. KDFv2 and the death of off-device Pass-the-PRT

The fix Microsoft shipped on 13 July 2021 fits on one line.

The CVE is CVE-2021-33779. NIST's National Vulnerability Database describes it as "Windows AD FS Security Feature Bypass Vulnerability" and provides no further public detail [@nvd-cve-2021-33779]. Microsoft's own KDFv2 documentation ties the patch explicitly to that CVE: "On July 13, 2021, updates were released for AD FS to address token replay attacks, as described in CVE-2021-33779. These updates introduce new settings to enable and control a new, Key Derivation Function (KDF) called KDFv2" [@kdfv2-learn].

The version-2 key-derivation rule introduced for the `x-ms-RefreshTokenCredential` cookie on 13 July 2021. Under KDFv2, the SP800-108 KDF context is `SHA256(ctx || assertion_payload)` rather than the bare client-chosen `ctx` value. The JWT header field `kdf_ver` carries the value `2` to indicate that KDFv2 was used. KDFv1 is preserved for backward compatibility but is disabled by default on a service that has been moved to "Enforced" mode [@ms-oapxbc-jwt] [@kdfv2-learn].

A small subtlety lives in the attribution. NVD names AD FS. The community-side coverage -- blog.3or.de, Mollema's TROOPERS 22 deck, AADInternals -- names PRT-cookie forgery. The Microsoft KDFv2 page sits in the middle: it ties the patch to CVE-2021-33779 and walks through the same derivation change that closed off-device Pass-the-PRT, but it does not use the term "Pass-the-PRT" on the page itself. We will keep the hedge in mind.

NVD's one-line description -- "Windows AD FS Security Feature Bypass Vulnerability" -- is authoritative for the federal CVE record [@nvd-cve-2021-33779]. The community attribution to the Pass-the-PRT class comes from independent reverse-engineering: blog.3or.de's analysis is the most precise public reading. Both can be true; KDFv2 is the rollout vehicle, and it ships into both AD FS (the on-prem federation server) and the Microsoft Entra ID PRT path. The article reads CVE-2021-33779 as "the rollout vehicle for KDFv2," not as a one-to-one CVE-to-attack mapping.

The load-bearing rule is one sentence. MS-OAPXBC §3.2.5 puts it like this: "If the client chooses to use KDFv2, the client MUST use SHA256(ctx || assertion payload) instead of ctx as the context for deriving the signing key. The client MUST also add the JWT header field kdf_ver with value set to 2 to communicate that KDFv2 was used for creating the derived signing key" [@ms-oapxbc-jwt].

To see why that line matters, picture what the attacker in §5 was actually copying. The attacker lifted the derived signing key out of lsass. The derived signing key was, under KDFv1, a function of the session key (TPM-resident) and the client-chosen context ctx (any 256 bits the attacker liked). Any cookie the attacker built using the same ctx would verify against the same derived key. The attacker could pick ctx first, derive the key once, and stamp out as many cookies as they wanted.

Under KDFv2, the context is no longer arbitrary. The context is SHA256(ctx || assertion_payload). The assertion_payload is the JWT body the cookie is trying to assert. Change a single claim in the body, and the SHA-256 hash changes, and the SP800-108 derivation produces a different key. A key derived for one cookie cannot sign any other cookie. There is nothing to precompute.

Note: The architectural insight is the same one Kerberos learned with PA-FX-FAST and TLS learned with channel binding: a session-key derivation must be bound to the message being signed, not just to a per-session label. Before KDFv2, the derivation contract was "derive a key for this session, then sign anything." After KDFv2, the contract is "derive a key for this specific message." An attacker who exfiltrates the session key off-device cannot precompute a useful signing key; an attacker who exfiltrates a derived signing key for one cookie cannot reuse it for the next. Off-device Pass-the-PRT is dead.

The residual is also explicit. The attacker who is still on the device -- still has a process running as the user or as SYSTEM -- can ask CloudAP to mint a fresh cookie. The TPM happily performs the new SHA-256-bound derivation, because that is its job; CloudAP returns the signed cookie to the calling process, because that is its job. The blog.3or.de reverse-engineering names this class precisely: "This attack, referred to as Pass-the-PRT-Cookie, still works today but requires presence on the targeted device" [@dimi-3or-de-kdfv2]. Mollema's TROOPERS 22 talk calls the same residual "Cookie-on-Demand" and walks the in-place cookie-minting flow on a fully patched Entra-joined endpoint [@troopers22-mollema-pdf] [@troopers22-abstract].

The minimal cryptographic statement of the fix is small enough to write down. Let $H$ be HMAC-SHA256, $k_s$ be the session key, $\ell$ be the constant label AzureAD-SecureConversation, $\mathit{ctx}$ be the per-cookie context, and $p$ be the JWT body to be signed. Under KDFv1, the derived signing key was $k_d = H(k_s, \ell \parallel \mathit{ctx})$. Under KDFv2, the derived signing key is $k_d = H(k_s, \ell \parallel \mathrm{SHA256}(\mathit{ctx} \parallel p))$. The difference is exactly the hash of the message body inside the derivation context.

{` // Illustrative; do NOT use as production crypto. const crypto = require('crypto');

function sha256(buf) { return crypto.createHash('sha256').update(buf).digest(); } function hmac(key, data) { return crypto.createHmac('sha256', key).update(data).digest(); }

function deriveKdfv2SigningKey(sessionKey, ctx, assertionPayload) { const label = Buffer.from('AzureAD-SecureConversation', 'utf8'); const boundCtx = sha256(Buffer.concat([ctx, assertionPayload])); // SP800-108 KDF in counter mode is more involved; one HMAC stands in here. return hmac(sessionKey, Buffer.concat([label, boundCtx])); }

// The signing key is now uniquely tied to assertionPayload. `}

A side-by-side flowchart makes the structural shift legible.

flowchart LR subgraph KDFv1 ["KDFv1 (pre-July 2021)"] A1[Session key in TPM] --> A2["SP800-108 KDF
label = AzureAD-SecureConversation
context = ctx"] A2 --> A3[Derived signing key] A3 --> A4[HMAC over any JWT body] end subgraph KDFv2 ["KDFv2 (July 2021+)"] B1[Session key in TPM] --> B2["SP800-108 KDF
label = AzureAD-SecureConversation
context = SHA256 of ctx || payload"] B2 --> B3[Derived signing key] B3 --> B4[HMAC over the specific JWT body] end

KDFv2 killed off-device replay. It did not kill the on-device signing oracle, and it did not shorten the PRT's 90-day lifetime. The next generation tackled both -- not by closing the on-device gap, which is architecturally hard, but by making issued access tokens revocable in seconds.

7. The seam: CAE, Token Protection, Cloud Kerberos Trust

By 2022 the PRT was the credential. The work that remained was to make every artifact issued from it -- every access token, every Kerberos TGT, every Conditional Access claim -- share the same device-binding contract.

That work has three named pieces, and a quiet rename in the middle.

Continuous Access Evaluation

Continuous Access Evaluation entered public preview in late 2020, a few months after Mollema's August blog. By 10 January 2022, Microsoft announced General Availability across Microsoft Entra ID; the announcement post came from Alex Simons, Corporate Vice President for Program Management in the Microsoft Identity Division [@twu-cae-ga-mirror]. CAE is the mechanism by which a long-lived access token issued from a PRT can be invalidated in seconds when something critical changes.

An industry-standard near-real-time revocation channel for OAuth access tokens, implemented by Microsoft Entra ID as a claim-challenge protocol between Entra and CAE-aware resource providers. CAE is anchored in the OpenID Continuous Access Evaluation Profile (CAEP) [@caep-openid-spec]. CAE-aware resources reject a previously valid access token when Entra signals one of five critical events: user account deletion or disablement, password change, MFA enablement, admin token revocation, or high user-risk classification. Microsoft Learn documents an event-propagation upper bound of 15 minutes, with IP-location enforcement instantaneous [@cae-learn].

Mechanically: a CAE-aware client requests an access token from Entra ID, and Entra issues a long-lived token -- up to 28 hours rather than the conventional one hour -- with a xms_cc claim signaling that the bearer understands the protocol. The resource provider serves requests against that token. When something changes -- the user gets disabled in HR, the IT admin resets the password, a sign-in trips a high-risk classification -- Entra ID fires a CAEP event. The resource provider receives the event and, on the next request, returns an HTTP 401 with a WWW-Authenticate claim challenge. The client returns to Entra, presents the PRT, and asks for a fresh access token; Entra evaluates Conditional Access at that moment and either issues a new token or refuses. The user sees, at worst, a fast re-authentication; the access window for the revoked credential is on the order of seconds rather than the access token's original lifetime.

sequenceDiagram participant Admin participant Entra as Microsoft Entra ID participant Resource as Exchange Online participant Client Admin->>Entra: Force password reset for user Entra-->>Resource: CAEP event: Credential Change Client->>Resource: GET /mail (with long-lived token) Resource-->>Client: 401 WWW-Authenticate (claim challenge) Client->>Entra: Refresh token + claim challenge Note over Entra: Re-evaluate Conditional Access against current user state Entra-->>Client: New short access token (or deny) Client->>Resource: GET /mail (new token) Resource-->>Client: 200 OK

The initial CAE deployment was constrained: only Exchange Online, SharePoint Online, and Teams understood the claim-challenge protocol at GA [@cae-learn]. Microsoft Graph followed. Other workloads still honor an access token until natural expiry, which is the open scope of the §9 caveat list.

Token Protection

If CAE is the time dimension, Token Protection is the space dimension. The Conditional Access feature, also referred to as "token binding," demands that an app-token request originate from a device-bound session token -- in practice, a PRT-signed assertion. The Microsoft Learn page defines it as a "Conditional Access session control that attempts to reduce token replay attacks by ensuring only device bound sign-in session tokens, like Primary Refresh Tokens (PRTs), are accepted by Microsoft Entra ID when applications request access to protected resources" [@token-protection-learn].

A Microsoft Entra Conditional Access session control that enforces device-bound sign-in for app-token requests against supported resources. Token Protection is the per-app analogue of the PRT's device-binding contract: every access token must originate from a device-bound session token. As of 2026, Token Protection is generally available on Windows for Exchange Online, SharePoint Online, Teams, Azure Virtual Desktop, and Windows 365; it is in preview on iOS/iPadOS and macOS via the Microsoft Enterprise SSO plug-in [@token-protection-learn] [@apple-sso-plugin-learn].

The current scope is intentionally narrow. Native applications and the Microsoft Enterprise SSO plug-in for Apple devices both implement the device-bound assertion. Browsers do not. A browser visiting a Microsoft cloud resource still rides the x-ms-RefreshTokenCredential cookie path. Closing that gap is what Device Bound Session Credentials -- the cross-vendor web standard Microsoft co-designed with Google -- exists to do, and we will return to that in §10.

Cloud Kerberos Trust

The third piece bridges the cloud-mediated PRT path back to on-prem Kerberos. The mechanism is simple in framing and intricate in implementation: Microsoft Entra ID provisions a virtual AzureADKerberos read-only domain controller object inside the on-prem Active Directory domain, and an Entra-signed partial Kerberos TGT issued to a Hello-for-Business-signed-in device can be exchanged at any on-prem DC for a fully-formed TGT carrying SID and authorization data.

A Microsoft Entra ID mechanism by which Entra ID can mint Kerberos TGTs for one or more Active Directory domains. An Entra-signed partial TGT carries the user's identity; an on-prem domain controller, holding the cryptographic shared key represented by the virtual `AzureADKerberos` RODC computer object, completes the TGT with on-prem SID and group claims. The bridge requires Windows 10 21H2 (with KB5010415+) or later, and a Windows Server 2016+ functional level on the domain controller; it shipped in April-June 2022 [@cloud-kerberos-trust-learn] [@entra-passwordless-onprem].

The Microsoft Learn deployment guide is explicit about the AzureADKerberos object's role: "When Microsoft Entra Kerberos is enabled in an Active Directory domain, an AzureADKerberos computer object is created in the domain. This object: Appears as a read only domain controller (RODC) object, but isn't associated with any physical servers; Is only used by Microsoft Entra ID to generate TGTs for the Active Directory domain" [@cloud-kerberos-trust-learn]. The architectural property to notice is that the user's NTLM hash is not the binding key. Microsoft Entra ID never holds the on-prem NTLM hash; the cryptographic root is the AzureADKerberos RODC's keys, which Entra and the on-prem domain controller share without involving any user-side long-term secret.

Cloud Kerberos Trust is the Kerberos PKINIT pattern from RFC 4556 [@rfc-4556-pkinit], reframed: the cloud identity provider is the public-key initial authenticator, and Entra ID issues the partial TGT exactly as a PKINIT-aware KDC would.

The Azure AD to Microsoft Entra ID rename

In the middle of all this, on 11 July 2023, the brand changed. Microsoft renamed Azure Active Directory to Microsoft Entra ID and consolidated several adjacent products under the Microsoft Entra umbrella [@entra-rename-2023]. The article uses "Microsoft Entra ID" throughout; in primary sources from before July 2023, the same product is "Azure AD." The rename is real, and it matters when citing older documentation, but it does not change the protocol surface.

The seam restated

With Continuous Access Evaluation, Token Protection, and Cloud Kerberos Trust in place, the picture from §1 fills out. Every cloud-mediated identity feature on a modern Windows endpoint either issues, refreshes, presents, or evaluates a PRT. The PRT itself is the asymmetric handshake that binds the device. CAE makes the time dimension elastic. Token Protection makes the access surface device-bound at the resource-request layer. Cloud Kerberos Trust makes the on-prem Kerberos surface reachable from a PRT-bearing device.

Key idea: The PRT is the cryptographic seam: a single device-bound credential, issued at first sign-in, that every other identity artifact on the device references. CAE, Token Protection, and Cloud Kerberos Trust are not three different bindings; they are three different ways the same PRT contract reaches three different surfaces -- the revocation surface, the per-resource access-token surface, and the on-prem Kerberos surface.

A small comparison matrix makes the support story explicit.

Resource / scenario	CAE-aware	Token Protection (Windows GA)	Cloud Kerberos Trust
Exchange Online	Yes	Yes	n/a
SharePoint Online	Yes	Yes	n/a
Microsoft Teams	Yes	Yes	n/a
Microsoft Graph	Yes	Not enforced	n/a
Azure Virtual Desktop	Partial	Yes	n/a
Windows 365	Partial	Yes	n/a
On-prem file share	n/a	n/a	Yes
Browser (any Microsoft cloud)	Indirect via resource	No (native apps only)	n/a

That is what the PRT does. But four sibling articles in this series describe identity surfaces the PRT does not cover. Before we celebrate the seam, we have to be honest about where it stops.

8. Where PRT is not the answer

The PRT carries device state, MFA state, and Conditional Access claims for the cloud-mediated identity path. There is no clause in that sentence that mentions on-prem Kerberos, NTLM hashes, local admin authorization, or workload identities -- and that is the point.

Five surfaces the PRT does not cover, in the order operators most often confuse them:

On-prem Kerberos via the on-prem KDC. A Windows user signing into a domain-joined or hybrid-joined machine still mints a Kerberos TGT against the on-prem Key Distribution Center on Windows logon. The PRT path is parallel, not replacement. The user's downstream kerberos.dll ticket cache is populated by Kerberos AS_REQ/AS_REP exchanges between the workstation and the on-prem DC; the PRT lives in CloudAP's memory in lsass and does not influence that flow. Cloud Kerberos Trust adds a bridge from PRT to on-prem TGT for users whose primary credential is in Entra; it does not retire the on-prem Kerberos path.

Credential Guard and LSAISO. Credential Guard, introduced on the Enterprise SKU of the original Windows 10 release in 2015, isolates NTLM hashes and Kerberos long-term keys inside the Local Security Authority Isolated Subsystem (LSAISO), which runs in Virtual Trust Level 1 (VTL1) on top of the Hyper-V hypervisor [@credential-guard-learn] [@credential-guard-itpro-2016-wayback]. Credential Guard predates the cloud-identity model entirely; its threat model is on-prem credential theft via long-term-key extraction from lsass. The load-bearing distinction for the threat model is this: PRT material does NOT live in LSAISO. It lives in normal lsass.exe under CloudAP. Mollema's August 2020 extraction worked because the PRT's session-key handling is in the same address space as ordinary user processes that hold debug privilege; LSAISO did not move there. Treat "I have Credential Guard enabled" and "my PRT is hardware-isolated" as independent statements.The LSAISO isolation contract is for on-prem credentials -- NTLM hashes, Kerberos krbtgt keys, the kinds of long-term secrets that the 2010s-era "Pass-the-Hash" tooling was designed to extract. The PRT's session key is a per-PRT artifact that lives in CloudAP's memory under normal LSASS. Credential Guard protects you against a different attack class. Get it for those reasons; do not get it expecting PRT-class mitigation.

Adminless and local-admin removal. "Adminless" is an authorization pattern -- removing standing local-admin rights, requiring just-in-time elevation -- not an authentication pattern. It is orthogonal to the PRT. A device can be PRT-bound and still have a thousand local admins; a device can have zero local admins and still mint PRTs. The PRT addresses "who is signing in;" Adminless addresses "what they can do once signed in." Conflating them is a common rhetorical move in Microsoft documentation and a common source of confusion in audits.

App Identity, managed identities, and workload identities. Workloads in Microsoft cloud environments authenticate through a separate broker path: the Azure Instance Metadata Service (IMDS) on VMs, Workload Identity Federation for cross-cloud Kubernetes flows, managed identities on Functions and App Service. None of these always involve a PRT. A managed identity is a non-human principal in Entra ID with a system-issued credential, not a device-bound JWT, and the broker path that produces its access tokens is structurally different. The App Identity sibling article addresses that surface in detail.

Remote Credential Guard versus Azure AD RDP sign-in. These two are often introduced together because both involve credentials over RDP, and conflating them is the load-bearing threat-model error in this section. Remote Credential Guard redirects Kerberos credentials over the RDP hop: the client's TGT is reachable to the remote mstsc session via a CredSSP-mediated redirection mechanism, so that the remote session can fetch downstream service tickets without re-prompting. It does not transport PRT material across the connection. Azure AD RDP sign-in -- the separate scenario where the RDP host itself is Entra-joined and accepts an Entra sign-in at session establishment -- is the PRT-mediated path, and it happens at the host side, not as a redirection from the client.

Note: If your threat model says "I am redirecting credentials over RDP, therefore my PRT is exposed," you are reading the Remote Credential Guard documentation wrong. Remote Credential Guard ferries Kerberos tickets between the client mstsc and the remote session host; the PRT lives in the client's LSASS and does not cross the RDP wire under that feature. Azure AD RDP sign-in is the separate, host-side scenario where the remote session establishes its own PRT against Entra. The Stage 0a audit flagged this conflation as one of the most common errors in the wild, and the Microsoft Learn pages are not co-located.

The pattern across all five is the same. PRT is the cloud-mediated authentication path. Kerberos is the on-prem authentication path. Credential Guard is the on-prem long-term-credential isolation path. Adminless is the local-authorization pattern. App Identity is the workload-authentication path. Remote Credential Guard is an on-prem credential redirection over RDP. They run alongside each other on a modern Windows endpoint; they answer different questions. Mistaking the PRT for any of them is how good threat models go sideways.

9. Theoretical limits

The single most important sentence in the W3C Device Bound Session Credentials draft is also the single most important sentence about the PRT -- and it does not mention the PRT at all.

DBSC will not prevent temporary access to the browser session while the attacker is resident on the user's device. The private key should be stored as safely as modern operating systems allow, preventing exfiltration of the session private key, but the signing capability will likely still be available for any program running as the user on the user's device. -- W3C Web Application Security Working Group, Device Bound Session Credentials draft

That paragraph is the architectural lower bound. Every device-bound session credential ever proposed inherits it. The PRT is no exception. Five bounded promises follow.

1. The on-device-attacker floor is architectural. A hardware-bound key whose signing surface is reachable by a same-privilege process can be used by that process for the lifetime of its presence. The TPM holds the key; the operating system mediates the signing operation; any process the operating system trusts to talk to CloudAP can ask for a signature. KDFv2 closed off-device replay because the signing key is now uniquely bound to one cookie -- but the on-device process can simply ask for the next signature. The DBSC working draft is explicit that this is the floor for the entire class [@dbsc-w3c-draft]. The composition argument we will name in §10 is the practical response.

2. Non-TPM Windows reopens the pre-2021 attack class. When the device key and transport key are protected by DPAPI rather than by a TPM 2.0, the key material can be unwrapped with the user's profile credentials. Pre-2021 Pass-the-PRT becomes available again because the attacker is no longer trying to extract a derived signing key from lsass -- they are extracting the root of the derivation from disk. Microsoft Learn names "TPM 2.0 on Windows 10 1903 or higher" as the supported configuration; everything else is best-effort [@prt-msft-learn]. TPM 2.0 is load-bearing, not optional, for the security claims this article makes.

3. Phishing-resistance inheritance is one-shot. The PRT records the authentication strength of the issuing credential -- whether the user signed in with Hello for Business, a FIDO2 key, a password, or a password plus an MFA factor. The mfa claim on the PRT carries this through to downstream tokens. If the user authenticated with a phishable factor at issuance, every downstream access token transitively trusts that weaker factor for the PRT lifetime. The PRT does not upgrade. To enforce phishing-resistant authentication, the deployer must configure Conditional Access Authentication Strengths at the Entra ID side -- the PRT will record what arrived, but it will not refuse to mint downstream tokens because the issuing factor was weak.

4. CAE coverage is not universal. Continuous Access Evaluation is the time dimension of revocation -- but only for CAE-aware resources. Exchange Online, SharePoint Online, Teams, and Microsoft Graph honor the claim-challenge protocol; many other workloads still treat the access token as valid until its native expiry [@cae-learn]. If your tenant's risk surface is a CAE-unaware first- or third-party application, the deployment-time guarantee is the access token's natural lifetime, not 15 minutes.

5. The PRT lifetime is 90 days by design. A device offline for more than the PRT lifetime cannot silently refresh; the user will see a re-authentication prompt the next time the device reaches Entra ID. That window is the Conditional Access trade-off: longer windows reduce friction for travelers and offline scenarios; shorter windows reduce the attacker's window after a device compromise. Microsoft chose 90 days; the deployer can tune it via Conditional Access Sign-In Frequency policies but cannot move it independently of the broader refresh-token configuration.

Note: To approximate the ideal -- a device-bound, near-real-time-revocable, phishing-resistant cross-app SSO credential -- a deployer composes: PRT (device binding) + CAE (near-real-time revocation) + Token Protection (per-resource device binding for native apps) + Authentication Strengths (Conditional Access policy that upgrades phishing resistance at issuance) + DBSC (per-origin web defense once it is available). No single artifact closes all five gaps; composition is the deployer's job, and the gaps in any one artifact are the joints another is supposed to cover.

Four of the five limits are bounded -- TPM rollout, claim-strength policy, CAE rollout, offline cadence. They get smaller as Microsoft ships, as administrators tighten policy, as more resources become CAE-aware. One is architectural and applies to every device-bound session credential ever proposed: same-device admin equals access while the admin has it. That is the open problem the next section traces.

10. Open problems

Five open problems sit on the PRT model right now. None of them have a "just ship a patch" answer.

Cookie-on-Demand on the live device. The architectural defense is bounded by the §9 floor. Mollema's TROOPERS 22 talk makes the case that trustlet-level isolation of the PRT signing path -- moving the CloudAP cookie-construction code from normal lsass into an isolated user-mode environment in VTL1, the same security boundary that protects LSAISO -- would close the residual class [@troopers22-mollema-pdf]. Microsoft has not shipped that move. The cost is non-trivial: every downstream broker (WAM, the browser SSO surface, every native app that talks to CloudAP) would need to route through a trustlet-mediated signing API, and the trustlet itself would need to make policy decisions about which callers are entitled to a cookie. The benefit is real -- it removes the same-user-attacker class for the most powerful credential on the device -- but the engineering cost has not been deemed worth it as of 2026.

Cross-vendor near-real-time revocation. CAE works inside the Microsoft Entra perimeter. If a user is compromised at Entra and Microsoft revokes the session, the signal does not automatically propagate to Okta-protected resources, Google Workspace, AWS IAM Identity Center, or any other identity provider the same user happens to have a session against. The standardization vehicle exists: the OpenID Shared Signals Framework defines a cross-IdP event-receiver protocol, and the OpenID CAEP specification provides the event taxonomy [@caep-openid-spec]. The bilateral transmit/receive deployments are sparse. Stage 3 of the research pipeline found no public production cross-vendor CAE deployment that wires Entra revocation events into a non-Microsoft IdP. The standard is ready; the deployments are not.

DBSC and PRT composition for browser SSO. Google's Device Bound Session Credentials began general availability for Chrome 146 on Windows in late 2025, with Microsoft co-designing the standard through the W3C process [@dbsc-google-blog] [@dbsc-w3c-draft]. The Chrome developer documentation references Chrome 145 as the rollout-start build, and the Google security blog references Chrome 146 as the GA build; the version drift reflects a phased rollout, and the article uses the later figure [@dbsc-chrome-developer]. The composition question is unresolved: when a browser on Windows visits login.microsoftonline.com, the request will carry both a DBSC-bound short cookie (per-origin) and an x-ms-RefreshTokenCredential cookie from the WAM attachment path. Which binding wins, and how the two bindings are composed in the resource provider's evaluation, has not been publicly documented. The Stage 3 research found no Microsoft engineering blog explaining the contract.The Chrome developer documentation page on DBSC cites "Chrome 145" while the Google Security Blog post about DBSC GA cites "Chrome 146." The two pages are co-published by Google; the security blog is dated later in 2025 and represents the GA figure. Stage 4 flagged this as an internal-inconsistency artifact. The article uses Chrome 146 for the GA framing and notes Chrome 145 as the rollout-start build [@dbsc-chrome-developer] [@dbsc-google-blog].

A modern Windows Edge session against `login.microsoftonline.com` already carries `x-ms-RefreshTokenCredential`. A modern Chrome 146 session on Windows carries a DBSC-bound short cookie for the same origin. Token Protection enforces device binding for *native-app* access-token requests, not browser ones. The three bindings are not redundant -- they cover different surfaces -- but Microsoft has not published a precedence rule or a unified "this is how the browser proves device binding to Entra" reference, and the open question is whether the W3C DBSC draft will be the home for that contract or whether Microsoft will document the composition independently. The composition story for browser SSO is, in 2026, the single most active open problem in this space.

PRT-aware Conditional Access for AI agents and workload identities. As organizations deploy autonomous AI agents that act on behalf of users -- Copilot agents, Office Studio bots, third-party LangGraph-style systems -- the identity story is genuinely unsettled. Some agents authenticate as the user via delegated permissions on a PRT-mediated path. Others authenticate as their own service principal via Workload Identity Federation. Conditional Access policies designed for human users -- "require compliant device, require MFA, require sign-in frequency under four hours" -- do not map cleanly to either. Microsoft Entra Agent ID entered public preview at Ignite 2025 with Conditional Access extended to agent identities via custom security attributes and agent-identity-blueprint policy targeting [@entra-agent-id-conditional-access], but the precise PRT-side claim semantics for agent-on-behalf-of-user vs autonomous-agent paths are still settling. The Conditional Access for AI Agents sibling article addresses the evolving model in detail.

PRT across RDP. There is no clean "redirect PRT" primitive analogous to Remote Credential Guard's Kerberos redirection. Inside an RDP session to an Entra-joined host, a user can perform an Azure AD RDP sign-in that mints a new PRT at the host -- but the client's PRT does not transit the RDP hop. Forensic and operational tooling that wants to know "what PRT does this remote user have, and is it the same as the client's?" has to query both endpoints separately. Active Microsoft work in this area is referenced in Mollema's TROOPERS 22 deck, but no public solution has shipped.

These five problems share an architecture: they are all about composition. The PRT is one of several primitives that have to work together. The next section walks the practical guide for making them work in your environment today.

11. Practical guide

Here is what you actually do with the PRT this week.

Verifying PRT issuance

The operator-facing surface is dsregcmd /status, which prints the PRT state under the SSO State section. The three fields to read are AzureAdPrt (Yes if a PRT is present), AzureAdPrtUpdateTime (the timestamp of the last refresh), and AzureAdPrtExpiryTime (the absolute expiry on the current PRT, by default 90 days after issuance) [@prt-msft-learn] [@dsregcmd-troubleshoot].

{ // Models the section of dsregcmd /status output you care about. // On a real Windows host, you would run: dsregcmd /status | findstr AzureAdPrt const sampleOutput = \ +----------------------------------------------------------------------+ | SSO State | +----------------------------------------------------------------------+ AzureAdPrt : YES AzureAdPrtUpdateTime : 2026-05-12 09:31:14.000 UTC AzureAdPrtExpiryTime : 2026-08-10 09:31:14.000 UTC AzureAdPrtAuthority : login.microsoftonline.com/ EnterprisePrt : NO `; const lines = sampleOutput.split('\n').filter(l => l.match(/AzureAdPrt/)); console.log(lines.map(l => l.trim()).join('\n')); // Healthy: AzureAdPrt=YES and AzureAdPrtUpdateTime within the last 4 hours. `}

If AzureAdPrt is NO on a device that should have one, the most common causes are (a) the device is not actually Entra-joined, (b) the user has never signed in interactively since the last reboot, or (c) the device's TPM is malfunctioning and CloudAP could not complete the issuance handshake. dsregcmd /status will print device-state diagnostics directly above the SSO State section that disambiguate these.

Forcing PRT renewal

The PRT refreshes silently every four hours, driven by CloudAP -- this is the renewal cadence Microsoft Learn documents as the device-side refresh schedule, not a Conditional Access policy [@prt-msft-learn]. To force an out-of-band renewal, the supported path is to sign the user out and back in with a Hello-for-Business gesture or a strong credential. A locked-and-unlocked session does not generally force a new PRT mint; CloudAP treats unlock as a continuation event, not a fresh issuance.

Hunting PRT-mediated sign-ins in Entra logs

In the Microsoft Entra audit and sign-in logs, the load-bearing fields are authenticationDetails, authenticationProcessingDetails, and the IsCompliantDevice and DeviceDetail claims attached to the sign-in event. A sign-in that rode the PRT path will surface a PRT indicator in authenticationProcessingDetails. In Microsoft Defender XDR's advanced-hunting tables, the corresponding views are IdentityLogonEvents (for on-prem and federated paths) and AADSignInEventsBeta (for native Entra sign-in events) [@defender-xdr-schema]. The latter is the table to query when looking for unusual x-ms-RefreshTokenCredential-driven sign-ins -- specifically, sign-ins from device-claim-bearing tokens whose DeviceId does not match the device's DeviceId in Intune.

Conditional Access patterns

Pattern	What it enforces	What it cannot enforce
Require compliant device	Sign-in only from devices Intune (or a partner MDM) reports as compliant	Whether the compliance signal is fresh; an attacker who can spoof an Intune compliance attestation passes
Require Microsoft Entra hybrid joined device	Sign-in only from hybrid-joined devices	Personal Entra-registered devices that meet compliance
Require MFA at sign-in	A fresh MFA factor at PRT issuance	Whether the MFA factor is phishing-resistant
Authentication Strengths (FIDO2-only)	Phishing-resistant credential at issuance, propagated as a strong `mfa` claim into the PRT	Downstream phishability through cookie theft (KDFv2 fix applies; on-device residual remains)
Token Protection for sign-in tokens	Device-bound assertion required for app-token requests	Browser sessions (DBSC is the per-origin counterpart)
Sign-in Frequency = 4 hours	Re-authentication every four hours	The 90-day PRT lifetime independent of sign-in cadence

The right policy stack for most enterprises is: require compliant device (or hybrid-joined), require Authentication Strengths for privileged users, require Token Protection where the resource supports it, and set a Sign-In Frequency policy that matches your risk appetite. CAE is on by default on modern tenants and does not need explicit opt-in.

CAE enablement and tenant configuration

CAE was made the default for all Entra tenants at GA on 10 January 2022; the announcement explicitly noted that Microsoft "auto-enabled it for all tenants" [@twu-cae-ga-mirror]. Microsoft Outlook, Microsoft Teams, and Office on Windows are CAE-aware clients [@cae-learn]; third-party apps that want to participate need to implement the claim-challenge protocol. Microsoft Graph clients gain CAE participation by including cp1 in the requested client capabilities [@cae-client-capabilities]. If your tenant is a CAE outlier, the cause is almost always a custom OIDC application that has not implemented the claim challenge.

Forensic indicators

Three signals deserve hunting attention:

Anomalous x-ms-RefreshTokenCredential cookie origins. A sign-in where the cookie's IP geolocation does not match the device's last known location -- particularly across time zones -- is a candidate Pass-the-PRT-Cookie signal even after KDFv2, because the on-device class survives.
Device-claim-bearing tokens whose DeviceId does not match Intune state. An attacker who lifted a PRT off-device cannot mint cookies post-KDFv2, but a cloned DeviceId claim in a token request is a strong off-the-rails signal in older logs and a useful retrospective hunt for July 2021 and earlier.
lsass broker-process anomalies. Mimikatz-class memory-reading tools typically attach to lsass with debug privileges. The current EDR generation (Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne) detects the canonical access patterns; deploy that telemetry, then validate the alert-rule coverage with Get-MpComputerStatus and the EDR-specific equivalents.

What NOT to do

Note: The single biggest operational mistake is to disable the broker because something else is broken. WAM, CloudAP, and the browser SSO surface are not optional add-ons; they are the cryptographic floor your Conditional Access policies are built on. If a particular app is breaking on PRT-mediated sign-in, the right move is to diagnose the broker integration, not to suppress it. Likewise, do not suppress Conditional Access in lieu of trusting the PRT -- the PRT carries claims that Conditional Access evaluates; disabling Conditional Access keeps the claims but throws away the policy engine.

Open an elevated command prompt. Run `dsregcmd /status`. Confirm `AzureAdJoined : YES`, `DeviceId` is populated, and `AzureAdPrt : YES` with a recent `AzureAdPrtUpdateTime`. Then in PowerShell, run `Get-CimInstance -ClassName Win32_Tpm` and confirm the TPM is present, ready, and at spec version 2.0. Finally, in the Entra ID portal, search for the device by `DeviceId` and confirm the registration state, the OS version, and the compliance posture. Those three checks rule out 90% of "is my PRT working?" questions.

That is the PRT -- what it is, how it broke, how Microsoft fixed it, where it stops. Now the FAQ.

12. FAQ and closing

No. They are different protocols, issued by different authorities, with different lifetimes. A Kerberos TGT is issued by an on-prem Key Distribution Center, lives 10 hours by default, and rides the AS_REQ/AS_REP protocol. A PRT is issued by Microsoft Entra ID, lives 90 days by default, and rides the MS-OAPXBC protocol over HTTPS. Cloud Kerberos Trust *issues a TGT to a PRT holder* via the Microsoft Entra Kerberos partial-TGT mechanism [@cloud-kerberos-trust-learn], but the two artifacts are distinct and serve different protocol clients. No. The PRT is the cloud-mediated authentication path. On-prem Kerberos still flows through the on-prem KDC for resources protected by the on-prem Active Directory domain. NTLM remains in use for legacy applications until those applications migrate. The PRT, Cloud Kerberos Trust, and the in-progress "NTLM-less" effort together describe a path that *reduces* reliance on NTLM, but they do not delete the on-prem authentication surface on day one. Not since July 2021. The asymmetric device key (`dkpriv`) signs the PRT *issuance* request -- a single asymmetric signature per PRT mint. The `x-ms-RefreshTokenCredential` cookie, by contrast, is HMAC-signed with `alg: HS256` using a symmetric key derived from the PRT *session key* via the SP800-108 KDF. Under KDFv2, the derivation context binds the cookie's full payload via `SHA256(ctx || assertion_payload)` [@ms-oapxbc-jwt] [@dimi-3or-de-kdfv2]. No. Dirk-jan Mollema's seminal PRT-cookie extraction work appeared in two blog posts on `dirkjanm.io` -- 21 July 2020 and 5 August 2020 [@mollema-prt-2020-07] [@mollema-prt-2020-08]. His 2022 conference talk on the same body of research was at TROOPERS 22 in Heidelberg in June 2022, not at DEF CON 30 [@troopers22-abstract]. Mollema's DEF CON history covers DC 27 (2019), DC 32 (2024), and DC 33 (2025); he did not present at DC 30 (2022) [@dirkjanm-talks-index]. The "DEF CON 2022" anchor that occasionally appears in summaries of the PRT-attack story is a memory error. Yes. Conditional Access evaluates each *token request*, including app-token requests via the Web Account Manager and `x-ms-RefreshTokenCredential` cookie redemptions at `login.microsoftonline.com`. The PRT carries device-state, MFA, and risk claims; Conditional Access uses those claims plus the resource and request context to allow or deny each request. CAE additionally revokes already-issued long-lived access tokens in near real time when critical events fire [@cae-learn]. No. Microsoft Pluton *is* a TPM 2.0 implementation -- the same TPM 2.0 contract, embedded in the SoC rather than as a discrete chip. The PRT two-key model is unchanged. `dkpriv` and `tkpriv` are TPM 2.0 keys on Pluton just as they are on a discrete TPM 2.0; CloudAP does not branch on TPM provenance in its issuance path. All three device states issue PRTs at first interactive sign-in. The differences are about device-management posture and which Conditional Access claims attach. **Microsoft Entra registered** is the personal-device / BYOD state -- the device has a cloud identity but is not the primary management surface; the PRT exists but the device is not necessarily compliant in the management sense. **Microsoft Entra joined** is the cloud-primary state -- the device's primary identity authority is Entra ID. **Microsoft Entra hybrid joined** is the dual state -- the device has both an on-prem AD computer object and an Entra ID device object; both authentication paths are active in parallel. Microsoft documents hybrid join as "an interim step on the road to Microsoft Entra join" for organizations migrating away from on-prem AD [@entra-devices-overview].

The PRT is not a replacement for Kerberos, NTLM, or Credential Guard. It is the cryptographic seam where Windows logon becomes a Microsoft Entra ID transaction -- and the rest of this series is about what runs alongside it: Hello for Business as the issuing credential, WebAuthn and FIDO2 as the per-relying-party authenticator class, Cloud Kerberos Trust as the on-prem bridge, Credential Guard as the on-prem-credential isolation path, Adminless as the local-authorization pattern, App Identity as the workload broker. Each of those articles starts from a question this one raises, and each closes on a question that connects back. The seam is the part you can name when somebody asks how the three sign-ins from §1 are secretly one event.

Measured Boot: The TCG Event Log from SRTM to PCR-Bound BitLocker

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

**Measured Boot is the system that lets Windows prove what code ran from power-on to logon.** A small immutable block called the CRTM measures the next stage, extending a SHA-256 digest into a TPM register (a PCR); each stage measures its successor, building a hash chain whose final value is uniquely determined by the entire ordered sequence of code that ran. BitLocker seals its Volume Master Key to a subset of those PCRs, so any unexpected change -- firmware update, Secure Boot key rotation, boot-manager swap -- forces a 48-digit recovery prompt. This article walks the chain event by event, explains why bitpixie (CVE-2023-21563) was unstoppable on TPM-only deployments, and gives you the six commands that turn the theory into a Monday-morning operational practice.

1. Two PCs That Hash Differently

At 06:00 on a Tuesday in March 2024, a senior administrator at a 500-seat law firm finishes patching her fleet of Dell OptiPlex 7090s overnight. At 08:42 she has answered her 173rd help-desk ticket, all variations on the same theme: Why is my laptop asking for a 48-digit BitLocker recovery key? The answer -- the answer the rest of this article exists to make obvious -- is that a single 32-byte SHA-256 register on every machine in her fleet now holds a different number than it did yesterday, and BitLocker's seal is bound to that number.

The patch she applied to make the fleet safer is the patch that locked it out.

Across town a second firm runs Secured-core PCs that ship with System Guard Secure Launch [@ms-learn-secured-core] enabled. Those machines absorb the same overnight UEFI delta without a single recovery prompt. Same vendor patch. Same Microsoft cumulative update. Same hour. Zero tickets. The difference is not the hardware; the difference is which subset of TPM registers BitLocker bound the disk-encryption key to.

A fixed-width append-only register inside a Trusted Platform Module. PCRs do not store; they *extend*. The TPM rewrites `PCR[N] := H(PCR[N] || measurement)`, where `H` is a cryptographic hash. PCRs reset to zero only at platform reset. A modern TPM 2.0 has 24 PCRs per hash bank, with banks for SHA-1, SHA-256, SHA-384, SHA-512, and SM3-256. A boot mode in which every stage of platform initialisation hashes the next stage's code and configuration into one or more PCRs *before* transferring control. Measured Boot is *reporting*, not *enforcement* -- it records what ran, but does not refuse to run anything. Secure Boot is the enforcement counterpart that refuses unsigned code; the two cooperate. Microsoft's `Trusted Boot` [@ms-learn-boot-process] extends the measurement chain into the Windows kernel.

By the end of this article you will be able to name every byte that went into that hash, predict whether any given administrative action will change it, and read the TCG event log on your own machine to confirm. You will see why the BitLocker seal is, in some configurations, a Faraday cage built on top of a fence the verifier never opened. You will learn that the chip Microsoft calls the Trusted Platform Module knows nothing of trust -- only of arithmetic over hashes -- and that the verifier, which knows what good looks like, is always someone other than the chip.

But first, the historical answer: how did a 32-byte register get into the position of deciding whether a PC boots cleanly or asks for a 48-digit key?

2. Origins: Arbaugh 1997 and the Chain-of-Hashes Axiom

The first paper to take the boot problem seriously is also one of the calmest. In 1997, three researchers at the University of Pennsylvania Distributed Systems Laboratory -- William A. Arbaugh, David J. Farber, and Jonathan M. Smith -- presented A Secure and Reliable Bootstrap Architecture [@aegis-1997] at the IEEE Symposium on Security and Privacy in Oakland. They opened with a line that ages disconcertingly well: "we find it surprising, given the great attention paid to operating system security that so little attention has been paid to the underpinnings required for secure operation, e.g., a secure bootstrapping phase for these operating systems."

They built a working prototype. A Pentium-class PC. A modified BIOS. A small PROM expansion card with public-key certificates. And, threaded through everything, an inductive structure they called AEGIS.

An ordered sequence in which each stage of platform initialisation verifies the cryptographic identity of the next stage *before* it executes. If every link verifies its successor, an external observer who trusts the first link transitively trusts the chain, modulo the cryptographic strength of the verification primitive.

AEGIS divided the boot into six levels (0 through 5). L0 was a small trusted ROM that ran the first POST phase, the signature-verification routines, and recovery code. L1 was the rest of the BIOS code plus CMOS. L2 was option-ROM expansion cards (the era's GPUs, network cards, SCSI controllers). L3 was the operating system boot block(s). L4 was the OS kernel. L5 was user programs and any network hosts the kernel reached. Each level verified the next before handing off; on a failed verification, L0 recovered the broken stage from a known-good network image. (The paper also presents a "four levels of abstraction" framing for one of its figures; the article uses the canonical six-level numbering.)

The smallest, lowest, most immutable code that runs after platform reset. It measures the next stage of firmware and extends that measurement into PCR[0] before transferring control. Modern PCs implement the CRTM in silicon -- Intel's Boot Guard Authenticated Code Module, AMD's Platform Security Processor firmware, or Microsoft's Pluton silicon -- because anything mutable is not actually a root of trust.

The architectural axiom that survived 28 years of evolution is this: there is always a bottom layer you cannot verify yourself. AEGIS does not eliminate that layer; it reduces trust to the smallest possible unverifiable thing. The L0 trusted ROM is the axiom; everything above it is provable from the axiom. Replace "trusted ROM" with "Boot Guard ACM" or "PSP boot ROM" or "Pluton silicon firmware" and the structure does not change.

AEGIS could not, on its own, make the next pivot. It had no hardware-rooted endorsement key. It had no append-only register that could not be lied to. It had no remote-attestation primitive -- the L0 ROM trusted itself, but an external auditor was forced to trust the BIOS's own report of the bootstrap. The trick AEGIS could not pull off is the trick the Trusted Computing Platform Alliance was about to attempt: make the root a chip.Arbaugh continued the work at the University of Maryland and later took a senior position at the National Security Agency. The bootstrap problem followed him; in 2005 he co-authored an early TPM-on-Linux survey that anticipates several of the PCR allocation conventions that PFP would formalise.

The TCPA was founded on October 11, 1999 [@wiki-tcg] by Compaq, Hewlett-Packard, IBM, Intel, and Microsoft. Its first specification [@wiki-tcg] shipped January 30, 2001. The first hardware-TPM-equipped PC shipped on the IBM ThinkPad T30 in 2002 [@wiki-tcg] (with a TPM 1.1-class Infineon SLB chip); the TPM 1.1b revision deployed in volume the year after. In 2003 the TCPA was reorganised as the Trusted Computing Group, with AMD joining as a founding board member.

The thing AEGIS could not do -- turn a chain of in-RAM hash comparisons into a record a remote party can trust -- is what the TPM became.

3. Early Approaches: TPM 1.1b, SHA-1, and the Original PCSI

"The first TPM version that was deployed was 1.1b in 2003" [@wiki-tpm] -- Wikipedia, drawing on the TCPA shipment record. A 24-pin chip in a tiny LPC-bus package, soldered to the motherboard of a ThinkPad T30. Sixteen PCRs. One hash bank: SHA-1, 20 bytes wide. A monotonic counter. An endorsement key, fused at manufacture. A storage root key, generated at first ownership. By 2010, hundreds of millions of business PCs shipped with one. By July 28, 2016, Microsoft's Windows 10 hardware logo programme required TPM 2.0 on every new OEM Windows 10 PC -- desktop, mobile, and server alike [@wiki-tpm].

The mechanic that did all the work is one operation: TPM_Extend. It takes a PCR index and a 20-byte digest. It produces a new PCR value defined as PCR[N] := SHA1(PCR[N] || digest).

The only writable mutation a TPM permits on a PCR. Given the current value `P` and a new measurement `M`, the TPM computes `H(P || M)` and writes the result back into the PCR. There is no `set`; there is no `clear` (PCRs reset only at platform reset, and some PCRs not even then). The hash chain is the *only* trace.

That two-letter primitive -- extend -- is doing more cryptographic work than its size suggests. A PCR is not a set of measurements; it is a sequence. If three boot stages measure three values a, b, c into PCR[0] in that order, the resulting PCR encodes H(H(H(0 || a) || b) || c). Reorder the stages and the final hash differs. Repeat a stage and the final hash differs. Skip a stage -- the move every rootkit dreams of -- and the final hash differs. Under collision-resistance of the underlying hash, producing the same final PCR via a different ordered sequence is computationally infeasible.

A naive design might use the PCR as a set: write each measurement into a separate slot, and let the verifier check that the set matches a known-good baseline. That design has two pathologies. First, an attacker who controls one stage can simply *not* report its measurement and let the verifier see a smaller set than ran. Second, order doesn't matter to a set; an attacker can rearrange the stages and slip a measured-but-vulnerable component in early, where its measurement still "matches" the baseline.

Extend solves both. You cannot omit a stage without changing the final hash. You cannot reorder. You cannot insert. The cost is that the verifier cannot read the PCR as a list of measurements -- it has to be given the list (the TCG event log) separately and re-derive the final PCR by replaying the extends. This is the trade we'll meet in Section 8 as a fundamental limit.

The PC Client Specific Implementation (PCSI) specification carved up the 24 PCRs of TPM 1.2 into eight indices that the world still uses today. PCR[0] holds the CRTM, the system firmware code, and the firmware host platform extensions. PCR[1] holds the host platform configuration (CMOS settings that change platform behaviour). PCR[2] holds the option ROM code. PCR[3] holds the option ROM configuration. PCR[4] holds the master boot record code (and on UEFI machines, the boot-loader image). PCR[5] holds the master boot record partition table (and on UEFI machines, the boot configuration). PCR[6] holds host platform manufacturer-specific events. PCR[7] holds host platform manufacturer events -- a category that, post-PFP, became Secure Boot policy.

A group of PCRs that share a hash algorithm. TPM 1.2 had one bank only (SHA-1). TPM 2.0 supports multiple banks simultaneously -- the same PCR index exists once per bank, with one digest per bank. A measurement into PCR[7] writes the same source bytes into every bank but produces algorithm-specific digests.

TPM 1.2 also defined the first remote-attestation primitive in industry hardware: TPM_Quote. The TPM signs a snapshot of selected PCR values plus a verifier-supplied nonce with a private key the chip alone holds (the attestation identity key, signed by a TCG-managed privacy CA). The verifier checks the signature, checks the nonce, checks the AIK certificate chain, and re-derives the expected PCR set from a TCG event log delivered separately. If the re-derivation matches the signed quote, the platform's boot history is authenticated.

It worked. For a while. Then, on February 23, 2017, the SHAttered team -- Marc Stevens (CWI Amsterdam) and Pierre Karpman (Inria) with Elie Bursztein, Ange Albertini, and Yarik Markov (Google Research) -- published the first public SHA-1 collision [@wiki-sha1]. Two PDF files with identical SHA-1 hashes. The collision cost about 110 GPU-years of compute [@wiki-sha1]. The implication for TPM 1.2 was immediate: a 20-byte SHA-1 PCR can no longer be assumed unique under attacker-controlled input.The SHA-1 choice in 2003 was state-of-the-art at the time, not negligence. NIST's SHA-256 had been published in 2001 but was not yet broadly trusted; SHA-1 was the IETF-blessed default for X.509 and many TLS deployments. The SHAttered collision required compute that did not exist commercially in 2003. By 2017 it required compute that anyone with a Google Cloud account could buy.

If the cryptographic floor is broken and you cannot re-floor in place -- a TPM 1.2 chip cannot grow a SHA-256 bank [@wiki-tpm] -- you replace the floor with one that can be moved. That is what TPM 2.0 became.

4. Evolution: TPM 2.0, Hash Agility, and the UEFI PFP

On April 9, 2014, the Trusted Computing Group announced the TPM Library Specification 2.0 [@wiki-tpm]. ISO ratified the result the following year as ISO/IEC 11889-1:2015 [@iso-11889-1-2015], and confirmed the standard as current in a 2021 review. The change set is large -- new algorithm framework, NV index ACLs, sessions, command authorization area, ECC primary keys -- but the line that matters for measurement is the simplest one: PCRs now exist in banks.

A property of a security system that lets operators or vendors replace one hash function with another without changing the system's interfaces. TPM 2.0 implements hash agility for PCRs (multiple banks), HMAC keys (algorithm parameter on the key), and signature primitives (algorithm parameter on the signature). Hash agility is not free: every bank costs storage, every bank costs extend cost, and the verifier must agree with the prover on which bank to use.

A TPM 2.0 chip can run a SHA-1 bank, a SHA-256 bank, and (often) a SHA-384 bank in parallel, plus optional SHA-512 and SM3-256. The same PCR index lives once per bank. A TPM2_PCR_Extend call updates every active bank with bank-specific digests; the source bytes are identical but the output is per-algorithm. TPM2_PCR_Allocate reconfigures the bank set at runtime, gated by platform authorization.

The event log structure had to grow with the chip. The pre-2014 log format -- TCG_PCR_EVENT, single SHA-1 digest -- could not carry per-bank digests. The PC Client PFP defined a new structure, TCG_PCR_EVENT2. From Microsoft's Tbsi_Get_TCG_Log reference [@ms-tbs-get-tcg-log], the wire format is:

typedef struct {
    TCG_PCRINDEX        PCRIndex;
    TCG_EVENTTYPE       EventType;
    TPML_DIGEST_VALUES  Digests;
    UINT32              EventSize;
    UINT8               Event[EventSize];
} TCG_PCR_EVENT2;

typedef struct {
    UINT32   Count;
    TPMT_HA  Digests;  // Count copies, one per bank
} TPML_DIGEST_VALUES;

typedef struct {
    UINT16  HashAlg;
    UINT8   Digest[size_varies_with_algorithm];
} TPMT_HA;

An in-RAM ordered list of `TCG_PCR_EVENT2` records, populated by firmware and OS components in the exact order they extend digests into PCRs. The log is *unsigned* -- only the PCR values are signed when the verifier later requests a quote. A verifier replays the log to re-derive the PCR values and accepts the log if the re-derivation matches the signed quote. The multi-bank digest container inside `TCG_PCR_EVENT2`. It holds a `Count` of `TPMT_HA` records, each carrying a hash-algorithm identifier (`HashAlg`, a TPM_ALG_ID) and the corresponding digest. A modern Windows log on a SHA-256-and-SHA-1 dual-bank TPM emits `Count = 2` per event with both digests of the same source bytes.

The very first event in a TPM-2.0-format log is, deliberately, a TPM-1.2-format record. From Microsoft Learn verbatim [@ms-tbs-get-tcg-log]: "The Signature member of the TCG_EfiSpecIdEventStruct structure is set to a null-terminated ASCII string of \"Spec ID Event03\"". That string is the self-describing handshake: a parser that doesn't know about banks reads the legacy event and either understands it (continuing as a 1.2 parser) or recognises the Spec ID handshake (and upgrades to the 2.0 parser). The cost of forward compatibility is precisely one event.The "Event03" suffix is not a typo. The TCG PC Client Platform Firmware Profile defines TCG_EfiSpecIDEventStruct with Signature[16] containing the ASCII string and a specVersionMajor/specVersionMinor/specErrata triplet. The "03" denotes the third revision of the format. Earlier "Spec ID Event02" structures exist in pre-1.21 PFP firmware; they encode banks differently and are extremely rare in Windows-era machines.

The bridge between the chip and the firmware is a UEFI protocol. EFI_TCG2_PROTOCOL [@uefi-org-specs] (UEFI 2.5 and later) exposes three calls that matter: HashLogExtendEvent (the one-shot "hash this blob, log it, extend the PCR" call), GetEventLog (return the in-progress event log to a caller), and GetCapability (which banks are active, which algorithms are supported). After ExitBootServices, the firmware publishes the final log as a UEFI configuration table; the OS reads it from there.

The Microsoft PFP-era PCR allocation is the table every modern Windows administrator should memorise.

PCR	TCG PFP definition	Microsoft WBCL convention	Linux IMA / shim convention
0	SRTM, BIOS, host platform extensions, embedded option ROMs	Firmware version (`EV_S_CRTM_VERSION`); platform firmware blob	Same
1	Host platform configuration	BIOS setup data	Same
2	UEFI driver and application code (option ROMs)	Pluggable option ROM code	Same
3	UEFI driver and application configuration	Option ROM data	Same
4	UEFI boot manager and boot attempts	`EV_EFI_BOOT_SERVICES_APPLICATION` for `bootmgfw.efi`	Same (shim/grub image)
5	Boot manager code and boot attempts	Boot partition GPT, EFI variables loaded by boot manager	Same
6	Host platform manufacturer events	Wake reason, S-state events	Same
7	Secure Boot policy	`SecureBoot`/`PK`/`KEK`/`db`/`dbx` variable digests	Same
8-9	OS-loader reserved	Unused on Windows	Linux kernel measurement (some distros)
10	OS-loader reserved	Unused on Windows	IMA file measurements (canonical)
11	OS-loader reserved	Microsoft WBCL events (BitLocker control PCR)	Unused
12	OS-loader reserved	Boot environment configuration	Unused
13	OS-loader reserved	ELAM driver hash and policy	Unused
14	OS-loader reserved	Boot-loader-authority events	shim MOK certificate enrolment
15	OS-loader reserved	Reserved	Reserved
16	Debug	Used during development	Same
17-22	Dynamic OS (DRTM use only)	Secure Launch, Authenticated Code Module	TrenchBoot, tboot
23	Application support	Reserved	Reserved

A small word on the index column: a 24-PCR TPM ranges from PCR[0] to PCR[23].The PFP allocates PCR[16] as a debug index that platform firmware may extend during development; the value resets to zero at TPM_Init, which is one of two PCRs (the other is PCR[23]) the platform may explicitly reset. Older PCSI-era documentation sometimes refers to PCR[24]; that is a historical artifact of an unsanctioned Infineon extension and is not part of the modern PFP allocation. The allocation itself is normative in the PFP, but it sits inside a wider policy frame: NIST SP 800-155 (BIOS Integrity Measurement Guidelines, December 2011 IPD) [@csrc-sp800-155-pdf] defined the federal procurement bar for "BIOS integrity measurement" -- a draft that, despite never finalising, became the de-facto procurement template for the SRTM measurement chain U.S. agencies require their suppliers to ship.

Note: If you click the canonical TPM 2.0 Library Specification link [@tcg-tpm-library] or the PC Client PFP link [@tcg-pfp], the trustedcomputinggroup.org host returns HTTP 403 to non-browser User-Agents and to some browser fingerprints. The specifications exist and are normative; we cite them by canonical URL. For verbatim struct definitions and the "Spec ID Event03" string, Microsoft's Tbsi_Get_TCG_Log reference [@ms-tbs-get-tcg-log] reproduces them word-for-word; Wikipedia's TPM article [@wiki-tpm] corroborates the spec metadata.

gantt dateFormat YYYY title Five generations of measured boot section Generation 1 AEGIS at UPenn (Arbaugh 1997) :a1, 1997, 1y section Generation 2 TCPA founded (1999) / TPM 1.1b (2003) :a2, 1999, 11y TPM 1.2 PCSI defines PCR[0-7] :a3, after a2, 11y section Generation 3 TPM 2.0 announced (April 9, 2014) :a4, 2014, 12y ISO/IEC 11889 (2015) / Hash agility :a5, 2015, 11y section Generation 4 Intel TXT GETSEC[SENTER] (2007) :a6, 2007, 19y Microsoft Secure Launch (Win10 1809) :a7, 2018, 8y section Generation 5 Azure Attestation / Intune DHA :a8, 2018, 8y PFP r2 / ML-DSA in flight :a9, 2025, 1y

We now have a self-describing log, a hash-agile PCR set, and a verbatim ABI. Who actually writes the log? And who reads it?

5. The Breakthrough: One Log, Many Consumers

Every trust decision a modern Windows machine makes about its own boot ultimately consults the same record. BitLocker's seal release. Windows Defender System Guard runtime attestation [@ms-learn-sgsl]. Windows Hello for Business device-bound key attestation. Microsoft Azure Attestation [@ms-aa-overview] policy evaluation. Microsoft Intune Device Health Attestation. Conditional Access posture checks. All of them, ultimately, read the TCG event log -- and the PCR snapshot it replays into. One log; every feature.

This is the article's structural insight. It is also the reason this specification has survived three generations of attacks: the cost of designing a new attestation feature on Windows is no longer "design a new measurement plane," it is "decide which PCRs your policy cares about."

Key idea: One log, many consumers. Every Windows trust decision about boot integrity -- BitLocker unseal, System Guard attestation, Hello for Business key attestation, Azure Attestation, Intune Device Health Attestation, Conditional Access -- ultimately consults the same TCG event log and the PCR snapshot it replays into. The cost of adding a new attestation feature is not a new measurement plane; it is a policy decision about which PCRs matter.

One log, every feature.

The cooperative writers populate the log in pipeline order, following the Microsoft Tbsi_Get_TCG_Log PCR allocation [@ms-tbs-get-tcg-log]. Firmware -- the silicon root of trust and everything above it through the UEFI driver execution environment -- writes PCRs 0 through 7. The Microsoft boot manager bootmgfw.efi writes additional events into PCRs 4, 11, and 12. The Windows OS loader winload.efi writes into PCRs 11 and 13. Into PCR 13 specifically, winload.efi writes the ELAM policy hash and the ELAM driver writes its own image digest (§6.5 walks the full PCR[13] cooperative sequence). The Windows kernel emits a EV_SEPARATOR event on every measured PCR once the boot-time measurement phase is complete, freezing the boot-time slice of the log for verifiers.

The unified reader path mirrors the writer fan-in. EFI_TCG2_PROTOCOL.GetEventLog exposes the main log to firmware drivers and applications before ExitBootServices; events measured after that call are published separately through the EFI_TCG2_FINAL_EVENTS_TABLE configuration table. Windows reads both during boot and exposes the merged log -- the firmware portion plus the OS-loader extensions -- to user mode through Tbsi_Get_TCG_Log [@ms-tbs-get-tcg-log]. Operators read it with the inbox tpmtool.exe or cross-platform tpm2_eventlog [@gh-tpm2-eventlog-man]; §6.7 walks the full tool set.

flowchart TD subgraph FW["Firmware (CRTM / PEI / DXE / BDS)"] F0["PCR[0]: CRTM, firmware blob"] F1["PCR[1]: BIOS setup"] F2["PCR[2]: option ROMs"] F3["PCR[3]: option ROM config"] F5["PCR[5]: GPT, EFI vars"] F6["PCR[6]: wake reason"] F7["PCR[7]: Secure Boot policy"] end subgraph BM["bootmgfw.efi"] B4["PCR[4]: boot mgr image (Authenticode)"] B11A["PCR[11]: WBCL boot mgr events"] B12["PCR[12]: boot config"] end subgraph WL["winload.efi"] W11["PCR[11]: kernel, HAL, boot-critical drivers"] W13A["PCR[13]: ELAM policy hash"] end subgraph ELAM["ELAM driver"] E13["PCR[13]: ELAM driver hash"] end subgraph K["Windows kernel"] SEP["EV_SEPARATOR on every measured PCR (freeze)"] end FW --> BM --> WL --> ELAM --> K

A single canonical log eliminates per-feature reinvention. Azure Attestation does not have to parse a different log than BitLocker. Hello for Business does not have to extend its own PCRs. The verifier community -- the part that knows what "good" means -- builds policies on top of one shared substrate.

We have named the log abstractly. What does an actual event look like, byte by byte, on the wire?

6. State of the Art: A Line-by-Line Walk Through the SRTM Chain

This is the section the practitioner audience came for. We walk the chain in the exact order events are logged on a modern UEFI Windows 11 24H2 machine. Reference: a Dell OptiPlex 7090 with Boot Guard, TPM 2.0 in SHA-256-only mode, Secure Boot enabled, BitLocker with TPM-only protector bound to the PFP-default UEFI profile.

The first measured event, after the initial EV_NO_ACTION Spec ID record described above, is a EV_S_CRTM_VERSION record. PCR index 0. Event type 0x00000008. Two SHA-256 digests (one per active bank if SHA-1 is also enabled). Event size 8. Event data: a little-endian UTF-16 string containing the firmware version, padded to 8 bytes. The CRTM extends its own version into PCR[0] before measuring anything else. This is the foundation event.

6.1 The CRTM and PCR[0]

The very first instruction the CPU fetches after reset is not in DRAM. On a modern x86, it is in an immutable silicon region whose location and contents differ by silicon vendor.

On AMD Zen-class platforms, the Platform Security Processor -- a 32-bit ARM core inside the SOC -- boots first, validates the platform firmware against a key fused into silicon, and only then releases the x86 cores from reset. On Intel platforms with Boot Guard, the Authenticated Code Module is loaded from firmware into the cache-as-RAM region, signed by a key whose hash is fused into Intel chipset OTP fuses, and verified by microcode before x86 main core start. On Microsoft Pluton SKUs, the Pluton silicon firmware runs first; on AMD Ryzen 6000-series and later parts with Pluton enabled, Pluton is implemented as a Microsoft-co-designed firmware mode running on the existing AMD PSP coprocessor, not as a separate chip.

In every case, that silicon-rooted CRTM measures the next stage of firmware before transferring control. From Microsoft's hardware-rooted trust documentation [@ms-learn-hwrot], verbatim: "This technique of measuring the static early boot UEFI components is called the Static Root of Trust for Measurement (SRTM)." The SRTM extends PCR[0] with a chain of three early events: EV_S_CRTM_VERSION (firmware version), EV_S_CRTM_CONTENTS (the immutable CRTM code hash), and EV_POST_CODE (the POST code region hash). Then, if the platform has a separable firmware volume, an EV_EFI_PLATFORM_FIRMWARE_BLOB event covers the rest of the SPI flash region per the TCG PFP event-type registry surfaced in Microsoft's Tbsi_Get_TCG_Log reference [@ms-tbs-get-tcg-log]. The PFP closes PCR[0] with an EV_SEPARATOR event at the BDS boundary.

Where the firmware-version string differs, the SHA-256 digest of the EV_S_CRTM_VERSION event data differs. Where the EV_S_CRTM_VERSION digest differs, PCR[0] differs. That is the entire mechanism by which an overnight UEFI patch changes PCR[0]. Dell updated the firmware string from "1.16.0" to "1.17.0"; the bytes hashed; the PCR moved; the seal broke.

6.2 PEI/DXE, option ROMs, and PCR[1-3]

After the CRTM hands off, the Pre-EFI Initialisation (PEI) phase runs and the Driver Execution Environment (DXE) phase loads UEFI drivers. PEI does early silicon initialisation -- memory controller, cache topology, basic chipset config -- and DXE does device discovery, including option ROMs for plug-in cards.

Each option ROM that runs is measured into PCR[2]. The option ROM's configuration -- card-specific NVRAM state that survives reboot -- is measured into PCR[3]. The PFP also reserves PCR[1] for the platform configuration: CMOS settings, the SMBIOS table contents, and any BIOS-setup-visible knob that affects platform behaviour per the PCR-allocation mapping surfaced in Microsoft's Tbsi_Get_TCG_Log documentation [@ms-tbs-get-tcg-log]. Changing your boot order in BIOS setup changes PCR[1]. Disabling a USB controller in firmware changes PCR[1]. Installing a discrete GPU adds an EV_EFI_BOOT_SERVICES_DRIVER event into PCR[2] for the GPU's video BIOS.

6.3 Secure Boot variables and PCR[7]

PCR[7] is the Secure Boot policy PCR. It records the digests of the four variables that define Secure Boot identity -- SecureBoot (the on/off flag), PK (Platform Key), KEK (Key Exchange Key), db (allowed signers), and dbx (revocation list) -- plus any signed program execution events the firmware logs to PCR[7] under EV_EFI_VARIABLE_AUTHORITY [@gh-wack0-bitlocker].

Each variable contributes one EV_EFI_VARIABLE_DRIVER_CONFIG event whose Event field encodes (VariableName GUID, UnicodeName, VariableDataLength, VariableData) and whose digest is the SHA-256 of that entire structure. The digest is not over the variable data alone; it is over the GUID and name as well. This matters: when the May 2023 Microsoft dbx update shipped under KB5025885 [@ms-kb5025885] added the BlackLotus-vulnerable boot manager hashes to the revocation list, the variable data length grew, the structure changed, and the resulting EV_EFI_VARIABLE_DRIVER_CONFIG digest differed. Every UEFI Windows machine on Earth that consumed that dbx update saw PCR[7] move.

From the Wack0/bitlocker-attacks index [@gh-wack0-bitlocker], reproducing TCG EFI Platform Specification §6.4 verbatim: "If the platform provides a firmware debugger mode which may be used prior to the UEFI environment or if the platform provides a debugger for the UEFI environment, then the platform SHALL extend an EV_EFI_ACTION event into PCR[7] before allowing use of the debugger". The intent is clear: a debugged firmware is a different PCR[7] than a production firmware. The verifier can refuse to release a key to a debugged platform.

6.4 Boot manager (bootmgfw.efi) and PCR[4] + PCR[11]

The UEFI Boot Device Selection (BDS) phase locates EFI/Microsoft/Boot/bootmgfw.efi on the EFI System Partition, computes its Authenticode digest, verifies the Authenticode signature against db and dbx, logs an EV_EFI_BOOT_SERVICES_APPLICATION event into PCR[4] with that digest, and transfers control. PCR[4] now binds to the boot manager's image content. A different boot manager binary -- a different version, a different language pack -- produces a different PCR[4].

Microsoft's Portable Executable signature format. The Authenticode digest is computed over the PE image *excluding* fields the loader rewrites (file offset bytes, the checksum field, the digital-signature pointer). Authenticode is not the same as a SHA-256 over the file -- two byte-identical .exe files can have different SHA-256 but the same Authenticode digest, and vice versa. Boot Guard, Secure Boot, and PCR[4] all hash the Authenticode digest, not the raw file.

Once bootmgfw.efi runs, it extends its own events into PCR[11]. These are Microsoft-specific Windows Boot Configuration Log (WBCL) records, not generic TCG events. They include the BCD store contents, the boot-environment configuration, and Microsoft-private telemetry about the boot manager's policy decisions. PCR[11] is the BitLocker control PCR -- the index that captures Windows-side boot-time configuration.

The Microsoft-specific extension of the TCG event log carrying boot-manager, loader, and ELAM events. WBCL events use the TCG `EV_EVENT_TAG` event type with Microsoft-private sub-types. They are extended into PCR[11], PCR[12], and PCR[13]. WBCL is exposed by `Tbsi_Get_TCG_Log_Ex` and is what `tpmtool.exe getdeviceinformation` actually parses.

6.5 winload.efi and the ELAM handoff

bootmgfw.efi chains to winload.efi, the OS loader. winload measures the Windows kernel image (ntoskrnl.exe), the Hardware Abstraction Layer (hal.dll), the OS configuration data (the boot manager's view of boot-critical drivers), and each boot-critical driver in load order -- each into PCR[11] as a WBCL record. The kernel binary itself is part of that chain; a kernel update changes PCR[11].

The Early Launch Anti-Malware (ELAM) interface gives a vendor anti-malware driver a chance to run before all other drivers and approve or block subsequent driver load attempts. winload measures the ELAM policy file hash into PCR[13]; the ELAM driver, when loaded, extends its own image digest into PCR[13]; the ELAM driver then returns its allow/deny verdict on each subsequent driver, and winload logs those verdicts (also into PCR[13] under WBCL EV_EVENT_TAG).

6.6 Kernel and the final separator

Once the Windows kernel starts, it exposes the TCG event log through the TPM Base Services driver Tbs.sys, which is consumed by Win32 callers through Tbsi_Get_TCG_Log. The kernel emits a EV_SEPARATOR event into every measured PCR -- the "ready-to-boot" marker. After the separator, no further measured-boot events occur for the current boot session. The WBCL is frozen. A verifier reading the log at this point sees the complete boot history.

6.7 Reading the log from user mode

On a Windows 11 24H2 machine, the simplest way to read the log is tpmtool.exe getdeviceinformation from an elevated prompt -- it prints the parsed WBCL plus the current PCR values. For the raw binary log, Get-TpmEndorsementKeyInfo from PowerShell returns the EK chain, and MeasuredBootTool.exe -log <path> from the Windows HLK kit returns the raw binary log file written under C:\Windows\Logs\MeasuredBoot\*.log.

Cross-platform, tpm2_eventlog [@gh-tpm2-eventlog-man] from the tpm2-tools suite [@gh-tpm2-tools] parses any binary log conforming to the PC Client PFP -- including Windows-saved logs, because the WBCL extension is structurally compatible. The man page is precise: "tpm2_eventlog(1) -- Parse a binary TPM2 event log... The format of this log documented in the 'TCG PC Client Platform Firmware Profile Specification'." On Linux, the firmware-published log lives at /sys/kernel/security/tpm0/binary_bios_measurements.

{` // Simulate three iterative SHA-256 extends into a single PCR. // Initial PCR is 32 zero bytes. Each extend: PCR := SHA256(PCR || measurement).

async function sha256(buffer) { const hash = await crypto.subtle.digest('SHA-256', buffer); return new Uint8Array(hash); }

function concat(a, b) { const out = new Uint8Array(a.length + b.length); out.set(a, 0); out.set(b, a.length); return out; }

function toHex(arr) { return Array.from(arr).map(b => b.toString(16).padStart(2, '0')).join(''); }

async function extendChain(measurements) { let pcr = new Uint8Array(32); // 32 zero bytes for (const m of measurements) { pcr = await sha256(concat(pcr, m)); } return toHex(pcr); }

const a = new TextEncoder().encode('firmware-v1.16'); const b = new TextEncoder().encode('bootmgfw-2024-03'); const c = new TextEncoder().encode('winload-26100.123');

(async () => { const abc = await extendChain([a, b, c]); const cba = await extendChain([c, b, a]); console.log('PCR after a,b,c =', abc); console.log('PCR after c,b,a =', cba); console.log('Same value?', abc === cba); })(); `}

Run that snippet and you will see two completely different 32-byte hex strings. The PCR encodes the order. A verifier comparing your machine's PCR[11] against a known-good baseline is implicitly checking that the kernel, the HAL, and the boot-critical drivers all loaded in the expected sequence -- not just that they all loaded. Reorder the chain, even with identical inputs, and the PCR moves. This is the property that makes the chain-of-hashes axiom load-bearing.

6.8 The PCR allocation cheat sheet

Pin the table from Section 4 to your wall. Most operational questions reduce to "which PCR is affected by this change, and is it in my BitLocker profile?" Three quick rules:

Code changes go to even PCRs (0, 2, 4). Firmware blob, option ROM, boot manager. A firmware update moves PCR[0]; a discrete GPU swap moves PCR[2]; a boot-manager update moves PCR[4].
Configuration changes go to odd PCRs (1, 3, 5). BIOS setup, option ROM config, EFI variables seen by the boot manager.
Policy and identity go to PCR[7]. Secure Boot keys. Any dbx update moves PCR[7]. Disabling Secure Boot moves PCR[7]. Enrolling third-party db entries moves PCR[7].

PCR[11] is the OS-loader code chain on Windows (kernel, HAL, boot drivers). PCR[13] is the ELAM policy and driver. PCR[14] is, by Microsoft convention, boot-loader-authority events; by Linux shim convention, MOK enrolment. Same index; different ontology. Verifiers must pick a side.

6.9 BitLocker seal-binding

BitLocker's Volume Master Key is wrapped by a TPM-resident sealed blob whose policy is TPM2_PolicyPCR over a chosen PCR profile. The default UEFI profile is the bitmask 0x00000080 | 0x00000800 = 0x880 -- that is PCR[7] (bit 7 = 0x80) plus PCR[11] (bit 11 = 0x800) -- as documented in the BitLocker Group Policy reference [@ms-learn-bitlocker-gpo], which notes verbatim that "when Secure Boot State (PCR7) support is available, the default platform validation profile secures the encryption key using Secure Boot State (PCR 7) and the BitLocker access control (PCR 11)." The legacy CSM/BIOS profile is 0x00000015 | 0x00000800 = 0x815 -- that is PCR[0], PCR[2], PCR[4], plus PCR[11].

At seal time (when BitLocker enables, or when a user changes the protector configuration), the TPM records the current PCR values into the policy. At every subsequent boot, the boot manager rebuilds the session, calls TPM2_PolicyPCR with the current PCR values, and calls TPM2_Unseal. If the current PCRs match the seal-time digest, the TPM releases the VMK and BitLocker unlocks transparently. If they don't match, the TPM refuses and Windows prompts for the 48-digit recovery key.

From Microsoft's BitLocker countermeasures documentation [@ms-learn-bitlocker-counter]: "By default, BitLocker provides integrity protection for Secure Boot by using the TPM PCR[7] measurement. An unauthorized EFI firmware, EFI boot application, or bootloader can't run and acquire the BitLocker key". The PCR[7]-default choice is deliberate: PCR[7] is the policy PCR, not the code PCR. Firmware updates don't change a Secure-Boot-policy hash; only key-database updates do.

sequenceDiagram participant Firmware participant BootMgr as bootmgfw.efi participant TPM participant Winload as winload.efi Firmware->>TPM: TPM2_PCR_Extend (PCR[0-7]) BootMgr->>TPM: TPM2_PCR_Extend (PCR[4], PCR[11], PCR[12]) BootMgr->>TPM: TPM2_StartAuthSession BootMgr->>TPM: TPM2_PolicyPCR (selection = current profile) BootMgr->>TPM: TPM2_Unseal (sealed VMK blob) alt PCRs match seal-time digest TPM-->>BootMgr: VMK plaintext BootMgr->>Winload: hand off, VMK in protected memory Winload-->>Firmware: continue boot else PCRs do not match TPM-->>BootMgr: TPM_RC_POLICY_FAIL BootMgr-->>BootMgr: prompt for 48-digit recovery key end

The on-disk registry path that records the profile choice is HKLM\SOFTWARE\Policies\Microsoft\FVE\PlatformValidationProfileUEFI [@ms-learn-bitlocker-gpo]. The value is a 24-bit bitmask where bit N selects PCR[N]. A device that sealed under the default 0x880 profile and then has Group Policy changed to 0x815 will not automatically re-seal -- you must explicitly disable and re-enable the TPM protector with manage-bde -protectors [@ms-manage-bde-protectors] to rotate the policy.

A small utility decodes the bitmask:

{` function decodeProfile(mask) { const selected = []; for (let bit = 0; bit < 24; bit++) { if (mask & (1 << bit)) selected.push(bit); } return selected; }

console.log('Default UEFI profile (0x880):', decodeProfile(0x880)); console.log('Legacy CSM profile (0x815): ', decodeProfile(0x815)); console.log('A more restrictive profile (0x8D5):', decodeProfile(0x8D5));

// Output: // Default UEFI profile (0x880): [7, 11] (PCR[7]+PCR[11]) // Legacy CSM profile (0x815): [0, 2, 4, 11] (PCR[0]+PCR[2]+PCR[4]+PCR[11]) // A more restrictive profile (0x8D5): [0, 2, 4, 6, 7, 11] `}

Run it. Your machine's profile mask is one of those three (or close enough). If the mask includes PCR[0], every firmware update will trigger a recovery prompt. If it omits PCR[0] but includes PCR[7], only Secure Boot key changes (Microsoft's annual dbx updates, third-party Linux enrolments, BIOS-setup Secure Boot toggles) will. The four canonical recovery-prompt causes follow directly:

Cause	PCR affected	Mitigation
UEFI firmware update	PCR[0]	Suspend BitLocker before update; legacy profile only
Microsoft `dbx` update or Secure Boot key rotation	PCR[7]	Suspend BitLocker before patch Tuesday
Boot-manager binary swap (KB-driven update)	PCR[4], PCR[11]	Suspend BitLocker before cumulative update
Firmware setup change (virtualization toggle, device enable/disable)	PCR[1]	Suspend BitLocker before deliberate change

We have walked the chain. What about the chain we cannot trust -- the OEM-vendor-firmware-allowlist explosion that overwhelms remote verifiers?

7. Competing Approaches: DRTM, Late Launch, and Secure Launch

A quote from Microsoft's hardware-root-of-trust documentation [@ms-learn-hwrot] frames the problem precisely: "As there are thousands of PC vendors that produce many models with different UEFI BIOS versions, there becomes an incredibly large number of SRTM measurements upon bootup. Two techniques exist to establish trust here -- either maintain a list of known 'bad' SRTM measurements (also known as a blocklist), or a list of known 'good' SRTM measurements (also known as an allowlist)."

The allowlist explodes. Every OEM, every model, every firmware revision, every Secure Boot key generation produces a fresh PCR[0]/PCR[7]/PCR[11] tuple. A central verifier that wants to assert "this fleet booted firmware Microsoft has signed off on" has to maintain a database whose cardinality grows quadratically in (vendors x firmware versions). By 2017 the table size made the verifier policy ungovernable for general-purpose Windows fleets.

The fix is structural: introduce a second measurement plane that does not depend on the OEM. From the same Microsoft document: "System Guard Secure Launch, first introduced in Windows 10 version 1809, aims to alleviate these issues by using a technology known as the Dynamic Root of Trust for Measurement (DRTM)." And: "Secure Launch simplifies management of SRTM measurements because the launch code is now unrelated to a specific hardware configuration."

DRTM is a CPU primitive. On Intel, it is GETSEC[SENTER], introduced with Trusted Execution Technology in 2007. From the Intel SDM mirror, verbatim: "GETSEC[SENTER] / Launch a measured environment. EBX holds the SINIT authenticated code module physical base address. ECX holds the SINIT authenticated code module size (bytes)." On AMD, the equivalent is the SKINIT instruction from the AMD-V (SVM) family, introduced with the first AMD-V silicon in 2005-2006 [@wiki-x86-virt]. Microsoft's Secure Launch implementation [@ms-learn-sgsl] issues SENTER or SKINIT from a small Secure Kernel Loader (SKL) inside winload.efi.

What SENTER and SKINIT do, at machine level, is roughly identical: they suspend all but one CPU, reset PCRs 17 through 22 in the TPM to a defined value (zero for SHA-256, all-ones for SHA-1 historically; the SHA-256 reset value is UNVERIFIED_FETCH -- the TCG PFP returns HTTP 403 to non-browser agents), load the launch module (Intel verifies the signature on its SINIT Authenticated Code Module; AMD measures its Secure Loader Block rather than checking a signature), and atomically transfer control to it with interrupts disabled and the IOMMU active. The ACM/SLB's measurement gets extended into PCR[17]; the Measured Launch Environment (MLE) it loads -- on Windows, the Hyper-V hypervisor and the secure kernel -- gets extended into PCR[18].

The code body that the DRTM primitive ($SENTER$/$SKINIT$) measures into PCR[18] after the Authenticated Code Module (Intel) or Secure Loader Block (AMD) has been measured into PCR[17] and verified. On Microsoft Secure Launch, the MLE is the hypervisor plus the secure kernel. On Linux+TrenchBoot, the MLE is the GRUB late-launch component plus the kernel.

The reason SENTER and SKINIT matter, beyond the resetting of PCRs 17-22, is what they don't measure. They do not measure the PEI/DXE firmware. They do not measure option ROMs. They do not measure the entire SRTM trail in PCRs 0-7. A verifier that consumes only PCRs 17-22 sees a uniform digest across every Intel platform (because every Intel platform runs the same Intel-signed ACM) and every Microsoft Secure-Launch-capable system (because every such system runs the same Microsoft-signed SKL). The OEM diversity is absorbed by ignoring the diverse measurements.

The Rutkowska / Wojtczuk SMM attack and the DRTM preconditions

Before SENTER could be trusted, it had to survive a DMA attack class that Joanna Rutkowska and Rafal Wojtczuk demonstrated at Black Hat DC 2009 [@itl-attacking-txt-2009]. Their paper's abstract is direct: "We describe a practical attack that is capable of bypassing the TXT's trusted boot process". The mechanism: between the signature check on the SINIT ACM and its execution, a DMA-capable peripheral could overwrite the verified payload. Intel's response was architectural -- route SINIT through IOMMU-protected memory, and refuse to start SENTER if the IOMMU is not on. The fix is enforced at the instruction level: the SDM mirror's GETSEC[SENTER] description lists the chipset and TPM preconditions GETSEC[SENTER] now checks before opening the measured-launch window. Every modern DRTM design rests on the assumption that the IOMMU is active at the late-launch instant.

DRTM does not replace SRTM; it layers on top. SRTM still measures everything pre-late-launch into PCRs 0-7 and 11-14. DRTM resets a separate slice (PCRs 17-22) and starts fresh. A verifier that wants the small OEM-invariant TCB consumes the DRTM slice and ignores PCRs 0-16. A verifier that wants the full pre-late-launch history consumes the SRTM slice and ignores 17-22. A verifier that wants both -- say, "the firmware was on the allowlist *and* the secure kernel started cleanly" -- consumes both. The cost is one extra `TPM2_Quote` selection mask. The benefit is that you can change attestation policy without changing the measurement plane.

Microsoft Secure Launch and the Secured-Core PC bar

Microsoft's Secured-core PC programme [@ms-learn-secured-core] packages Secure Launch with a set of other hardware requirements: SMM Supervisor, kernel DMA protection, Boot Guard or PSP firmware, Pluton or equivalent silicon root of trust, and Memory Integrity (HVCI) enabled by default. The Microsoft framing: "Microsoft is working closely with OEM partners and silicon vendors to build Secured-core PCs that features deeply integrated hardware, firmware and software to ensure enhanced security for devices, identities and data." The result is a tier-1 SKU set whose attestation evidence is the small OEM-invariant DRTM TCB, not the large SRTM history.

Operationally, the Secured-Core flag enables the configuration block at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios per Microsoft's Secure Launch configuration guide [@ms-learn-sgsl]. When the registry flag is set and the silicon supports late launch, winload.efi issues SENTER/SKINIT after measuring the early kernel, and the hypervisor launches inside the MLE.

TrenchBoot: open-source DRTM for Linux

DRTM is not Windows-only. The TrenchBoot project [@trenchboot-org] -- with contributors from Apertus Solutions, Oracle, and 3mdeb [@trenchboot-org] -- maintains an open-source DRTM stack for Linux and Xen on GRUB. From the TrenchBoot documentation repo [@gh-trenchboot-docs]: "TrenchBoot is a framework that allows individuals and projects to build security engines to perform launch integrity actions for their systems." The Linux side of the same primitive that Microsoft Secure Launch uses on Windows.

flowchart TD subgraph SRTM["SRTM chain (PCRs 0-7, 11-14)"] S1["CRTM"] --> S2["PEI/DXE"] --> S3["option ROMs"] --> S4["BDS"] S4 --> S5["bootmgfw.efi"] --> S6["winload.efi (early)"] end subgraph DRTM["DRTM chain (PCRs 17-22)"] D1["SKL issues SENTER / SKINIT"] --> D2["CPU resets PCRs 17-22"] D2 --> D3["ACM/SLB extended into PCR[17]"] D3 --> D4["MLE (hypervisor + secure kernel) into PCR[18]"] D4 --> D5["Secure kernel boots; IOMMU active"] end S6 --> D1

The comparison below synthesizes the TCG PFP PCR allocation surfaced in Microsoft's Tbsi_Get_TCG_Log reference [@ms-tbs-get-tcg-log] with the Microsoft hardware-root-of-trust documentation [@ms-learn-hwrot] and the BitLocker countermeasures unlock-mode enumeration [@ms-learn-bitlocker-counter]:

Property	SRTM (PCR[0-7,11-14])	DRTM (PCR[17-22])	TPM-only BitLocker (seal PCR[7,11])	TPM+PIN
Trust-anchor size	OEM CRTM + firmware + option ROMs + drivers (large)	Vendor ACM/SLB + MLE only (small)	Same as SRTM	Same + human PIN secret
Hardware required	Any TPM 2.0 platform	Intel TXT-capable or AMD SVM-capable + IOMMU	Same as SRTM	Same
Recovery prompts/year	High (firmware + dbx + boot manager)	Low (PCR[17-22] not in default profile)	High on TPM-only profile	Same as seal profile
bitpixie-class attack	Vulnerable	Not directly mitigated	Vulnerable	Mitigated (PIN required)
Verifier policy size	O(vendors x versions)	O(vendor)	O(profile)	O(profile + PIN policy)

DRTM solves the OEM diversity problem. It does not solve the problem that the log is unsigned, the measurement is a hash and not a good hash, and the CRTM is an axiom. What can measurement never prove?

8. Theoretical Limits: What Measurement Can Never Prove

Restate the axiom from §2: the first hash in the chain is an axiom; the silicon that computes it is itself unmeasured. CRTM is the Root of Trust for Measurement, not the Root of Trust for Everything. The trust we can claim is that, given the integrity of the silicon and the immutability of the embedded keys, the chain is a faithful record of what ran. The "given" is doing all the work.

Three limits, each architectural and not implementational.

8.1 Trust on first measurement

The CRTM has nothing under it. If you compromise the silicon -- through a faulTPM-class SoC voltage glitch against an AMD fTPM, through SPI-bus sniffing of a discrete TPM, through a Pluton supply-chain tamper, through an Intel Boot Guard key extraction -- the rest of the chain is, formally, useless. The verifier asks the chip "what ran?"; the chip computes the answer using cryptographic primitives the chip itself implements; if the chip is malicious, every answer is consistent with whatever boot history the attacker wishes. The TPM's TPM2_Quote signature is bound to the chip's own AIK; if the chip is the attacker, the signature is honest about a lie.

This is not a flaw of TPM 2.0. It is a feature of mathematics. You cannot bootstrap trust from nothing. AEGIS knew this in 1997; the TCG accepted it in 1999; every silicon root of trust still depends on it in 2026. The only mitigations are (a) make the silicon as small and audited and physically resistant as the budget allows (which is why Pluton ships a separate sub-millimetre microcontroller), and (b) bind the chip's identity to a manufacturer-rooted certificate chain that an out-of-band auditor can verify -- which is why Hello for Business enrollment cross-checks the EK certificate against the OEM root before issuing the device-bound key.

8.2 A PCR value is a hash, not a good hash

The TPM has no knowledge of what is good. PCR[0] holding 0xC4F7... is just a number. To the TPM it is no more or less suspicious than 0xA21E.... The TPM's job, during TPM2_PolicyPCR+TPM2_Unseal, is to refuse the key release if the PCRs do not match the seal-time digest -- regardless of whether the seal-time digest was a benign value or a malicious one.

A PCR value is a hash, not a *good* hash.

This is why a sealed BitLocker VMK released on a successful TPM2_PolicyPCR match is not a guarantee that the booted code was actually trustworthy. It is a guarantee that the booted code matched the seal-time digest. If at seal time the platform was running an older, signed, but vulnerable bootmgfw.efi, the seal binds to that boot manager's PCR[11]. Years later, when an attacker downgrades to that same older, signed boot manager, PCR[11] reproduces the seal-time digest exactly, and the TPM cheerfully releases the key. This is the mechanism that makes bitpixie work; we will meet it again in Section 9.

The verifier -- BitLocker policy, Azure Attestation policy, Intune DHA, your fleet management tool -- is the only entity that knows what good means. The TPM provides reporting infrastructure; the verifier provides policy infrastructure. Measurement is reporting infrastructure, not policy infrastructure.

Key idea: Measurement is reporting infrastructure, not policy infrastructure. The TPM knows what was measured; only the verifier knows what is good. Every BitLocker unseal, every Azure Attestation, every Intune DHA verdict is a policy decision made by software outside the TPM, against a number the TPM merely reports.

Note: A sealed VMK released on a successful TPM2_PolicyPCR match is not a guarantee that the booted code was actually trustworthy. It is a guarantee that the booted code matched the seal-time digest. If seal time captured a vulnerable but signed binary, every subsequent boot of that same vulnerable signed binary will unseal cleanly. This is the architectural reason bitpixie works against TPM-only BitLocker even on fully patched 2025 firmware.

8.3 The log is unsigned

TPM2_Quote signs only the PCR values plus the verifier's nonce. It does not sign the TCG event log. A malicious firmware can extend an honest digest into the TPM and report a different event in the log it hands the OS. The PCR is correct; the log is a fabrication. Detection comes only from the verifier replaying the log against the quoted PCRs and flagging a mismatch.

In practice this is not a problem on benign firmware, because the firmware has no incentive to lie about its own events. It becomes a problem precisely in the cases where the firmware is the attacker -- BlackLotus-class implants that own the boot manager, faulTPM-class chip compromises that own the TPM. In those cases, a verifier that trusts both the log and the quote without replaying is trusting a forged document.

The mitigation is structural and well-known: verifiers MUST replay. Azure Attestation, Intune DHA, and Microsoft's reference attestation library all replay the log against the quoted PCRs and refuse to issue a token on mismatch. Operators rolling their own attestation pipeline often skip the replay step, especially in early-prototype deployments. Skip the replay and you have an unauthenticated event list dressed up as evidence.

8.4 The cuckoo attestation class (Parno 2008)

There is a class of attack that no amount of replay or PCR profile tightening can stop. Bryan Parno's 2008 HotSec paper [@parno-hotsec-pdf] names the problem the cuckoo attack and proposes the first formal model for establishing trust in a platform under that threat. The abstract, paraphrased lightly to fit this article's word-list: any naive approach falls victim to a cuckoo attack; the model, in Parno's own phrasing, "reveals the cuckoo attack problem".

An attestation-relay attack in which a verifier challenges a compromised device, the compromised device proxies the challenge to a separate, genuine, attested device elsewhere, the genuine device produces a valid signed quote, the compromised device returns that quote as if it were its own, and the verifier accepts. Without out-of-band identification of *this* device's endorsement key, the verifier cannot distinguish "the EK that signed the quote" from "an EK in the world that signed a quote." Named by Bryan Parno in 2008 by analogy with the cuckoo bird's brood parasitism. A TPM-resident asymmetric key whose certificate is signed by the platform's Endorsement Key certificate chain, used to sign `TPM2_Quote` responses. The verifier checks the AK's certificate chain to the OEM root before trusting the quote. If the EK chain is not pre-bound to *this* device's serial number (or some other out-of-band identifier), an attacker can relay the challenge to a different TPM and return a valid signature from that TPM's AK.

The cuckoo class is closeable, but only by binding the AK to this device's identity before trust is needed. Microsoft Autopilot [@ms-aa-tpm-concepts] and Windows Hello for Business do this transparently during device enrollment: the EK certificate chain is captured at first boot, cross-checked against the OEM root, and the resulting AK is bound to a specific Microsoft Entra ID device object. Ad-hoc attestation deployments that do not capture the EK chain at enrollment are vulnerable.

Bryan Parno is now at Carnegie Mellon [@cmu-parno] and was on sabbatical at Amazon during 2025. The cuckoo paper remains, on its eighteenth birthday, the canonical reference for the class.

Permanent limits accepted. What are people actively trying to fix that we have not solved yet?

9. Open Problems: bitpixie, the dbx-Update UX, and What's Next

The fix is the breakage. The patch that closes the most dangerous BitLocker bypass of the decade is also the patch that drowns help-desks in 48-digit recovery prompts. The structural entanglement of these two facts is the central open problem of measured boot in 2026.

9.1 bitpixie (CVE-2023-21563)

An attacker reaches behind a fully-patched, BitLocker-enabled Windows 11 laptop. They plug in a LAN cable. They plug in a USB keyboard. They press F12 to boot from network. Within five minutes the disk encryption key is on their disk.

That is bitpixie. From the Neodyme write-up [@neodyme-bitpixie]: "Thanks to a bug discovered by Rairii in August 2022, attackers can extract your disk encryption key on Windows' default 'Device Encryption' setup. This exploit, dubbed bitpixie, relies on downgrading the Windows Boot Manager. All an attacker needs is the ability to plug in a LAN cable and keyboard to decrypt the disk." The CVE is CVE-2023-21563 [@nvd-2023-21563], described as a "BitLocker Security Feature Bypass Vulnerability" with the MSRC advisory at CVE-2023-21563 [@msrc-2023-21563].

The mechanism is the second aha moment from Section 8 made operational. From SySS's bitpixie technical write-up [@syss-bitpixie]: "The bitpixie vulnerability in Windows Boot Manager is caused by a flaw in the PXE soft reboot feature, whereby the BitLocker key is not erased from memory. To exploit this vulnerability on up-to-date systems, a downgrade attack can be performed by loading an older, unpatched boot manager."

The chain in detail: (1) The attacker boots the target normally. The boot manager unseals the VMK, hands it to winload.efi, and loads BitLocker into the boot path. (2) Before winload.efi zeroes the VMK from RAM, the attacker triggers a PXE soft reboot (a feature of older boot manager versions) that returns control to the boot manager without a full platform reset. (3) The attacker now PXE-boots a Linux image that scans physical memory for the BitLocker FVE marker -FVE-FS- and extracts the VMK. The platform reset never happened, the RAM never cleared, the TPM never re-quoted -- the VMK is just lying there in untouched physical memory.

The downgrade: the older boot manager whose soft-reboot path leaks the VMK is still signed by the Microsoft 2011 production certificate, which is still in db on every Secure Boot machine until that certificate's natural 2026 expiry. PCR[7] -- the policy PCR -- accepts the downgraded boot manager because the boot manager is still validly signed. PCR[11] still matches the seal-time digest because, at seal time, that exact older boot manager was the one running. The TPM unseals. BitLocker unlocks. The attack proceeds.

This is the third aha moment from the article's structure: a PCR replay attack with a still-trusted older signed binary. The TPM is not malfunctioning. The policy is not misconfigured. The seal is doing exactly what it was sealed to do: release the key if the boot reproduces the boot it was sealed against. The attacker just produced the seal-time boot, in 2024, using a signed-but-vulnerable binary the verifier has not revoked.

Public disclosure landed at the 38th Chaos Communication Congress in December 2024 [@38c3-bitpixie]. From the talk abstract verbatim: "since 2022, when Rairii discovered the bitpixie bug (CVE-2023-21563). While this bug is 'fixed' since Nov. 2022 and publically known since 2023, we can still use it today with a downgrade attack to decrypt BitLocker." The full attack chain was demonstrated on stage by Thomas Lambertz of Neodyme. The proof-of-concept code is at github.com/martanne/bitpixie [@gh-martanne-bitpixie].The repository handle martanne is the GitHub username; the discoverer is Rairii (August 2022); the 38C3 presenter is Thomas Lambertz (Neodyme). Press accounts that refer to "martanne" as a person are confusing the GitHub handle with an author identity.

9.2 The KB5025885 / Windows UEFI CA 2023 rotation

Microsoft's structural response is documented in the canonical KB article on Boot Manager revocations [@ms-kb5025885]. The fix is in three stages. Stage 1: enroll the new Windows UEFI CA 2023 certificate in the Secure Boot db variable. Stage 2: replace existing boot manager binaries with copies signed by the 2023 CA instead of the 2011 CA. Stage 3: revoke the 2011 CA in dbx. The full rollout is gated on the 2026 natural expiry of the original Microsoft production signing certificate.

Every one of those three stages changes PCR[7]. Every one. Stage 1 adds bytes to db; Stage 3 adds bytes to dbx; even Stage 2, which doesn't touch the Secure Boot variables directly, ships a new boot manager binary whose Authenticode digest moves PCR[4]. On TPM-only BitLocker bound to 0x880 = PCR[7] + PCR[11], the recovery prompt fires twice for every customer.

9.3 BlackLotus (CVE-2022-21894 "Baton Drop")

The bitpixie story does not stand alone. On March 1, 2023, ESET researcher Martin Smolár disclosed BlackLotus [@eset-blacklotus] -- in his own words, "the first publicly known UEFI bootkit bypassing the essential platform security feature -- UEFI Secure Boot -- is now a reality." BlackLotus exploits CVE-2022-21894 [@nvd-2022-21894] ("Baton Drop"), a Secure Boot bypass in a Microsoft-signed boot manager. From the ESET write-up [@eset-blacklotus]: "Although the vulnerability was fixed in Microsoft's January 2022 update, its exploitation is still possible as the affected, validly signed binaries have still not been added to the UEFI revocation list. BlackLotus takes advantage of this, bringing its own copies of legitimate -- but vulnerable -- binaries to the system in order to exploit the vulnerability."

The structural fix for BlackLotus is identical to the structural fix for bitpixie: revoke the vulnerable signed binaries in dbx. Microsoft shipped the BlackLotus dbx revocations in May 2023; that update is the source of most of the "PCR[7] moved overnight" stories from the second half of 2023. The break-fix-break loop is now a recurring operational reality, not an exception.

the first publicly known UEFI bootkit bypassing the essential platform security feature -- UEFI Secure Boot -- is now a reality. -- Martin Smolár, ESET Research, March 1, 2023

9.4 The break-fix-break loop

Key idea: The fix is the breakage. Every dbx update that closes a Secure Boot bypass changes PCR[7]. Every PCR[7] change forces a 48-digit recovery prompt on every TPM-only BitLocker machine on the platform. The patch that closes BlackLotus or bitpixie is the operational pain. Pre-boot authentication (TPM+PIN) blocks the downgrade attack from releasing the VMK without the user's PIN, but it does not eliminate PCR[7]-driven recovery: a selected-PCR change still forces suspend/resume or a planned reseal.

flowchart LR A["BlackLotus disclosed
(March 2023)"] --> B["Microsoft May 2023 dbx update
revokes vulnerable boot managers"] B --> C["PCR[7] changes on every
UEFI Windows machine"] C --> D["TPM-only BitLocker fires
fleet-wide 48-digit prompts"] D --> E["Operators delay patches
or roll back to gain stability"] E --> F["Window of vulnerability
re-opens for class"] F --> A

Note: The only safe pattern when applying UEFI firmware, BIOS, or Secure Boot DB/DBX changes is to suspend BitLocker first. Run Suspend-BitLocker -RebootCount 1 from an elevated PowerShell prompt, apply the patch, and let the suspend auto-resume on the next clean boot. The TPM never sees a PCR mismatch because BitLocker is not asking the TPM for the VMK during the patch reboot.

9.5 Post-quantum agility for the attestation key

Looking ahead, the next structural break is cryptographic: the TPM's signing primitives (RSA-2048, ECC P-256) do not survive Shor's algorithm on a sufficiently large quantum computer. The TCG's PC Client Platform Firmware Profile revision 2 work is targeting post-quantum agility for attestation keys -- ML-DSA (Dilithium) and ML-KEM (Kyber) variants of the signature and key-encapsulation primitives that TPM2_Quote and TPM2_ActivateCredential depend on.

The constraint that limits the rollout is mechanical. The TPM 2.0 command and response buffer is, by default, 4096 bytes. A Dilithium Level 3 (ML-DSA-65) signature is 3,309 bytes per FIPS 204 [@csrc-nist-gov-204-final]. An RSA-2048 signature is 256 bytes. The buffer survives RSA quotes with vast headroom; it has roughly 800 bytes of headroom for an ML-DSA-65 quote. ML-KEM-768 (NIST Category 3) ciphertexts are 1,088 bytes per FIPS 203 [@csrc-nist-gov-203-final], with public keys at 1,184 bytes -- still tight if you also need an ML-DSA-65 signature on the same response. The PFP r2 work is largely about negotiating buffer growth across the TPM-firmware-OS path so the post-quantum primitives fit. As of 2026 this is UNVERIFIED_FETCH from the TCG (the TCG specifications site [@tcg-tpm-library] returns HTTP 403 to non-browser User-Agents), but Microsoft has signalled interim TPM 2.0 deployments with enlarged buffers.

9.6 DRTM coverage gaps

DRTM is a Secured-core feature; not every fleet runs Secured-core hardware. Raw Intel TXT has shipped on vPro platforms since the Q3 2007 introduction of the Intel DQ35J board [@itl-attacking-txt-2009], but the deployable surface for Microsoft Secure Launch is narrower because Secured-Core also requires HVCI, kernel DMA protection, and an SMM Supervisor. In practice Secure Launch is available on Intel Coffee Lake (Core 8th-generation) and later platforms; on AMD with Zen 2 and later (Ryzen 3000+ desktop; EPYC 7002+ server with SKINIT); and on Qualcomm Snapdragon SD850 and later on the ARM side. Fleets dominated by pre-2018 hardware -- and there are many of them, especially in cost-sensitive deployments -- cannot use Secure Launch as a SRTM allowlist substitute.

For those fleets, the only deployable mitigation against bitpixie remains pre-boot authentication (TPM+PIN). The cuckoo class remains open against ad-hoc attestation pipelines that do not bind AKs to device serials at provisioning. The OEM allowlist combinatorial explosion remains the unsolved problem that pushed Microsoft to DRTM in the first place.

9.7 PFP r2 in flight

The PC Client Platform Firmware Profile is in active revision. PFP r2 is expected to formalise SHA-3 support, change the default banks to SHA-384 and SHA-512 (with SHA-256 retained for legacy compatibility), and codify the PCR[14] semantics that have been a Microsoft-vs-Linux ontology disagreement for the past decade. As of 2026 the revision is UNVERIFIED_FETCH from the TCG canonical URL [@tcg-pfp] (same 403 class); the tpm2_eventlog man page [@gh-tpm2-eventlog-man] tracks the spec by name without a rev number, deliberately so it can absorb r2 without rebuild.

For practitioners who need a current catalogue of hardware-debugger gaps that PCR[7]'s `EV_EFI_ACTION` event was supposed to close, the Wack0/bitlocker-attacks repository [@gh-wack0-bitlocker] maintains a curated index, including a reference to a DFRWS Europe 2023 paper from the Brazilian Federal Police that catalogued debug-mode firmware shipped to retail. The TCG EFI Platform Specification §6.4 quote reproduced there -- *"If the platform provides a firmware debugger mode... the platform SHALL extend an EV_EFI_ACTION event into PCR[7]"* -- exists precisely because shipped firmware historically did not always do this. The PCR[7] floor is not as solid as the specification suggests.

You have read 8,000 words. You have a recovery prompt to clear on Monday morning. What do you do?

10. Practical Guide: A Monday-Morning Checklist

Six actions. Each one tied to a verified Microsoft Learn or TCG source. Run them in order; you will know more about your fleet's measured-boot posture in twenty minutes than most operators learn in a year.

10.1 Inspect your log

Run tpmtool.exe getdeviceinformation from an elevated prompt; §6.7 enumerates the cross-platform and Linux equivalents. For a clean machine-readable dump, save the binary log via MeasuredBootTool.exe -log <path> [@ms-tbs-get-tcg-log] (Windows HLK), then parse it with tpm2_eventlog [@gh-tpm2-eventlog-man] for a portable text dump. The event stream conforms to the TCG_PCR_EVENT2 struct documented in the Tbsi_Get_TCG_Log reference [@ms-tbs-get-tcg-log].

10.2 Confirm your BitLocker PCR profile

Run manage-bde -status C: from an elevated prompt. Confirm a Numerical Password protector exists -- without one, you cannot recover from a profile mismatch and you are one PCR drift away from data loss. Then inspect HKLM\SOFTWARE\Policies\Microsoft\FVE\PlatformValidationProfileUEFI. On a Secure Boot UEFI machine the value should be 0x880 (PCR[7] + PCR[11]) per the BitLocker countermeasures documentation [@ms-learn-bitlocker-counter]: "By default, BitLocker provides integrity protection for Secure Boot by using the TPM PCR[7] measurement."

If you see 0x815 (PCR[0,2,4,11]), you are on the non-PCR[7] legacy validation profile (a CSM/legacy boot, or a UEFI system where Secure Boot PCR[7] binding is unavailable) and every firmware update will trigger a recovery prompt. The fix is to verify Secure Boot is on (Confirm-SecureBootUEFI from PowerShell), then re-seal by disabling and re-enabling the TPM protector.

10.3 Suspend BitLocker before every firmware update

The only safe pattern is this:

```powershell # Run as administrator. # Suspend BitLocker for the next 1 reboot. BitLocker auto-resumes after the # next clean boot completes, regardless of how many additional boots happen. Suspend-BitLocker -MountPoint "C:" -RebootCount 1Now run the OEM firmware updater or the Windows cumulative update that touches Secure Boot. The PCRs will move; BitLocker will not see a mismatch because the seal check is bypassed for this boot. After the patch reboot, BitLocker automatically re-seals to the new PCR values. To verify, run:

manage-bde -status C:

The output should show "Protection On" and the new PCR profile.

</Spoiler>

### 10.4 Enable Secure Launch on Secured-Core hardware

If your hardware supports DRTM (Intel TXT-capable Coffee Lake or later, AMD Zen 2 or later with `SKINIT`, ARM SD850 or later), enable Secure Launch. The configuration guide [@ms-learn-sgsl] lists the four paths: MDM via Intune, Group Policy, the Windows Security UI, or the registry directly at `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios`. Once enabled, Secure Launch absorbs OEM firmware diversity into the small DRTM TCB, reducing the verifier's allowlist burden from O(vendors x firmware versions) to O(vendor).

### 10.5 For high-value devices, switch to TPM+PIN

This is the only deployed mitigation that closes bitpixie pre-attack. From Microsoft's countermeasures documentation [@ms-learn-bitlocker-counter], four unlock modes exist: TPM-only, TPM+startup-key, TPM+PIN, TPM+startup-key+PIN. Of those, only the modes that require a human secret survive a downgrade attack -- the attacker can recreate the seal-time PCRs by booting an older signed boot manager, but they cannot recreate the PIN.

Enable it with `manage-bde -protectors -add C: -tpmandpin <PIN>`. Users will type the PIN at boot. For Secured-Core fleets where the BIOS exposes USB and TPM+PIN before the OS, this is the best practical security/UX trade. For high-value developer or executive endpoints it is non-negotiable.

> **Note:** bitpixie. Every other recoverable class -- evil-maid via tampered USB, cold-boot RAM extraction at modest cost, supply-chain implants on the firmware -- has either operational mitigations or is out-of-budget for the threat model. bitpixie does not. Pre-boot authentication closes it; nothing else does.

### 10.6 Bind your attestation keys to the device at provisioning

The cuckoo class only closes if the verifier knows the *specific* TPM's endorsement key before trust is needed. Microsoft Autopilot and Hello for Business do this transparently [@ms-aa-tpm-concepts] during device enrollment, capturing the EK certificate chain and cross-checking it against the OEM root before issuing the device-bound key. Ad-hoc deployments -- "we joined our domain after first boot" -- usually skip this step and leave the cuckoo path open. If you run an attestation pipeline outside Hello for Business or Azure Attestation, audit your AK provisioning: is the EK chain captured at first boot, and is it bound to a unique device record?

The Monday-morning steps are six items long. The structural questions are not. We close with the questions every reader still has.

## 11. Frequently Asked Questions

<FAQ title="Frequently asked questions about Measured Boot and PCR-bound BitLocker">

<FAQItem question="Why am I being prompted for a 48-digit recovery key after a BIOS update?">
Because PCR[0] or PCR[7] changed. BitLocker's seal binds the Volume Master Key to a specific subset of PCR values captured at seal time. A UEFI firmware update changes the `EV_S_CRTM_VERSION` and `EV_EFI_PLATFORM_FIRMWARE_BLOB` digests in PCR[0]; a Secure Boot `dbx` update changes PCR[7]. On boot, the TPM runs `TPM2_PolicyPCR` against the current PCRs, fails the match, and refuses to release the VMK. BitLocker falls back to the recovery-key protector. The fix is to suspend BitLocker before the patch with `Suspend-BitLocker -MountPoint "C:" -RebootCount 1`, per Microsoft's BitLocker countermeasures documentation [@ms-learn-bitlocker-counter].
</FAQItem>

<FAQItem question="What's the difference between Secure Boot and Measured Boot?">
Secure Boot is *enforcement*: it refuses to run code that isn't signed by a trusted certificate in the `db` variable. Measured Boot is *reporting*: it records what ran -- signed or not -- into PCRs and the TCG event log. They cooperate but don't substitute. Secure Boot stops a bootkit from running. Measured Boot lets a remote verifier confirm, after the fact, that no bootkit ran. The TPM-based Trusted Boot extension [@ms-learn-boot-process] continues the measurement chain into the Windows kernel, drivers, and ELAM.
</FAQItem>

<FAQItem question="If Secure Boot is on, do I still need Measured Boot?">
Yes. The remote-attestation evidence chain is a measured-boot artifact -- Azure Attestation, Intune Device Health Attestation, Hello for Business device-bound key attestation, BitLocker PCR-bound unseal, and System Guard runtime attestation all consult the TCG event log and PCR snapshot. Secure Boot has no remote-reporting story; it cannot, by itself, prove to a verifier in Azure that this laptop in the field booted the firmware Microsoft signed off on. Measured Boot is what makes that proof possible.
</FAQItem>

<FAQItem question="Why does BitLocker bind to PCR[7] instead of PCR[0,2,4,11]?">
Because PCR[7] is the *policy* PCR, not the *code* PCR. Firmware updates and option-ROM changes move PCR[0] and PCR[2]; Secure-Boot-policy hashes don't change unless the actual `PK`/`KEK`/`db`/`dbx` variables change. The result: a fleet on the default UEFI profile (`0x880` = PCR[7] + PCR[11]) survives Dell and HP and Lenovo firmware updates without recovery prompts, because those vendors' firmware updates move PCR[0] and not PCR[7]. The trade-off is that PCR[7] only moves when Secure Boot's identity moves -- which is exactly when you do want a recovery prompt (a key revocation is a real security event). Microsoft makes the trade-off explicit in the BitLocker countermeasures documentation [@ms-learn-bitlocker-counter].
</FAQItem>

<FAQItem question="Can attestation prove my OS isn't compromised right now?">
No. Attestation proves what *booted*. It captures the boot-time state of the platform up to a `EV_SEPARATOR` event the kernel emits early in OS bootstrap. Anything that happens after the separator -- a malicious kernel driver loaded at runtime, a memory-corruption exploit in a Win32 service, a rootkit that bypasses HVCI -- is invisible to PCR-based attestation. The runtime-attestation problem is what Windows Defender System Guard runtime attestation [@ms-learn-sgsl] and Microsoft's hypervisor-isolated runtime checks try to address; that is a separate trust system layered on top of measured boot, not part of it.
</FAQItem>

<FAQItem question="What is PCR[14] for on Windows?">
Microsoft's Windows Boot Configuration Log convention uses PCR[14] for boot-loader-authority events -- WBCL records that capture which authorities the boot manager consulted for code-integrity decisions. The Linux shim convention uses PCR[14] for Machine Owner Key (MOK) enrolment events. Same PCR index; different ontology. A verifier reading PCR[14] must know which OS produced the log it is reading; the value is meaningless without that context. This is one of the corner cases PFP r2 is expected to formalise.
</FAQItem>

<FAQItem question="Is bitpixie fixed?">
Not on TPM-only BitLocker, not yet. The structural fix is KB5025885 [@ms-kb5025885] (May 2023) which enrolls the new Windows UEFI CA 2023 certificate and ultimately revokes the 2011 CA in `dbx`. Full revocation is gated on the 2011 CA's 2026 natural expiry. Until then, an attacker can still downgrade to a 2011-signed boot manager whose PXE-soft-reboot path leaks the VMK. The only pre-attack mitigation that closes the class today is pre-boot authentication: TPM+PIN, or TPM+startup-key, or both. The 38C3 talk demonstrated the attack on fully-patched late-2024 firmware.
</FAQItem>

</FAQ>

<StudyGuide slug="measured-boot-tcg-event-log" keyTerms={[
  { term: "PCR (Platform Configuration Register)", definition: "Append-only TPM register that extends rather than stores. Modern TPMs have 24 PCRs per hash bank; `PCR[N] := H(PCR[N] || measurement)`." },
  { term: "CRTM (Core Root of Trust for Measurement)", definition: "The smallest, lowest, immutable code that runs after platform reset. It measures the next firmware stage into PCR[0] and is an axiomatic root, not a verified one." },
  { term: "SRTM (Static Root of Trust for Measurement)", definition: "The measurement chain rooted at the CRTM, covering PCRs 0-7 and 11-14 across firmware, boot manager, OS loader, ELAM, and kernel." },
  { term: "DRTM (Dynamic Root of Trust for Measurement)", definition: "Mid-boot CPU primitive (Intel `GETSEC[SENTER]`, AMD `SKINIT`) that resets PCRs 17-22 and atomically launches a vendor-signed Authenticated Code Module plus a Measured Launch Environment." },
  { term: "TCG Event Log / WBCL", definition: "Ordered list of `TCG_PCR_EVENT2` records (with Microsoft-specific WBCL extensions in PCRs 11/12/13) that the verifier replays to re-derive PCR values from a `TPM2_Quote`." },
  { term: "TPM2_PolicyPCR / TPM2_Unseal", definition: "TPM 2.0 commands that bind a sealed blob's release to a specific PCR profile. BitLocker uses this pair to release the VMK only when current PCRs match the seal-time digest." },
  { term: "Authenticode", definition: "Microsoft PE-image digest format used for code signing. PCR[4] hashes the Authenticode digest of `bootmgfw.efi`, not the raw bytes of the file." },
  { term: "Cuckoo Attack", definition: "An attestation-relay attack (Parno 2008) in which a compromised device proxies a verifier's challenge to a different genuine TPM and returns that TPM's valid signed quote. Closeable only by pre-binding the AK to the device serial." },
]} />

Fuzzy Extractors and the One Inequality That Explains Why Windows Hello Doesn't Use One

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

A fuzzy extractor turns a noisy, low-entropy biometric reading into a stable, uniformly random cryptographic key, with a public helper string that leaks negligibly little about the key. The Dodis-Reyzin-Smith 2004 construction is the canonical primitive: a secure sketch composed with a strong randomness extractor, governed by a single security inequality that bounds the extractable key length by the source min-entropy, minus the code redundancy, minus twice the security parameter. For consumer face and fingerprint at realistic noise levels, that inequality forbids a cryptographically useful key. Windows Hello -- and Apple Face ID -- consequently use a *match-then-unwrap-TPM-sealed-key* architecture instead, in which the biometric is a gate, not an input to key derivation.

1. Why can't a fingerprint just be a password?

A developer building a login system writes key = SHA256(fingerprint_image), ships it, and never logs in again. Two scans of the same finger produce two slightly different images, the hash is avalanche-sensitive by design, and the cryptographic key is unrecoverable on every authentication after the first. The fix is not a bigger hash. The fix is a new cryptographic primitive.

The mistake is universal because the temptation is universal. A fingerprint feels like a password: it identifies you, it is hard to forge, and you carry it everywhere. So why not just hash it into a 256-bit key the way every developer has hashed a password for thirty years? The answer is mechanical. SHA-256 is an avalanche function: flipping a single input bit flips, on average, half the output bits. A fingerprint sensor returns a slightly different image every time you press your finger to the glass; one stray dust mote, one degree of rotation, one pixel of pressure variation, and the input has changed in thousands of bits. The hash is statistically independent of the previous one. The key is gone.

{// Two near-identical 128-bit "fingerprint readings" differing in just 5 bits const enc = new TextEncoder(); async function sha256Hex(bytes) { const h = await crypto.subtle.digest('SHA-256', bytes); return [...new Uint8Array(h)].map(b => b.toString(16).padStart(2,'0')).join(''); } const w1 = new Uint8Array(16); for (let i = 0; i < 16; i++) w1[i] = (i * 37) & 0xff; const w2 = w1.slice(); w2[3] ^= 0x01; w2[7] ^= 0x10; w2[11] ^= 0x02; w2[12] ^= 0x40; w2[15] ^= 0x80; const h1 = await sha256Hex(w1), h2 = await sha256Hex(w2); let diff = 0; for (let i = 0; i < 64; i++) if (h1[i] !== h2[i]) diff++; console.log('reading 1 hash:', h1); console.log('reading 2 hash:', h2); console.log('hex digits that differ:', diff, '/ 64'); console.log('the second hash shares nothing with the first');}

Any biometric authentication scheme has to confront two simultaneous problems. The first is that biometric readings are noisy: two scans of the same finger differ in many bits, two photos of the same face under different lighting differ in millions. The second is that biometric distributions are low-entropy: fingerprints, faces, and even irises are far from uniformly random bitstrings; they cluster heavily, and a clever guesser can do much better than brute force.

The Dodis-Reyzin-Smith framing of these two facts, in the introduction of their 2004 paper, is precise: "strings that are neither uniformly random nor reliably reproducible seem to be more plentiful" than the well-behaved strings classical cryptography assumes [@dors-2008-siamjc]. Hao, Anderson, and Daugman put the engineering version of the problem in one sentence: "the main obstacle to algorithmic combination is that biometric data are noisy; only an approximate match can be expected to a stored template. Cryptography, on the other hand, requires that keys be exactly right, or protocols will fail" [@hao-anderson-daugman-2005-tr].

A pair of algorithms $(\text{Gen}, \text{Rep})$ such that $\text{Gen}(w) \to (R, P)$ produces a uniformly random key $R \in \{0,1\}^\ell$ and a public helper string $P$, while $\text{Rep}(w', P) \to R$ recovers the same key $R$ for any $w'$ within distance $t$ of $w$. The helper $P$ may be public; it must leak only negligibly about $R$ under any source $W$ of sufficient min-entropy [@dors-2008-siamjc].

A fuzzy extractor is the primitive built to solve exactly this design problem. Given a noisy source $w$ with at least $m$ bits of min-entropy, $\text{Gen}$ produces a stable key $R$ and a public helper $P$; given any reading $w'$ within Hamming distance $t$ of the original, $\text{Rep}$ recovers $R$ identically. The helper $P$ is allowed to be public; the security guarantee says $P$ leaks at most $\varepsilon$ bits about $R$ in statistical distance. This primitive is the right answer to the developer's mistake at the top of the section, and it has been the subject of twenty years of beautiful cryptographic theory.

So here is the puzzle the rest of the article will solve. Every major consumer biometric authentication product -- Windows Hello (2015), Apple Touch ID (2013), Apple Face ID (2017) -- has explicitly avoided this primitive. None of them derives a cryptographic key from your biometric. Why? The answer takes nine more sections, and it bottoms out on one inequality.

2. Historical origins: the 1990s problem statement

By the late 1990s the smartcard-and-PKI deployment wave had forced an uncomfortable question on the cryptographic community: how do you bind a long-lived private key to a person rather than a device? Smartcards were cheap to mass-produce, but they were also cheap to steal, and PINs got shared the moment any user found them inconvenient. Tying the key to a fingerprint or an iris reading promised a way out, but the underlying mathematics had not yet been written down.

Two foundational tools were already in the cryptographic toolkit and would later become load-bearing pieces of the fuzzy extractor. The first was the 1979 Carter-Wegman construction of universal hash functions: a family ${h_s}$ such that for any two distinct inputs $x \ne y$, $\Pr_s[h_s(x) = h_s(y)] \le 1/|\text{range}|$ [@carter-wegman-1979]. The second was the 1989 Impagliazzo-Levin-Luby Leftover Hash Lemma (LHL), which proved that applying a randomly chosen universal hash to any min-entropy source yields an output statistically indistinguishable from uniform, up to a precise entropy budget [@ill-1989]. Together, these two results were a randomness-extraction toolkit waiting for an application.Carter-Wegman 1979 is the deepest ancestor of every information-theoretic fuzzy extractor. The strong extractor at the heart of the Dodis-Reyzin-Smith construction is, mechanically, a Carter-Wegman universal hash with a random seed -- the LHL is what proves its output is uniform.

The min-entropy of a random variable $W$ is $H_\infty(W) = -\log_2 \max_w \Pr[W = w]$. It is the entropy measure that captures *worst-case* guessing difficulty: a source with $m$ bits of min-entropy cannot be guessed correctly with probability greater than $2^{-m}$ in one try. Min-entropy is the right measure for cryptographic key derivation because Shannon entropy is too generous when the distribution is peaked [@dors-2008-siamjc].

In May 1998, at the IEEE Symposium on Security and Privacy, Davida, Frankel, and Matt published the first formal-cryptographic proposal for binding a private signing key to a biometric. Their scheme used majority-decoding with a BCH error-correcting code to absorb the noise in repeated iris readings, then used the corrected reading to release a stored long-lived signing key [@davida-frankel-matt-1998], [@dblp-davida-frankel-matt-1998]. The construction worked, in the sense that it ran end-to-end on test data. But the paper had no notion of a strong extractor, no parameter inequality bounding the extractable key length, and no security theorem against a generic adversary. The reader was asked to trust the construction by inspection.

That same period saw the rise of a completely different approach. In 2001, Ratha, Connell, and Bolle of IBM proposed cancelable biometrics: instead of trying to derive a cryptographic key from the biometric, apply a non-invertible application-specific transformation $T_i$ to the feature vector before storage, so that a compromised template can be revoked and re-issued under a fresh $T_j$ [@ratha-connell-bolle-2001]. The goal was template protection, not key derivation.

The three properties Ratha et al. demanded of $T_i$ -- irreversibility (the transform cannot be inverted to recover the original feature vector), unlinkability (two transforms of the same biometric cannot be matched), and renewability (a compromised transform can be replaced) -- would two decades later be codified verbatim by ISO/IEC 24745:2022 as the universal properties of any biometric template protection scheme [@iso-iec-24745-2022], [@rathgeb-uhl-2011]. Cancelable biometrics partitions the design space alongside fuzzy extractors: the former transforms a biometric template, the latter derives a cryptographic key from it.

Davida, Frankel, and Matt had shipped a working construction without a unifying primitive. Juels and Wattenberg, within twelve months, would publish a cleaner construction with the same gap; and within seven years Dodis, Reyzin, and Smith would close it. The next section is the story of those precursors, and the structural defect they share.

3. Early approaches: fuzzy commitment and fuzzy vault

Two precursor constructions, six years apart, get most of the way to a fuzzy extractor without naming the primitive. They are simultaneously the foundation everything later builds on and the ad-hoc constructions the 2004 Dodis-Reyzin-Smith paper would retroactively classify as components of a real abstraction rather than a complete one.

3.1 Juels-Wattenberg 1999: fuzzy commitment

Ari Juels and Martin Wattenberg, at the 1999 ACM Conference on Computer and Communications Security, introduced the fuzzy commitment scheme [@juels-wattenberg-1999-pdf]. The construction is short enough to write on a napkin. Fix a binary error-correcting code $\mathcal{C} \subseteq {0,1}^n$ that corrects up to $t$ errors. To commit to a noisy biometric reading $w \in {0,1}^n$:

Pick a random codeword $c \stackrel{R}{\leftarrow} \mathcal{C}$.
Publish the commitment blob $(h(c), \delta)$ where $\delta := w \oplus c$ and $h$ is a cryptographic hash.

To decommit with a fresh reading $w'$ within Hamming distance $t$ of $w$, compute $c' := D(w' \oplus \delta)$ where $D$ is the code's decoder; check $h(c') \stackrel{?}{=} h(c)$. If the check passes, the commitment opens. The argument that the scheme is binding (the committer cannot later open to a different value) and hiding (the commitment leaks nothing about $w$) goes through in the random-oracle model.

sequenceDiagram participant U as User (commit) participant S as Storage participant V as Verifier (decommit) U->>U: Pick random codeword c U->>U: Compute delta = w XOR c U->>U: Compute t = hash(c) U->>S: Publish (t, delta) Note over V: Time passes, user re-scans V->>S: Fetch (t, delta) V->>V: Read fresh w' near w V->>V: Compute c' = Decode(w' XOR delta) V->>V: Check hash(c') == t V-->>V: Open commitment to c

Fuzzy commitment is elegant, but it has three structural gaps that DRS 2004 will later expose.

First, the construction is a commitment, not an extractor: it binds a hash of a codeword, not a uniformly random key, and it cannot be plugged directly into a key-derivation pipeline. Second, it assumes Hamming-distance noise, which fits iris codes (Daugman's IrisCodes are fixed-length bitstrings whose pairwise distance is fractional binomial) but does not fit fingerprint minutiae sets or face embeddings. Third, and most damagingly, the construction leaks under correlated re-enrolment. In 2009, Simoens, Tuyls, and Preneel demonstrated "how to link and reverse protected templates produced by code-offset and bit-permutation sketches" [@simoens-tuyls-preneel-2009]; if a user enrols twice with two slightly different readings $w_1, w_2$ of the same finger, the helper pair $(\delta_1, \delta_2)$ leaks $w_1 \oplus w_2$, which is closer to zero than uniform and reveals the noise distribution.

3.2 Juels-Sudan 2002 / 2006: fuzzy vault

Three years later, Ari Juels and Madhu Sudan extended the same idea to unordered sets, the natural metric for fingerprint minutiae [@juels-sudan-2002-pdf], [@juels-sudan-2006-dcc]. The fuzzy vault locks a secret $\kappa$ in a vault as follows:

Encode $\kappa$ as the coefficients of a polynomial $p$ of degree $k$ over a finite field.
For each element $a_i$ of the genuine biometric set $A$, publish the point $(a_i, p(a_i))$.
Add many chaff points $(x_j, y_j)$ with $y_j \ne p(x_j)$ to drown the genuine points in noise.

A user whose set $B$ overlaps sufficiently with $A$ identifies enough true points to Reed-Solomon-decode $p$, recovers $\kappa$, and unlocks the vault. The construction handles set-difference noise naturally and was widely deployed in fingerprint authentication research between 2002 and 2010.Watch the citation. The conference version is IEEE ISIT 2002 (single-page proceedings extended abstract; full author PDF is the canonical text). The journal version is Designs, Codes and Cryptography 38(2):237-257, February 2006 -- not IEEE Transactions on Information Theory as one widely-circulated secondary source claims.

But the fuzzy vault inherits and amplifies the precursor's defects. Walter Scheirer and Terrance Boult, in 2007, enumerated three concrete attacks: Attack via Record Multiplicity (ARM), Surreptitious Key Inversion (SKI), and Blended Substitution [@scheirer-boult-2007]. The Attack via Record Multiplicity exploits exactly the same correlated-re-enrolment weakness fuzzy commitment has: two vaults locking the same biometric under different polynomials reveal the underlying set $A$ by intersecting the published points. The Scheirer-Boult paper opens with a sentence that is, in retrospect, the diagnosis of the entire pre-DRS literature: "while many PETs for biometrics have attempted a formal analysis of their security, a significant oversight has been the issue of the risk from attacks that use multiple records" [@scheirer-boult-2007].

3.3 The structural defect both constructions share

Stand back. Both constructions handle noise tolerance via an error-correcting code, and both produce a security argument by hashing or hiding the result. Neither construction separates these two responsibilities. The noise-tolerance layer (the code) and the uniformity layer (the hash) are entangled in the same blob of public data. That entanglement is structurally why neither can prove a generic security theorem against a generic adversary: every security argument is tied to specific assumptions about the source distribution, the code, and the random oracle, and slight changes to any of them break the analysis. The fix is not a better code or a better hash. The fix has a name: decomposition.

A pair of algorithms $(\text{SS}, \text{Rec})$ such that $\text{SS}(w) \to s$ produces a public sketch $s$, and $\text{Rec}(w', s) \to w$ recovers the original $w$ for any $w'$ within distance $t$ of $w$. The sketch is allowed to leak some information about $w$, but the residual *average min-entropy* $\tilde H_\infty(W \mid \text{SS}(W))$ must remain at least some target $\tilde m$ [@dors-2008-siamjc].

That word -- decomposition -- is what Dodis, Reyzin, and Smith would deliver, on Thursday May 6, 2004, in Interlaken, Switzerland, at EUROCRYPT.

4. Evolution: five generations at a glance

Before walking through the DRS 2004 decomposition in detail, it helps to see where it sits in the family tree. Every construction the rest of this article mentions belongs to one of five generations, ordered by what failure of the previous generation it closes.

flowchart LR G0["Gen 0
hash(w)
fails on noise"] --> G1["Gen 1
Juels-Wattenberg 1999
fuzzy commitment"] G1 --> G15["Gen 1.5
Juels-Sudan 2002/2006
fuzzy vault"] G15 --> G2["Gen 2
Dodis-Reyzin-Smith 2004
fuzzy extractor"] G2 --> G3a["Gen 3a
Boyen 2004
reusable"] G2 --> G3b["Gen 3b
BDKOS 2005 / DKKRS 2012
tamper-resilient"] G2 --> G4["Gen 4
Fuller-Meng-Reyzin 2013
computational, LWE-based"] G2 --> G5["Gen 5
CFPRS 2016
reusable low-entropy"]

The table below names each generation, its central insight, and the new failure mode it exposes that motivates the next generation. Read it top to bottom; each row solves a problem the row above raised.

Gen	Year	Authors / venue	Central insight	New failure exposed
0	--	folk	$\text{key} = h(w)$	Avalanche destroys key on every re-scan
1	1999	Juels-Wattenberg, CCS [@juels-wattenberg-1999-pdf]	Code-offset: hide $w$ inside $\delta = w \oplus c$ for random codeword $c$	Hamming-only; no extractor; leaks under re-enrol
1.5	2002 / 2006	Juels-Sudan, ISIT / DCC [@juels-sudan-2002-pdf], [@juels-sudan-2006-dcc]	Polynomial-on-set with chaff points; handles set-difference	Vulnerable to record-multiplicity and key-inversion attacks [@scheirer-boult-2007]
2	2004 / 2008	Dodis-Reyzin-Smith, EUROCRYPT / SIAM JC [@drs-2004-eurocrypt], [@dors-2008-siamjc]	Decomposition: secure sketch + strong extractor; one inequality	Forbids construction at consumer biometric entropy
3a	2004	Boyen, CCS [@boyen-2004-ccs-eprint]	Reusable fuzzy extractors; chosen-perturbation security	Outsider model needs XOR-homomorphic sketch; insider model needs RO
3b	2005 / 2012	Boyen-Dodis-Katz-Ostrovsky-Smith, EUROCRYPT [@bdkos-2005-eurocrypt]; DKKRS, IEEE TIT [@dkkrs-2012-ieeetit]	Tamper-resilient fuzzy extractors; helper-data integrity against active adversary	Active-adversary lower bound: $\Omega(\log(1/\varepsilon))$ extra entropy
4	2013 / 2020	Fuller-Meng-Reyzin, ASIACRYPT / I&C [@fmr-2013-asiacrypt-eprint], [@fmr-2020-iandc]	Skip the sketch; LWE-based computational construction extracts key length equal to source min-entropy	Negative result: every computational HILL secure sketch still implies an ECC with $2^{m-2}$ codewords
5	2016	Canetti-Fuller-Paneth-Reyzin-Smith, EUROCRYPT [@cfprs-2016-eurocrypt]	Per-bit digital lockers; sample-then-extract; reusable for low-entropy sources	Depends on digital-locker idealisation; restricted source class

Read this way, the family tree tells a story. Each successor generation closes a real defect: Boyen 2004 closes the multi-enrolment leak that Simoens-Tuyls-Preneel would later make concrete; BDKOS 2005 closes the helper-data tampering problem; FMR 2013 attacks the min-entropy floor itself by trading information-theoretic security for an LWE assumption; CFPRS 2016 chases the low-entropy regime where every prior generation gave up. None of them dethrones the foundational decomposition. They all live inside the framework DRS established.Watch two attribution traps. Boyen 2004 is a sole-author paper -- "Reusable Cryptographic Fuzzy Extractors" by Xavier Boyen [@boyen-2004-ccs-eprint], not "Boyen and Reyzin" or "Boyen et al." And Fuller-Meng-Reyzin 2013 appeared at ASIACRYPT 2013, not EUROCRYPT 2013; the misattribution is widespread in secondary sources [@fmr-2013-asiacrypt-eprint].

Generation 2 is the load-bearing entry. Every later claim about what a fuzzy extractor can and cannot do traces back to it. The next section walks through the construction in mechanical detail, because the inequality at its centre is the artefact every later section will reference.

5. The breakthrough: Dodis-Reyzin-Smith 2004 in detail

May 6, 2004. Interlaken, Switzerland. Session 16 ("New Applications"). Yevgeniy Dodis (NYU), Leonid Reyzin (Boston University), and Adam Smith (then MIT) present a paper that will be widely cited as the foundational work of the area [@drs-2004-eurocrypt]. The journal version, published in 2008 in SIAM Journal on Computing with Rafail Ostrovsky added as a fourth author, is the canonical reference text for every formal definition the field uses [@dors-2008-siamjc].The conference paper is three-author Dodis-Reyzin-Smith; the 2008 SIAM Journal on Computing version is four-author and adds Ostrovsky. Cite whichever fits your context, but get the author count right.

The paper's contribution is not a new algorithm. It is a decomposition and a security inequality. The two halves of the decomposition are the secure sketch and the strong randomness extractor, and the inequality bounds the extractable key length in terms of source min-entropy, code redundancy, and security parameter.

5.1 The secure sketch: information reconciliation

A secure sketch is the noise-tolerance layer. Formally, an $(\mathcal{M}, m, \tilde m, t)$-secure sketch is a pair of functions $(\text{SS}, \text{Rec})$ over a metric space $(\mathcal{M}, \text{dis})$ such that, for any $w, w'$ with $\text{dis}(w, w') \le t$, $\text{Rec}(w', \text{SS}(w)) = w$, and for any source $W$ with min-entropy $H_\infty(W) \ge m$, the average min-entropy $\tilde H_\infty(W \mid \text{SS}(W)) \ge \tilde m$ [@dors-2008-siamjc].

Average min-entropy, also called conditional min-entropy, generalises min-entropy to the case where partial information $Y$ about $W$ is public. Formally, $\tilde H_\infty(W \mid Y) = -\log_2 \mathbb{E}_{y \leftarrow Y}\!\left[\max_w \Pr[W = w \mid Y = y]\right]$. It is the right entropy measure for sketches because the sketch $\text{SS}(W)$ is public and an adversary's best guess of $W$ averages over the possible sketch values [@dors-2008-siamjc].

Two canonical sketch constructions matter. The code-offset sketch picks a random codeword $c$ from an $[n, k, 2t+1]$ binary error-correcting code and publishes $s = w \oplus c$. To recover, compute $c' = D(w' \oplus s)$ where $D$ is the code's decoder; then return $w = s \oplus c'$. The entropy loss is at most $n - k$ bits. The syndrome sketch publishes $s = H \cdot w^T$ where $H$ is the parity-check matrix of the same code; recovery solves a coset-leader problem. The entropy loss is identical; the syndrome variant just publishes a shorter helper. PinSketch, the canonical sketch for set-difference metrics, lives in section 6 of the journal paper [@dors-2008-siamjc].

{// Simulate a tiny [16, 11, 3] code: 11 data bits, 5 parity bits via a fixed generator. // Real code-offset uses BCH/Reed-Solomon; this is a toy that shows the structure. function parity(w, mask) { let p = 0; for (let i = 0; i < 16; i++) if ((mask>>i)&1) p ^= (w>>i)&1; return p; } const masks = [0b1111111111100000, 0b1111110000011110, 0b1111000011111101, 0b1100111111111011, 0b0011111111110111]; function encode(data11) { let cw = data11 & 0x7FF; for (let i = 0; i < 5; i++) cw |= parity(data11, masks[i]) << (11 + i); return cw; } // Sketch: pick a random codeword c, publish s = w XOR c const w = 0b0110110010110101; // imagine this is the user's first reading const data = Math.floor(Math.random() * 2048); const c = encode(data); const s = w ^ c; console.log('First reading w =', w.toString(2).padStart(16,'0')); console.log('Random codeword c =', c.toString(2).padStart(16,'0')); console.log('Public sketch s = w XOR c =', s.toString(2).padStart(16,'0')); // Re-scan: the user reads w' with one bit flipped const wp = w ^ (1 << 7); console.log('Re-scan reading w\\' =', wp.toString(2).padStart(16,'0')); const cp = wp ^ s; console.log('Decoder input c + e =', cp.toString(2).padStart(16,'0')); console.log('The decoder sees the noisy codeword and corrects it back to c -- so Rec recovers w from w\\' and s.');}

5.2 The strong randomness extractor: from sketch-residual to uniform key

A strong randomness extractor is the uniformity layer. The relevant formal statement is the average-case form of the Leftover Hash Lemma.

A function $\text{Ext}: \{0,1\}^n \times \{0,1\}^d \to \{0,1\}^\ell$ is an *average-case* $(n, \tilde m, \ell, \varepsilon)$-strong extractor if, for every joint distribution $(W, I)$ over $\{0,1\}^n \times \{0,1\}^*$ with $\tilde H_\infty(W \mid I) \ge \tilde m$, the statistical distance $\text{SD}((\text{Ext}(W; S), S, I), (U_\ell, S, I)) \le \varepsilon$ where $S$ is the (public) extractor seed and $U_\ell$ is uniform [@dors-2008-siamjc]. Let $H$ be a universal hash family with output length $\ell$. For any source $W$ with $\tilde H_\infty(W \mid I) \ge \tilde m$, the distribution $(S, H_S(W), I)$ is $\varepsilon$-close in statistical distance to $(S, U_\ell, I)$ whenever $\ell \le \tilde m - 2 \log(1/\varepsilon) + 2$ [@ill-1989], [@dors-2008-siamjc]. The Leftover Hash Lemma is therefore the single inequality that powers every information-theoretic strong extractor used in practice.

The LHL says: take any min-entropy source, hash it with a randomly chosen universal hash, and what comes out is statistically indistinguishable from uniform, up to a precise budget. Pay $2 \log(1/\varepsilon) - 2$ bits of entropy at the door; everything left over is uniform.

5.3 Composition

The composition is the whole point. Define $\text{Gen}(w) := (R, P)$ where $P = (\text{SS}(w), \text{seed})$ and $R = \text{Ext}(w; \text{seed})$. To recover, $\text{Rep}(w', P)$ runs $w = \text{Rec}(w', \text{SS}(w))$ and recomputes $R = \text{Ext}(w; \text{seed})$. The composition is an $(\mathcal{M}, m, \ell, t, \varepsilon)$-fuzzy extractor, and the security proof is now algebraic.

The helper data $P$ in a fuzzy extractor is the public part of the output of $\text{Gen}$. It consists of the secure sketch $\text{SS}(w)$ plus the extractor seed. It must be available at recovery time, but it need not be secret. The security guarantee says that even an adversary who sees $P$ in full learns at most $\varepsilon$ bits about the extracted key $R$ in statistical distance [@dors-2008-siamjc]. flowchart TD W["Noisy reading w"] --> SS["Secure sketch SS"] W --> EXT["Strong extractor Ext"] SEED["Random seed"] --> EXT SS --> P["Public helper P = (sketch, seed)"] SEED --> P EXT --> R["Uniform key R"] P --> REP["Rep at recovery"] WP["Noisy reading w'
(within distance t)"] --> REP REP --> R2["Same uniform key R"]

5.4 The load-bearing inequality

Compose the two entropy budgets. The sketch starts with $H_\infty(W) \ge m$ bits of min-entropy and leaks at most $n - k$ to its public sketch; what remains is $\tilde H_\infty(W \mid \text{SS}(W)) \ge m - (n - k)$. Feed that residual into the LHL with security parameter $\varepsilon$, and the extractor delivers a uniform key of lengthThe constant $+2$ at the end of the inequality is an artefact of how DORS 2008 states the average-case Leftover Hash Lemma in Lemma 2.4; the conference paper writes it as $-O(1)$.

$$\ell \;\le\; H_\infty(W) - (n - k) - 2\log(1/\varepsilon) + 2.$$

This inequality is the artefact every later section will reference. Walk it term by term. The first term is the source min-entropy: the actual information content of the biometric. The second term is the code redundancy: the entropy paid to absorb noise. The third term is the security parameter cost: every halving of the adversary's distinguishing advantage costs two bits. The final $+2$ is a small constant.

{function extractableKeyLen(m, codeRedundancy, epsilon) { const securityCost = 2 * Math.log2(1 / epsilon); return m - codeRedundancy - securityCost + 2; } // Iris source (Daugman 2003: ~249 dof = effective bits), 128-bit security, BCH [255,131,37] console.log('iris @ eps=2^-80:', extractableKeyLen(249, 124, 2 ** -80).toFixed(1), 'bits'); // Fingerprint at the upper end of Pankanti-Prabhakar-Jain 2002 (~70 effective bits) console.log('fingerprint @ eps=2^-80:', extractableKeyLen(70, 124, 2 ** -80).toFixed(1), 'bits'); // Face embedding under correlated illumination noise (~30-50 effective bits) console.log('face @ eps=2^-80:', extractableKeyLen(40, 124, 2 ** -80).toFixed(1), 'bits'); // Loosen security to eps=2^-40 and see if fingerprint recovers console.log('fingerprint @ eps=2^-40:', extractableKeyLen(70, 124, 2 ** -40).toFixed(1), 'bits');}

Run that calculator on realistic numbers. At a security parameter of $\varepsilon = 2^{-80}$, the third term alone eats 160 bits. A standard $[255, 131, 37]$ BCH code (which corrects up to 18 errors in 255 bits) burns another 124 bits. To extract a 128-bit AES key, the source must supply at least 410 bits of min-entropy.

Set $m = 70$ (fingerprint upper bound per Pankanti et al. 2002), $n - k = 124$ (BCH redundancy), and $\varepsilon = 2^{-80}$. The extractable key length becomes $70 - 124 - 160 + 2 = -212$ bits. A negative bound means the construction is not slow or expensive: it is *infeasible* at any parameter setting. Try loosening security to $\varepsilon = 2^{-40}$: still $70 - 124 - 80 + 2 = -132$. Even pushing the security parameter all the way down to $\varepsilon = 2^{-10}$ (laughably weak by OS-authenticator standards) leaves you at \$70 - 124 - 20 + 2 = -72$ bits. The fingerprint source simply does not have the entropy budget for the construction at any meaningful security level.

The iris, at Daugman's 249 statistical degrees of freedom [@daugman-2003-pdf], [@daugman-2004-csvt], is just barely enough -- and only because Hao, Anderson, and Daugman engineered a careful two-layer Hadamard-then-Reed-Solomon code that exploits the block structure of iris noise to achieve a high error-correction rate per information bit, sufficient to extract 140 bits from the 2048-bit iris code at 99.5% recovery success [@hao-anderson-daugman-2005-tr]. The fingerprint, at 40 to ~70 effective bits per Pankanti, Prabhakar, and Jain [@pankanti-prabhakar-jain-2002], is not even close. The face embedding, at 30 to 50 raw bits and considerably less under correlated illumination and pose noise, is further still.

Key idea: The DRS 2004 key-length inequality is the article's load-bearing artefact. Every later claim that a fuzzy extractor cannot work on consumer biometrics traces back to it. The construction is not slow or expensive on these sources -- it is mathematically forbidden, in the sense that the extractable key length is negative at the security parameter an operating-system authenticator demands.

This is the inequality that forbids the construction on consumer-grade face or fingerprint at the security bar an operating system authenticator demands. The rest of the article is the four-generation effort to escape the forbidding, and the architectural choice every shipped consumer product made instead.

6. State of the art: by metric space and by successor generation

The DRS 2004 framework is parameterised by metric space and source class. To navigate the field, think of every fuzzy-extractor instantiation as a pair of choices: pick a sketch suited to the source's metric, then pick an extractor suited to the source's entropy profile. The state of the art is best read as a two-axis table.

6.1 Sketches by metric space

Metric space	Sketch construction	Code or technique	Where it fits
Hamming distance	Code-offset / syndrome [@dors-2008-siamjc]	$[n,k,2t+1]$ BCH	Iris codes; SRAM PUFs
Set difference	PinSketch (DORS 2008 section 6) [@dors-2008-siamjc], [@reyzin-lab-home]	Symmetric-difference syndrome decoding; sublinear in universe size	Fingerprint minutiae sets; many-out-of-many tokens
Edit distance	Embed into Hamming via low-distortion encoding	Ostrovsky-Rabani-style embeddings	DNA sequences, typed passwords
Continuous (face / fingerprint embeddings)	Quantise then Hamming	Lloyd-Max or learned quantisers	Face deep-features; the worst empirical entropy profile

The continuous-source case is where the consumer biometric story gets ugly: quantising a learned embedding loses entropy in proportion to the quantiser's resolution, and the residual is the entropy budget the sketch has to work with.

6.2 Generation 3a: Boyen 2004 reusable fuzzy extractors

Xavier Boyen, about five months after the DRS conference paper, attacked the multi-enrolment problem head on [@boyen-2004-ccs-eprint]. A reusable fuzzy extractor remains secure when the same source is enrolled multiple times under correlated but different readings $w_1, w_2, \ldots, w_q$. Boyen formalises two threat models. The outsider chosen-perturbation attack allows the adversary to choose the noise patterns between enrolments; Boyen shows that fuzzy extractors built from XOR-homomorphic sketches (code-offset is one) are secure against outsider adversaries with bounded perturbations. The insider chosen-perturbation attack additionally gives the adversary access to the extracted keys $R_1, \ldots, R_q$; this stronger model requires a random-oracle assumption. The Canetti-Fuller-Paneth-Reyzin-Smith 2016 paper would later argue that the outsider model's perturbation class is "unlikely to hold for a practical source," quoting the paper directly [@cfprs-2016-eprint].

6.3 Generation 3b: BDKOS 2005 / DKKRS 2012 tamper-resilient fuzzy extractors

A different defect of the DRS construction: the public helper $P$ is not authenticated. If an active adversary can rewrite $P$ on its way to the verifier, the verifier reconstructs the wrong key, and the security analysis falls apart. Xavier Boyen, Yevgeniy Dodis, Jonathan Katz, Rafail Ostrovsky, and Adam Smith addressed this in 2005 with the tamper-resilient fuzzy extractor [@bdkos-2005-eurocrypt]. Their Theorem 1 builds a tamper-detecting secure sketch in the random-oracle model: publish $(\text{pub}^, h)$ where $\text{pub}^$ is a standard sketch and $h = H(w, \text{pub}^*)$; at recovery, recompute the tag and reject on mismatch. The full tamper-resilient fuzzy extractor (BDKOS §3.2) then composes this tamper-detecting sketch with a strong extractor. The standard-model construction came later, in 2012, from Dodis, Kanukurthi, Katz, Reyzin, and Smith, by replacing the random oracle with an algebraic manipulation detection (AMD) code, with entropy loss $O(\log(1/\varepsilon))$ above the passive bound [@dkkrs-2012-ieeetit], [@cdfpw-2008-eurocrypt].

6.4 Generation 4: Fuller-Meng-Reyzin 2013 computational fuzzy extractors

By 2013 the field had hit a wall. The DRS inequality forbids information-theoretic constructions on low-entropy consumer biometrics. Fuller, Meng, and Reyzin asked the obvious next question: does the wall come down if you trade information-theoretic security for computational security? Their answer, in Computational Fuzzy Extractors at ASIACRYPT 2013, is half negative and half positive [@fmr-2013-asiacrypt-eprint], [@fmr-2020-iandc].

The negative half: "for every secure sketch that retains $m$ bits of computational entropy, there is an error-correcting code with $2^{m-2}$ codewords" [@fmr-2013-asiacrypt-eprint]. The coding-theory lower bound survives the relaxation to computational HILL pseudoentropy. The positive half: skip the sketch entirely. Treat the biometric reading as an LWE error vector, use a random linear code, and base security on the Learning With Errors problem. The construction extracts a key length equal to the source min-entropy, with security under standard LWE assumptions.

6.5 Generation 5: Canetti-Fuller-Paneth-Reyzin-Smith 2016 reusable low-entropy

The final piece of the contemporary state of the art is CFPRS 2016 [@cfprs-2016-eurocrypt], [@cfprs-2016-eprint]. Ran Canetti, Benjamin Fuller, Omer Paneth, Leonid Reyzin, and Adam Smith built a fuzzy extractor that is reusable, handles low-entropy distributions, and works under realistic correlated noise. The key technique is per-bit digital lockers: for each bit of the source, store a digital locker keyed on a random subset of input bits. Recovery samples subsets, queries the lockers, and majority-votes. The construction depends on a digital-locker idealisation, but CFPRS show that any reusable fuzzy extractor for low-entropy sources requires either the random-oracle model or an equivalent strong assumption, which limits the room to remove the idealisation.

6.6 The one consumer-biometric construction that ever cleared the bar

Across two decades of theoretical work, exactly one published consumer-biometric fuzzy extractor has cleared the DRS bar at production-grade parameters. Hao, Anderson, and Daugman, in a 2005 Cambridge tech report and a 2006 IEEE Transactions on Computers paper, presented an iris fuzzy extractor that "can generate up to 140 bits of biometric key, more than enough for 128-bit AES" with "a 99.5% success rate" on 70 eyes [@hao-anderson-daugman-2005-tr], [@hao-anderson-daugman-2006-ieeetc]. The construction layers a Hadamard code (handles single-bit errors) with a Reed-Solomon code (handles burst errors) inside the code-offset sketch, then runs LHL.The Hao-Anderson-Daugman code is a two-layer Hadamard-then-Reed-Solomon composition. The inner Hadamard layer is HC(6) at rate $7/64 \approx 1/9$ (7 bits encoded into 64 bits per block, 32 blocks per 2048-bit iris code), and absorbs noise within each block; the outer RS(32, 20) over $\text{GF}(2^7)$ tolerates up to six block errors across the 32 blocks. The composition costs more redundancy than a single BCH code but matches the iris noise statistics better. The iris is the only common biometric where the entropy budget is generous enough to absorb that much redundancy and still leave 140 bits over.

The state of the art, taken together, is wide and mature. Every successor either requires the source to have an entropy profile most consumer biometrics lack, or uses idealisations (random oracle, digital locker, LWE-with-specific-error-distribution) that no production cryptosystem wants to depend on. The next two sections make that boundary precise.

7. Competing approaches: six paradigms

Step back from the fuzzy-extractor lineage and put it in competitive context. There are at least six distinct approaches to binding cryptographic operations to a biometric, and only two of them derive a key from the biometric. The other four use the biometric as a gate on a key generated elsewhere. ISO/IEC 24745:2022 codifies three protection properties -- irreversibility, unlinkability, and renewability -- that any biometric template protection scheme should provide [@iso-iec-24745-2022], and the Rathgeb-Uhl 2011 survey is the open-access reference that maps each approach to the three properties [@rathgeb-uhl-2011].

Approach	Representative work	Derives key?	Irreversibility	Unlinkability	Renewability
Information-theoretic fuzzy extractor	Dodis-Reyzin-Smith 2004 family [@dors-2008-siamjc]	Yes	Yes (under min-entropy)	Hard under correlated re-enrol	Yes (rotate seed and sketch)
Computational fuzzy extractor	Fuller-Meng-Reyzin 2013 / CFPRS 2016 [@fmr-2013-asiacrypt-eprint], [@cfprs-2016-eurocrypt]	Yes	Yes (under LWE / digital locker)	Improved over information-theoretic	Yes
Cancelable biometrics	Ratha-Connell-Bolle 2001 [@ratha-connell-bolle-2001]	No	Yes (by transform design)	Yes (transform key)	Yes (re-enrol under fresh transform)
Homomorphic encryption biometric matching	Engelsma-Jain-Boddeti HERS [@engelsma-jain-boddeti-hers-arxiv]	Partial	Yes (under HE)	Yes	Yes
Secure-element match-on-chip	Apple Secure Enclave [@apple-platform-security], [@apple-secure-enclave]	No	Hardware-anchored	Yes (per-device)	Yes (hardware key rotation)
Match-then-unwrap-TPM-sealed-key	Windows Hello ESS [@ms-learn-ess], [@ms-learn-hello-business]	No	Hardware-anchored	Yes (per-device)	Yes (rotate TPM-sealed key)

A class of biometric template protection schemes in which a non-invertible, application-specific transformation $T_i$ is applied to the feature vector before storage. The stored template is then $T_i(\text{features})$; matching is performed in the transformed space; and a compromised template can be revoked by re-enrolling under a fresh transform $T_j$. The goal is *template protection*, not cryptographic key derivation: no uniformly random key falls out of the construction. ISO/IEC 24745 names three properties such a transform must satisfy: irreversibility, unlinkability, and renewability [@ratha-connell-bolle-2001], [@rathgeb-uhl-2011]. The international standard *Information security, cybersecurity and privacy protection -- Biometric information protection* (ISO/IEC 24745:2022 Edition 2, 63 pages, published February 2022 [@iso-iec-24745-2022]) defines three properties of any biometric protection scheme -- irreversibility, unlinkability, renewability -- without prescribing any specific cryptographic primitive. The standard is paywalled at CHF 204, which is why most academic and engineering treatments cite the open-access Rathgeb-Uhl 2011 survey [@rathgeb-uhl-2011] as a proxy for the property definitions. The three properties are deliberately neutral: a fuzzy extractor, a cancelable transform, a homomorphic-encryption matcher, and a hardware-anchored secure element can all in principle satisfy them, and the standard is silent on which is best.

The two derive approaches (rows 1 and 2 in the table) follow the genealogy this article has been tracing. The remaining four are gate approaches: each generates the cryptographic key by some independent means -- a TPM-sealed asymmetric key, a Secure Enclave-bound key, a homomorphic-encryption keypair -- and uses the biometric only to decide whether to release the key. The cancelable-biometrics approach is even more conservative: it does not even tie a key to the biometric at all; it only protects the template against compromise.

Why is the derive versus gate distinction so deep? Because it determines who is responsible for the key's secrecy. In a derive model, the biometric is the secret; if the biometric leaks (a photo of your face, a latent print on a glass), the cryptographic key is at risk. In a gate model, the secret is independent of the biometric -- usually a hardware-anchored private key that never leaves the secure element -- and the biometric is just a soft second factor that decides whether the user is allowed to use the secret.

Hardware-anchored gate schemes also get to rely on attestation: a TPM or Secure Enclave can prove to a remote relying party that the key it just used is bound to a specific device, by a specific user, in a specific authentication ceremony. A pure software fuzzy extractor cannot make any of those claims.

This is the decisive architectural distinction in the field. Every shipped consumer biometric authenticator on the planet picks gate. The next two sections explain why: section 8 walks through three theoretical lower bounds that draw the perimeter inside which any fuzzy extractor can live, and section 10 walks through the Windows Hello architecture as the concrete embodiment of gate.

8. Theoretical limits

Three lower-bound results, taken together, draw the perimeter inside which any fuzzy extractor can live. The section 5 inequality was the first. Two more come from later papers, and they are sharper than the basic inequality suggests.

8.1 The min-entropy floor

The DRS section 5 inequality already gives a floor: $\ell \le H_\infty(W) - (n-k) - 2\log(1/\varepsilon) + 2$. Fuller, Reyzin, and Smith in 2020 sharpened this with an impossibility result for universal information-theoretic fuzzy extractors.

They define a stronger notion they call fuzzy min-entropy, $H^{\text{fuzz}}{t,\infty}(W) := -\log \max{w_0} \Pr[W \in \mathcal{B}t(w_0)]$, and prove that the gap between the universal-construction bound $H\infty(W) - \log|\mathcal{B}t|$ and the optimal bound $H^{\text{fuzz}}{t,\infty}(W)$ can be a large fraction of $n$ bits. For Daugman's iris parameters ($n = 2048$, $H_\infty \approx 249$, $\log|\mathcal{B}_t| \approx 1024$), the universal bound sits more than 1000 bits below the fuzzy-min-entropy upper bound -- a gap of $\approx 0.5n$ -- and Theorem 5.1's impossibility region pushes the worst-case gap up toward $h_2(\tau) \cdot n$ for higher noise rates [@frs-2020-ieeetit]. The implication: a single universal construction cannot extract the optimal key length from every high-fuzzy-min-entropy source; some sources require source-specific constructions to close the gap, and the DRS bound is essentially tight in the worst case.

Plug realistic numbers into the floor. The table below is the empirical perimeter the cryptographic community has lived inside for two decades.

Source	Approx. raw entropy	Effective entropy under correlated noise	Clears DRS bar at $\varepsilon = 2^{-80}$ for 128-bit key?
Iris [@daugman-2003-pdf], [@daugman-2004-csvt]	~249 dof	~249 dof (matched-illumination scans)	Yes (demonstrated [@hao-anderson-daugman-2006-ieeetc])
Fingerprint minutiae [@pankanti-prabhakar-jain-2002]	~70 bits at best image quality	40-70 bits depending on sensor	No
Face deep-feature embeddings	30-50 bits raw	Often much less under illumination / pose	No
SRAM PUF [@intrinsic-id-sram-puf], [@tuyls-skoric-kevenaar-2007-springer]	thousands of bits (entire SRAM page)	thousands of bits (controlled noise)	Yes (deployed in over a billion devices)

Watch Daugman's 249 figure carefully. It is the number of degrees of freedom in the Hamming distance distribution between IrisCodes from different irises, fit to a fractional binomial with $N = 249$ and $p = 0.5$. It is not the raw min-entropy of an iris image: an iris sensor returning 249 bits of high-quality iris data is not the same as 249 bits of min-entropy. Daugman's 2003 Pattern Recognition paper makes the distinction explicitly [@daugman-2003-pdf].

Note: Across every consumer biometric the industry has deployed, the iris is unique in clearing the DRS bar at production parameters. Daugman's 249 statistical degrees of freedom give the iris a budget more than three times the budget of fingerprint, and an order of magnitude more than face. Hao, Anderson, and Daugman 2006 demonstrate a 140-bit iris key with 99.5% success on 70 eyes [@hao-anderson-daugman-2006-ieeetc] -- the only published consumer-biometric fuzzy extractor ever to clear the DRS bar at production parameters. The catch: iris sensors are intrusive, expensive, and rarely shipped in consumer phones or laptops.

8.2 Reusability impossibility

Boyen's 2004 insider chosen-perturbation game is unconditionally insecure for adversaries who can choose enough perturbations [@boyen-2004-ccs-eprint]. CFPRS 2016 cite this impossibility result and work around it by restricting attention to a digital-locker-amenable source class [@cfprs-2016-eprint]. The practical implication is that any fuzzy extractor that wants to be reusable across many enrolments has to either (a) restrict the source class (CFPRS's path) or (b) accept a security degradation per re-enrol. Neither option is appealing for a consumer device that may see its user re-enrol after every kernel update, every sensor recalibration, or every routine credential rotation.

8.3 Active-adversary lower bound

A passive adversary sees the helper $P$ but does not modify it; an active adversary can rewrite $P$ between enrolment and recovery. BDKOS 2005 and DKKRS 2012 prove that protecting against active adversaries requires either a one-time setup secret (a shared seed established out of band), an authenticated channel between enrolment and recovery, or a min-entropy surplus of $\Omega(\log(1/\varepsilon))$ above the passive bound [@bdkos-2005-eurocrypt], [@dkkrs-2012-ieeetit]. For $\varepsilon = 2^{-80}$, the active-adversary surcharge is 80 bits.

8.4 Combining the three bounds

Stack the three bounds on top of each other for a consumer face / fingerprint source. The min-entropy floor is the hardest barrier: with 40 to 80 effective bits and 160 bits of security-parameter cost plus 100-plus bits of code redundancy, the extractable key length is negative. The reusability impossibility forecloses the workaround of pretending that re-enrolments are uncorrelated -- they are not, because real biometric drift is highly correlated. The active-adversary bound forecloses the workaround of pretending the helper data is safe in transit. A software-only fuzzy extractor cannot meet a consumer-OS security bar at consumer biometric quality. What you do instead is the next section.

9. Open problems

Four problems remain, ordered by how directly each one blocks deployment in a Windows Hello-class product.

Note: 1. Deployable face / fingerprint fuzzy extractors under realistic correlated noise. Engelsma, Cao, and Jain's 2019 DeepPrint reduces intra-user fingerprint variance via learned representations [@engelsma-cao-jain-2019-arxiv], but no published construction has cleared the DRS bar on a realistic test set under correlated noise. 2. Reusable computational fuzzy extractors without idealisations. CFPRS 2016 uses digital lockers, which require either a random oracle or an equivalent strong assumption [@cfprs-2016-eurocrypt]. Eliminating that idealisation is open. 3. Post-quantum information-theoretic fuzzy extractors. Fuller-Meng-Reyzin's LWE-based construction is already post-quantum on the computational side [@fmr-2013-asiacrypt-eprint], [@fmr-2020-iandc], but an information-theoretic construction tailored to PQ-style noise distributions is open. 4. The PUF-to-biometric architectural gap. Fuzzy extractors are deployed only for PUFs (Synopsys PUF IP (including QuiddiKey), over a billion devices [@intrinsic-id-sram-puf]) where the noise model is controlled. Closing the architectural gap to consumer biometrics, where the noise model is adversarial and environmental, is open.

Each of these is hard, and none has a credible path to a consumer-OS-grade deployment in the next product cycle. Take them one at a time.

The first is the most obviously blocking. Even if every fingerprint sensor in the world tomorrow began returning DeepPrint embeddings instead of minutiae sets, the entropy budget would still be tens of bits below the DRS bar. The bottleneck is the source distribution, not the encoder. Improving the encoder helps -- a learned representation with lower intra-user variance shifts the noise distribution toward zero, which lets you use a code with less redundancy -- but the inequality still bites. The community's working belief is that no consumer fingerprint sensor will ever ship enough min-entropy to clear the bar at the security parameter an OS authenticator demands.

The second is more nuanced. Digital lockers are useful in practice -- they are the central tool that lets CFPRS 2016 handle reusability for low-entropy sources -- but they depend on the random-oracle model. The random-oracle model is fine for theoretical work; it is uncomfortable for a production cryptosystem that has to survive an FIPS evaluation and a NIST audit. The hope is that non-malleable extractors or correlation-resistant universal hash families can replace digital lockers in the CFPRS construction without losing the reusability guarantee. Promising directions exist; none has matured into a deployable construction.

The third sounds esoteric but matters. The information-theoretic DRS construction has been quietly post-quantum since 2004: the LHL holds against quantum adversaries up to a constant factor, and BCH decoding is classical [@dors-2008-siamjc]. But once you move to the computational fuzzy extractors of FMR 2013 or CFPRS 2016, the security argument depends on a hardness assumption (LWE or digital-locker-as-RO) that one wants to be confident survives the post-quantum transition. LWE is widely believed to be PQ-secure; digital lockers are not yet rigorously analysed against quantum adversaries.

The fourth, the PUF-to-biometric gap, is where the theoretical and engineering communities meet most uncomfortably. The fuzzy extractor works in practice: Synopsys PUF IP (including QuiddiKey) embeds a code-offset / syndrome-based fuzzy extractor in over a billion devices, "deployed and proven in over a billion devices certified by EMVCo, Visa, CC EAL6+, PSA, ioXt, and governments across the globe" per the vendor [@intrinsic-id-sram-puf]. The SRAM PUF has thousands of bits of min-entropy and a controlled noise model: powering up the SRAM gives a startup pattern that is reliable across temperature and voltage swings to within a few percent of bits. The signal-to-noise ratio is dramatically better than any consumer biometric.Pierre-Alain Dupont, Julia Hesse, David Pointcheval, Leonid Reyzin, and Sophia Yakoubov's 2018 EUROCRYPT paper Fuzzy Password-Authenticated Key Exchange [@dupont-hesse-pointcheval-reyzin-yakoubov-2018] is a recent direction that decouples fuzzy extraction from key agreement: rather than extract a key once and use it, two parties run a password-authenticated key exchange whose "password" is a noisy biometric. Fuzzy PAKE sidesteps the helper-data leakage problem because the helper is consumed inside an interactive protocol that does not commit it to long-term storage.

The bright line between PUF and biometric is the *noise model*. An SRAM PUF lives in a single device, sees temperature and voltage variation between $-40^\circ$C and $+85^\circ$C, and operates against an adversary who can read the SRAM but cannot rewrite the silicon. The noise distribution is empirically measurable, and the entropy budget is enormous -- thousands of bits per page. A consumer fingerprint sensor, by contrast, lives outside the trust boundary: the noise distribution depends on skin moisture, sensor cleanliness, finger angle, and an adversary who can lift a latent print from a glass. The fuzzy-extractor framework is the right answer for the PUF case and the wrong answer for the consumer biometric case, and the difference is the noise model, not the cryptography.

Each of these problems is interesting on its own merits, but none of them has a credible path to a consumer-OS-grade deployment in the next product cycle. So what does a consumer OS actually do? That is the punchline.

10. The punchline: why Windows Hello does not use a fuzzy extractor

State the claim flatly. Windows Hello, in every shipping configuration since Enhanced Sign-in Security was introduced with Windows 11, performs match-then-unwrap, not derive-from-biometric. The biometric is a gate, not an input to key derivation. The cryptographic credential a Windows Hello user authenticates with is a TPM-bound asymmetric keypair generated independently during provisioning; the biometric matcher merely decides whether to authorise the TPM to use that key. The full architecture is documented verbatim in Microsoft Learn's Enhanced Sign-in Security and Windows Hello for Business pages [@ms-learn-ess], [@ms-learn-hello-business].

10.1 Enrolment

When a Windows user enrols a face or a fingerprint, the biometric data path runs inside a Virtualisation-Based Security (VBS) trustlet, not in the kernel and not in the camera driver. Microsoft's documentation is explicit:

"When ESS is enabled, the face algorithm is protected using VBS ... The hypervisor allows the face camera to write to these memory regions providing an isolated pathway to deliver face data from the camera to the face matching algorithm" [@ms-learn-ess].

The face image never lands in regular kernel memory. It is delivered by the hypervisor into a memory region readable only by the VBS-resident face-matching trustlet, which extracts a feature template, encrypts it with VBS-only keys, and writes the encrypted blob to disk. For fingerprint, ESS supports only sensors with on-device matching: "ESS is only supported on fingerprint sensors with match on sensor capabilities" [@ms-learn-ess]. The sensor itself runs the matcher and never exposes the template to the host operating system.

A user-mode process that runs inside Virtual Trust Level 1 (VTL 1) on Windows, isolated from the normal-world kernel (VTL 0) by the Hyper-V hypervisor. Trustlets are the unit of code that the Secure Kernel hosts and that VBS-protected operations execute inside. Examples include the LSA Isolated process (Credential Guard) and the biometric matcher (Windows Hello with Enhanced Sign-in Security) [@ms-learn-ess].

In parallel, the credential the user will actually authenticate with is generated. Microsoft Learn's Windows Hello for Business page describes this verbatim: "The provisioning flow requires a second factor of authentication before it can generate a public/private key pair. The public key is registered with the IdP, mapped to the user account" [@ms-learn-hello-business]. The private key never leaves the TPM. It is sealed against a TPM policy that requires the boot integrity to be intact, the user account to be the same, and the VBS-resident biometric matcher to have signalled a match success. The keypair is a per-user, per-device, per-IdP credential; nothing about it is a function of the user's biometric.

10.2 Authentication

At authentication time, the user presents a face or a finger; the VBS-resident matcher compares the live template to the stored template; on success, the matcher signals the TPM via a secure channel to unwrap the asymmetric private key for use in an IdP challenge response. The Microsoft documentation states the architecture in two sentences:

The Windows biometric components running in VBS establish a secure channel to the TPM ... When a matching operation is a success, the biometric components in VBS use the secure channel to authorize the usage of Windows Hello keys for authenticating the user with their identity provider, applications, and services. -- Microsoft Learn, Windows Hello Enhanced Sign-in Security [@ms-learn-ess]

The authentication ceremony itself is described in the Windows Hello for Business page: "Regardless of the gesture used, authentication occurs using the private portion of the Windows Hello for Business credential. The IdP validates the user identity by mapping the user account to the public key registered during the provisioning phase" [@ms-learn-hello-business]. The IdP sees a cryptographic proof that the user-registered TPM-bound key signed the challenge; it never sees anything that depends on the biometric.

flowchart LR subgraph "DRS fuzzy extractor (theoretical)" D1["Read biometric w"] --> D2["Gen(w) -> (R, P)"] D2 --> D3["Store helper P on disk"] D2 --> D4["Use R as key"] D5["Re-read w' near w"] --> D6["Rep(w', P) -> R"] D6 --> D7["Use R as key"] end subgraph "Windows Hello (production)" W1["Read biometric w in VBS"] --> W2["Compute template T"] W2 --> W3["Encrypt and store T with VBS-only key"] W4["Generate TPM-bound keypair (sk, pk)"] --> W5["Register pk with IdP"] W4 --> W6["Seal sk to TPM with policy"] W7["Re-read w' in VBS"] --> W8["Match w' against T"] W8 --> W9["Authorise TPM unwrap via secure channel"] W6 --> W9 W9 --> W10["TPM signs IdP challenge with sk"] end

10.3 Why this is the right design

Map each architectural choice to a fuzzy-extractor limit from section 8.

The min-entropy gap is real. Face and fingerprint min-entropy under correlated real-world noise is below the DRS bar for any cryptographically meaningful key length at the security parameter an OS authenticator must hit. Section 5's inequality forbids the construction; no amount of clever engineering moves the constants. Microsoft's engineers, when faced with the choice between deriving a 128-bit key from a 40-bit source and binding the key to a TPM, made the only choice the math allows.

Helper-data leakage compounds under re-enrolment. Every time a user re-enrols (new device, sensor recalibration, post-incident credential refresh), a new helper string would be published. Simoens, Tuyls, and Preneel established that correlated code-offset helpers link and reverse [@simoens-tuyls-preneel-2009]. Hardware-anchored match-then-unwrap rotates the TPM-sealed asymmetric key under standard key-management rules instead, sidestepping the cryptographic reusability problem entirely. Key rotation under a hardware root of trust is a solved problem; reusability in a software fuzzy extractor remains an active research area.

Reusability across user-account-rebuild scenarios. PIN reset, device wipe-and-restore, and credential rotation become key-management problems (rotate the TPM-sealed key) rather than cryptographic-reusability problems (rotate the fuzzy extractor and trust the CFPRS bound). The former has thirty years of operational practice behind it; the latter has none.

Hardware-anchored attestation is easier to reason about. TPM seal-policy binding gives a hardware-anchored security argument that a relying party can verify: the trustlet measurement, the biometric-match-success signal, and the boot integrity all have to match before the key unwraps. A software-only fuzzy extractor cannot match this attestation chain. The IdP at the other end of an authentication ceremony can ask the TPM for a quote attesting that the key was used inside a specific code module on a specific device; no software construction makes that proof.

Key idea: In every shipped consumer biometric authenticator on the planet, the biometric is a gate, not an input. The cryptographic key is generated separately during provisioning -- as a TPM-bound asymmetric keypair on Windows Hello, as a Secure-Enclave-bound key on Apple Face ID, as a StrongBox-bound key on Android [@android-keystore] -- and unwrapped on match success. The key is never derived from the biometric.

10.4 The sibling case: Apple Face ID and Touch ID

Apple's Secure Enclave Processor performs the same architectural pattern, with the Secure Enclave playing the role Windows assigns to the trustlet-plus-TPM pair. The Apple Platform Security guide is explicit:

"Apple's biometric security architecture relies on a strict separation of responsibilities between the biometric sensor and the Secure Enclave, and a secure connection between the two. The sensor captures the biometric image and securely transmits it to the Secure Enclave. During enrollment, the Secure Enclave processes, encrypts, and stores the corresponding Optic ID, Face ID, and Touch ID template data. During matching, the Secure Enclave compares incoming data from the biometric sensor against the stored templates to determine whether to unlock the device or respond that a match is valid" [@apple-platform-security], [@apple-secure-enclave].

Two vendors, independently, converged on the same architecture. Both vendors hire the strongest cryptographers in the world. Neither built a fuzzy extractor. The architectural pattern is now the consensus answer to the consumer biometric authentication problem.

Apple's Secure Enclave Processor is the architectural sibling of the Windows VBS trustlet plus TPM combination. The Secure Enclave is an ARM-based coprocessor with its own kernel, its own memory, and its own boot chain, physically isolated on the Application Processor die. During Face ID or Touch ID enrolment, the biometric sensor transmits its raw image directly to the Secure Enclave over a hardware-isolated link; the Secure Enclave extracts the template, encrypts it under a per-device key sealed to the Secure Enclave's UID, and stores it. During matching, the Secure Enclave compares the live template against the stored template inside its own memory, and on success authorises the use of cryptographic keys held in the same coprocessor. The pattern is identical to the Windows Hello pattern: derive nothing from the biometric; gate a hardware-bound key on the match decision [@apple-platform-security].

Twenty years of theoretical work; zero production consumer-OS biometric authenticators on the planet use any of it for face or fingerprint key derivation; and the engineers who said no were right, for reasons traceable to a single load-bearing inequality at the heart of the 2004 EUROCRYPT paper.

11. Frequently asked questions

No. Both perform match-then-unwrap rather than derive. Windows Hello generates a TPM-bound asymmetric keypair during provisioning [@ms-learn-hello-business]; the biometric matcher, running inside a VBS trustlet, authorises the TPM to use that key on a match-success signal [@ms-learn-ess]. Apple Face ID and Touch ID follow the same pattern with a Secure-Enclave-bound key in place of a TPM-bound one [@apple-platform-security]. In neither case is the cryptographic key a function of your biometric reading. Yes -- in SRAM PUFs. Synopsys PUF IP (including QuiddiKey), built on Intrinsic ID SRAM PUF technology, is "deployed and proven in over a billion devices certified by EMVCo, Visa, CC EAL6+, PSA, ioXt, and governments across the globe" [@intrinsic-id-sram-puf]. The PUF noise distribution is controlled and the entropy budget is enormous, so the DRS construction works exactly as advertised. Consumer face and fingerprint biometrics are a different regime: the noise model is adversarial, the entropy budget is small, and the construction's inequality forbids the key length an OS authenticator needs. Because the hash is avalanche-sensitive by design: a single-bit input change flips, on average, half the output bits. Two scans of the same finger differ in many bits, so two hashes differ in roughly half their bits. The cryptographic key is statistically independent of the previous one, and the user can never log in again after their first authentication. This is the failure mode that motivates the fuzzy-extractor primitive in section 1 [@hao-anderson-daugman-2005-tr]. Because of the load-bearing inequality at the heart of the EUROCRYPT 2004 paper. For consumer face and fingerprint biometrics at the security parameter an operating system authenticator demands ($\varepsilon = 2^{-80}$ or stronger), the extractable key length is negative: the source min-entropy is too low to absorb the cost of code redundancy plus the security parameter [@dors-2008-siamjc], [@frs-2020-ieeetit]. No amount of clever engineering moves the constants. Yes. The iris is the only common biometric that comfortably clears the DRS bar. Daugman's 2003 Pattern Recognition paper reports 249 statistical degrees of freedom across 9.1 million iris-to-iris comparisons [@daugman-2003-pdf]; Hao, Anderson, and Daugman in 2006 demonstrated a 140-bit iris key with 99.5% recovery success on 70 eyes [@hao-anderson-daugman-2006-ieeetc]. But iris sensors are expensive, intrusive, and rarely shipped in consumer phones or laptops, so the result has not generalised to mainstream consumer authentication. Deep-learning encoders such as Engelsma-Cao-Jain's DeepPrint reduce intra-user variance by mapping noisy raw biometric readings into compact embeddings [@engelsma-cao-jain-2019-arxiv]. That reduces the noise the secure sketch has to absorb and lets the code use less redundancy. But the deep encoder does not add min-entropy to the source: the underlying fingerprint is still a 40-to-80-bit source. No published construction has been shown to clear the DRS bar on a realistic correlated-noise test set for any consumer biometric other than iris. Unlikely without one of two changes. Either (a) the sensor stack would have to gain entropy -- for instance, adding an iris camera to a future Surface device would put the source above the DRS bar -- or (b) a CFPRS-style reusable computational fuzzy extractor would have to mature past the digital-locker idealisation [@cfprs-2016-eurocrypt]. Even then, the operational advantages of hardware-bound asymmetric keys (TPM-anchored attestation, IdP-friendly key rotation, no helper-data leakage on re-enrolment) are large enough that a fuzzy extractor would have to clear a high bar to displace the current architecture.

The fuzzy extractor is the right primitive for the right source. SRAM PUFs are that source; consumer face and fingerprint biometrics are not. The 2004 inequality drew the line, two decades of theory have refined the line, and every shipped consumer biometric authenticator on the planet has chosen to live on the other side of it.

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 introduced Project Cerberus at DCD>Zettastructure in London on November 8, 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 Pluton silicon to reach market, announced at CES 2022 with OEM systems shipping later that year [@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 clearest Microsoft-documented OS-delivered firmware-update path, 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 provisioned during silicon manufacture (the tape-out and fabrication steps) and exercised when signed Pluton firmware is loaded and verified from OEM firmware integration onward, but the licensing, assembly, and board-integration steps around it 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	FIPS 140-3 L2 (Pluton ROM, CMVP #4880); no public EAL4+ [@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 public Common Criteria EAL4+ certification for the whole security processor as of 2026, though its ROM module carries a FIPS 140-3 Level 2 validation (CMVP cert 4880) [@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 -- extends a hash of each component into the TPM's Platform Configuration Registers and records a separate, replayable event log, 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 used the platform's BIOS flashing routine to write the modified ROM back to the chip. 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 itself and KEK; KEK signs updates to db and dbx (a PK holder can replace KEK and thereby control db and dbx indirectly). 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 runs first and is immutable, and that performs the first measurement 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 still at its power-on value of all ones (0xFF...FF), 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 published a 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 SbatLevel UEFI variable records "minimum acceptable shim generation is 4", shim refuses every older shim, which still hashes correctly but is 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; shim compares it against a minimum generation recorded in the `SbatLevel` UEFI variable and refuses older builds, without consuming dbx capacity (firmware itself still enforces only db and dbx). 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 bootloaders and sepOS up to the user-facing apps (the Boot ROM itself is silicon-resident mask ROM and is never field-updated).

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; each mitigation step is enabled by writing the corresponding value to HKLM\SYSTEM\CurrentControlSet\Control\Secureboot\AvailableUpdates (the values are listed 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) or a USB startup key where the edition and management model support it [@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 TPM_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, F-Secure's (later WithSecure) 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 a startup-key factor or Network Unlock where appropriate (BitLocker's native OS-volume preboot authentication is TPM, TPM+PIN, and startup key, not FIDO2 or smart card), 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 every TPM-bound protector, so the next boot falls back to the BitLocker recovery key. 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.

No Secrets to Steal: How Windows Hello Eliminated the Shared Secret

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

**Windows Hello replaces passwords with biometric authentication backed by hardware cryptography.** Your face or fingerprint unlocks a private key sealed inside a TPM chip -- no biometric data ever leaves your device, and no shared secret crosses the network. After a decade of enterprise growing pains and a cat-and-mouse security arms race, Microsoft made passwordless the default for new accounts in May 2025, with passkeys now achieving a 98% sign-in success rate. The password's 64-year reign is ending -- but open problems in biometric spoofing, credential portability, and quantum-resistant cryptography mean the replacement is still under construction.

Why Passwords Must Die

In 2024, Microsoft observed 7,000 password attacks every second [@ms-passkeys] -- more than double the rate from 2023. Picture this: a user types their carefully memorized 16-character password into what looks like a corporate login page. The page is a phishing replica. In under a second, that password -- the one they have been rotating every 90 days for three years -- belongs to someone else.

Microsoft observed 7,000 password attacks per second in 2024. The password Corbato invented as a quick fix in 1961 had become the single greatest attack surface in computing.

The problem is not weak passwords. The problem is passwords themselves. They are shared secrets -- a piece of information that both you and the server know. Anything a server stores can be stolen. Anything you type can be intercepted. Anything you memorize can be phished. These are not implementation bugs. They are design properties.

It was not supposed to be this way. In 1961, Fernando Corbato [@wiki-password] introduced computer passwords at MIT as a quick fix for multi-user mainframes. Users needed separate file spaces on the Compatible Time-Sharing System (CTSS), and a secret string was the simplest way to provide per-user isolation. It was a temporary measure for a specific engineering constraint.

That temporary measure lasted 64 years.

What if authentication did not require a secret at all? What if your face unlocked a cryptographic key -- and that key never left your device? That is the promise of Windows Hello. But the story of how we got here passes through a gelatin finger, a low-cost USB device, and a near-infrared camera that shattered assumptions about what "secure" really means.

The Password's 64-Year Reign: A Brief History of Authentication Failure

In 1966, a software bug in MIT's CTSS printed the master password file to every user's terminal -- the first known password breach [@wiki-password].The 1966 CTSS incident was not a hack. A system administrator accidentally swapped the login message file with the master password file. Every user who logged in that day saw everyone else's password on screen.

It was a sign of things to come. For the next six decades, every generation of authentication would solve one problem -- and reveal a deeper one.

gantt title Authentication Evolution dateFormat YYYY axisFormat %Y section Passwords Plaintext passwords on CTSS :1961, 1979 section Hashed UNIX crypt / hashed passwords :1979, 1993 section Network Auth NTLM challenge-response :1993, 2000 Kerberos / Windows AD :2000, 2015 section Biometrics Software biometrics via WBF :2009, 2015 section Windows Hello Hello + TPM asymmetric auth :2015, 2021 ESS + VBS + Cloud Trust :2021, 2024 Passkeys and passwordless default :2024, 2026

Generation 0: Plaintext passwords (1961)

Corbato's CTSS stored passwords in plaintext [@wiki-password] in a file accessible to administrators. The model was simple: the user enters a string, the system compares it to a stored copy, and access is granted on match. The key assumption -- that only the legitimate user knows the password -- held exactly as long as the system remained uncompromised. Which was about five years.

Generation 1: Hashed passwords (1970s)

The obvious fix: do not store passwords in plaintext. In 1979, Robert Morris and Ken Thompson published the design behind UNIX's crypt() function [@wiki-crypt], a one-way hash based on a modified DES algorithm with a 12-bit salt. Even if an attacker stole the hash file, they could not directly read the passwords. They would have to try every possible password and compare hashes -- a brute-force attack.

For a while, that was computationally infeasible. Then Moore's Law caught up. By the late 1990s, EFF's DES Cracker and distributed.net had reduced 56-bit DES keysearch to 22 hours and 15 minutes [@eff-des], making DES-based crypt() increasingly untenable against well-funded attackers. Users also chose weak, predictable passwords, and attackers built rainbow tables that mapped common passwords to their hashes instantly.

Windows made this worse. LAN Manager (LM) hashes [@ms-lm-hash] uppercased every password, limited them to 14 characters, and split them into two 7-byte halves hashed independently.The LM hash design was spectacularly bad. By splitting a 14-character password into two 7-character halves, it reduced the brute-force search space from 95^14 to 2 x 95^7 -- a reduction of over 34 trillion times. An attacker could crack each half separately.

Rainbow tables could crack LM hashes in seconds. Microsoft eventually disabled LM hashing by default in Windows Vista, but the damage to enterprise networks had been done.

Generation 2: Network challenge-response (1990s)

The next insight: stop transmitting passwords over the network. NTLM [@ms-lm-hash] used a challenge-response protocol -- the server sends a random nonce, the client computes a response using the nonce and the password hash, and the server verifies the response. The password never crosses the wire.

Kerberos [@ms-kerberos], adopted in Windows 2000, improved further with mutual authentication, time-limited tickets, and single sign-on. It was elegant protocol engineering.

But the fundamental problem remained: shared secrets. NTLM was vulnerable to pass-the-hash attacks [@mitre-pth] -- an attacker who obtains the password hash can authenticate without ever knowing the password. Kerberos tickets could be stolen (Golden Ticket, Silver Ticket attacks). Both systems still depended on users choosing strong passwords, which they consistently failed to do.

Generation 3: First software biometrics (2000s)

By the early 2000s, fingerprint readers appeared on Windows laptops. The idea was appealing: replace "something you know" with "something you are." No password to remember, no password to steal.

Microsoft introduced the Windows Biometric Framework (WBF) [@ms-wbf] in Windows 7 (2009), standardizing the API and driver interface. Before WBF, each fingerprint reader vendor -- AuthenTec, Validity, UPEK -- shipped proprietary middleware that injected into the Windows logon process. The result was inconsistent security, driver conflicts, and no centralized management.

But WBF solved the wrong problem. It standardized the API while leaving the security model unchanged: biometric templates stored with weak encryption in user-accessible files, matching running in OS user space, and no hardware isolation whatsoever.

In 2002, Tsutomu Matsumoto at Yokohama National University demonstrated the "gummy finger" attack -- creating gelatin replicas of fingerprints that fooled approximately 80% of commercial readers [@gummy-finger]. The materials cost just a few dollars. Without liveness detection and hardware protection, biometrics were security theater.

The pattern was unmistakable. Each generation protected a different layer -- plaintext storage, hash computation, network transmission, biometric convenience -- but each left the next layer exposed. By 2013, passwords were fundamentally broken, and software-only biometrics were not the answer. Then Apple proved something nobody expected.

The Catalyst: How Touch ID Changed Everything

September 2013. Apple unveils the iPhone 5S [@apple-touchid] with a fingerprint sensor embedded in the home button. It was not the first phone with a fingerprint reader -- Motorola's ATRIX 4G shipped with a biometric fingerprint reader in 2011 [@motorola-atrix]. But it was the first one that hundreds of millions of people actually used.

What made Touch ID different was not the sensor. It was the Secure Enclave -- a dedicated secure subsystem integrated into Apple's system-on-chip and isolated from the main processor [@apple-secure-enclave]. The enclave runs its own microkernel, stores biometric material in protected memory, and keeps the matching pipeline outside the reach of normal iOS processes. Apple designed it so the biometric path stayed inside the enclave boundary rather than becoming just another app-visible API.

Note: Apple controlled the sensor, the SoC, the Secure Enclave hardware, and iOS. This vertical integration meant the entire biometric pipeline -- from sensor capture through template matching to key release -- could be designed as a single trust chain. No Windows OEM could match this in 2013 because the sensor, CPU, and OS came from three different vendors with no unified security model.

That architecture established a pattern that Windows Hello would later follow with the TPM. Both isolate secrets in hardware, but they do different jobs: the Secure Enclave is a richer coprocessor that protects both biometric processing and keys, while the TPM is a narrower trust anchor for key storage, signing, and attestation. Apple's newer Secure Enclave documentation also emphasizes encrypted enclave memory, whereas Windows later needed ESS and VBS to give its broader PC system a comparable isolation boundary [@apple-secure-enclave; @ms-ess].

Touch ID proved two things simultaneously: that consumer biometrics could be both secure and delightful, and that the key to secure biometrics was hardware isolation, not better algorithms.

The FIDO Alliance had already been working on the standards side. Founded in July 2012 [@fido-launch] by Michael Barrett (PayPal's CISO), Ramesh Kesanupalli (Nok Nok Labs), and partners including Lenovo, Validity Sensors, and Infineon, the Alliance set out to create open standards for strong authentication that would replace passwords. Its first protocols split the problem in two: UAF defined a passwordless flow where a device-local biometric or PIN unlocks a per-service key pair [@fido-uaf], while U2F defined a hardware-token second factor that signs a challenge after the user taps the device [@fido-u2f]. FIDO2 later unified these ideas into the WebAuthn + CTAP stack used for passkeys today [@fido-how].

The convergence was forming: consumer demand (Apple proved people wanted biometrics), open standards (FIDO defined how it should work), and enterprise need (Microsoft tracked thousands of password attacks per second). Apple showed what was possible. The FIDO Alliance defined how it should work. Microsoft was about to show how to do it at the scale of an entire operating system.

The Breakthrough: Windows Hello's Architecture

On March 17, 2015, Joe Belfiore announced Windows Hello. The key insight was not an algorithm -- it was an architecture. What if the biometric never leaves the device, and the authentication secret is a cryptographic key that even the server never sees?

A dedicated security chip soldered to a computer's motherboard (or implemented in firmware) that generates, stores, and manages cryptographic keys. The TPM can create key pairs where the private key is physically bound to the chip and cannot be exported -- even the operating system cannot extract it. Windows Hello uses TPM 2.0 to seal authentication keys. A cryptographic system using two mathematically related keys: a public key (shared openly) and a private key (kept secret). Data encrypted with one key can only be decrypted with the other. In Windows Hello, the TPM holds the private key and signs authentication challenges; the server holds only the public key, which is useless to an attacker.

Here is how Windows Hello authentication [@ms-whfb] works:

sequenceDiagram participant U as User participant B as Biometric Sensor participant D as Device OS participant T as TPM Chip participant S as Identity Server U->>B: Present face or fingerprint B->>D: Capture biometric sample D->>D: Match against stored template Note over D: Local verification only D->>T: Request private key release T->>T: Verify TPM-bound policy T-->>D: Private key available for signing S->>D: Send challenge nonce D->>D: Sign nonce with private key D->>S: Return signed assertion S->>S: Verify signature with public key S->>D: Authentication success

Step 1: Enrollment. The TPM generates an asymmetric key pair -- RSA-2048 or ECDSA P-256. The private key is sealed inside the TPM and cannot be exported. The public key is registered with the identity provider (Azure AD, Entra ID, or on-premises AD) [@ms-whfb].

Step 2: Biometric enrollment. The user registers their face (via a near-infrared camera) or fingerprint. The biometric template is stored locally on the device, protected by the OS.

Step 3: Authentication. The user presents their biometric gesture. The device verifies it locally against the stored template. If the match succeeds, the TPM releases the private key. The identity server sends a random challenge nonce; the device signs it with the private key and returns the signed assertion. The server verifies the signature using the stored public key. No shared secret ever crosses the network.

Key idea: Windows Hello's breakthrough was architectural, not algorithmic. By pairing biometrics with hardware-backed asymmetric cryptography, it eliminated shared secrets entirely. No biometric data ever leaves the device. No password hash sits on a server waiting to be stolen. Each authentication is a fresh, unreplayable cryptographic signature.

The probability that a biometric system incorrectly accepts an unauthorized person. Windows Hello requires a facial recognition FAR below 0.001% (1 in 100,000) [@ms-biometric-reqs]. Apple's Face ID is documented at less than 0.0001% (1 in 1,000,000) for a single enrolled face [@apple-faceid-security]. Lower is better -- but zero is theoretically impossible. A camera technology that captures light in the 700--1000 nanometer wavelength range, invisible to the human eye. Windows Hello uses NIR cameras because infrared illumination works regardless of ambient lighting and is harder to spoof with printed photos or screens -- standard displays do not emit near-infrared light. Or so everyone assumed until 2025.

Note: Without a TPM, Windows Hello falls back to software key storage, dramatically weakening the security model. The private key becomes a file protected by the OS rather than a secret sealed in tamper-resistant silicon. Always verify TPM 2.0 is present and active before relying on Hello's security properties.

A Trusted Platform Module is not a general-purpose processor. It is a purpose-built chip (or firmware module) designed for a narrow set of cryptographic operations: key generation, key storage, signing, and attestation.

When Windows Hello enrolls a user, the TPM generates a key pair using its internal random number generator. The private key never exists outside the chip's boundary -- it is generated inside the TPM and stays there. The TPM enforces access policies: it will only release the key for signing after the device OS confirms that the biometric match succeeded. Even a compromised operating system kernel cannot extract the private key from a hardware TPM.

This is fundamentally different from software key storage, where the key is a file on disk that any sufficiently privileged process can read.

The PIN paradox

Windows Hello also revived the humble PIN -- and made it more secure than a complex password. A Hello PIN [@ms-whfb] is device-bound: it unlocks the TPM-stored private key on that specific device. A stolen PIN is useless without physical access to the hardware. Compare this to a password, which works from any device on earth. A 4-digit PIN on Windows Hello is architecturally more secure than a 20-character password reused across services.Microsoft Passport was briefly announced as a separate product in early 2015 -- the cryptographic key infrastructure behind Windows Hello. By late 2015, the branding was merged. "Microsoft Passport" was retired and its functionality absorbed into "Windows Hello" and "Windows Hello for Business." The separate brand caused market confusion and was quickly abandoned.

The biometric FAR can be expressed mathematically. For a face recognition system with $n$ enrolled users and a per-comparison FAR of $p$, the probability of at least one false acceptance across all comparisons is:

$$P(\text{false accept}) = 1 - (1 - p)^n$$

For Windows Hello's required FAR of $10^{-5}$ [@ms-biometric-reqs] and a single user, this gives a 0.001% chance per authentication attempt. With 1,000 attempts, the cumulative probability rises to roughly 1% -- which is why lockout policies and anti-hammering protections exist.

{` // This demonstrates the core idea behind Windows Hello's authentication. // In the real system, the private key lives in the TPM and never leaves.

async function simulateHelloAuth() { // Step 1: Enrollment -- generate key pair (TPM does this in hardware) const keyPair = await crypto.subtle.generateKey( { name: "ECDSA", namedCurve: "P-256" }, true, // extractable for demo only; TPM keys are NOT extractable ["sign", "verify"] ); console.log("Key pair generated (simulating TPM enrollment)");

// Step 2: Server sends a challenge nonce const challenge = crypto.getRandomValues(new Uint8Array(32)); console.log("Server challenge:", Array.from(challenge.slice(0, 8)).map(b => b.toString(16).padStart(2, '0')).join(''));

// Step 3: Device signs the challenge with the private key const signature = await crypto.subtle.sign( { name: "ECDSA", hash: "SHA-256" }, keyPair.privateKey, challenge ); console.log("Signed assertion:", new Uint8Array(signature).slice(0, 16).join(',') + '...');

// Step 4: Server verifies with the public key const valid = await crypto.subtle.verify( { name: "ECDSA", hash: "SHA-256" }, keyPair.publicKey, signature, challenge ); console.log("Server verification:", valid ? "SUCCESS" : "FAILED"); console.log("\nNote: The private key never left the device."); console.log("The server only has the public key -- useless to an attacker."); }

simulateHelloAuth(); `}

Windows Hello solved the fundamental password problem: no shared secrets ever traverse the network. But the story does not end here -- because researchers would soon discover that protecting the key was not enough if you could not trust the camera.

The Enterprise Gambit: Windows Hello for Business

Windows Hello delighted consumers. But enterprise IT administrators asked a harder question: how do I deploy this to 50,000 machines managed by Active Directory?

The W3C Web Authentication API -- a browser standard that lets websites request public-key-based authentication from platform authenticators (like Windows Hello) or roaming authenticators (like security keys). WebAuthn became a W3C Recommendation on March 4, 2019, forming the browser-side component of the FIDO2 standard alongside CTAP (Client-to-Authenticator Protocol).

Windows Hello for Business (WHfB) [@ms-whfb] launched in 2016 with two trust types, each carrying its own infrastructure burden:

Certificate Trust required a full Public Key Infrastructure -- a Certificate Authority hierarchy, CRL distribution points, certificate templates, and ADFS (Active Directory Federation Services). For organizations that already had PKI, this was a natural fit. For everyone else, it meant weeks of setup.

Key Trust required Windows Server 2016+ domain controllers with AD schema extensions. Simpler than Certificate Trust, but still demanded on-premises infrastructure that many cloud-first organizations were trying to eliminate.Yogesh Mehta, Principal Group Program Manager at Microsoft, evangelized Windows Hello for Business at Ignite 2016. He would later be credited as a key figure in the FIDO2 certification effort. The original Belfiore blog post URL announcing Windows Hello is now lost to link rot.

Two milestones accelerated adoption. In March 2019, WebAuthn became a W3C Recommendation [@w3c-webauthn] -- a universal browser API for public-key authentication. Android had already been FIDO2-certified in February 2019 [@fido-android-certification]; two months after WebAuthn's recommendation, Windows Hello became one of the first FIDO2-certified platform authenticators built into a desktop operating system [@fido-certification]. Together, these meant that Windows Hello could authenticate not just to Windows, but to any FIDO2-supporting website through any modern browser.

Note: Unless you have specific PKI requirements, Cloud Trust -- announced by Microsoft in 2022 [@ms-cloud-trust-ga] -- eliminates much of the complexity of certificate and key trust deployments. It requires Entra ID configuration and Microsoft Entra Kerberos rather than a full on-prem PKI or ADFS stack, which is why Microsoft now treats it as the default recommendation for many hybrid organizations.

flowchart TD A[Choose a WHfB Trust Model] --> B{Cloud-native org using Entra ID?} B -->|Yes| C[Cloud Trust -- Recommended] B -->|No| D{On-prem AD still required?} D -->|Yes| E{Existing PKI infrastructure?} D -->|No| C E -->|Yes| F[Certificate Trust] E -->|No| G[Key Trust] C --> H[Simplest deployment: Entra ID only] F --> I[Most complex: CA + CRL + ADFS] G --> J[Moderate: Server 2016+ DCs required]

Cloud Trust delegates all validation to Entra ID. No on-premises PKI, no ADFS, no certificate templates. Best for organizations that are cloud-native or hybrid with Azure AD.

Key Trust requires Windows Server 2016+ domain controllers with AD schema extensions. Choose this if you need on-premises AD support but do not have PKI.

Certificate Trust requires the full PKI stack -- CA hierarchy, CRL distribution, ADFS. Choose this only if your organization already has PKI infrastructure and needs certificate-based authentication for regulatory compliance.

Enterprise deployment was painful -- multiple trust models confused administrators, and adoption was slower than hoped. But it was about to get much worse. In July 2021, a researcher with a low-cost USB board would demonstrate that Windows Hello's most basic assumption was wrong.

The Security Arms Race: When Researchers Fought Back

Omer Tsarfati had a simple question: what happens if you plug in a USB device that claims to be an IR camera? The answer would force Microsoft to rethink Windows Hello's entire trust model.

The USB camera bypass (CVE-2021-34466)

In July 2021, Tsarfati at CyberArk Labs [@cyberark-bypass] revealed that Windows Hello's facial recognition accepted input from any USB device presenting itself as an IR camera -- with no attestation, no hardware trust verification, and no device identity check.Tsarfati's attack required only a single IR frame -- not video, not a 3D reconstruction, just one static infrared image of the target's face. The simplicity of the attack was what made it so alarming.

Using an NXP evaluation board [@cyberark-bypass], Tsarfati constructed a custom USB device that replayed a single IR frame of a target's face. Plug it in, and Windows Hello authenticated the attacker as the target. At the time, 85% of Windows 10 users employed Windows Hello [@cyberark-bypass] -- making this a massive attack surface.

The insight was devastating: the TPM protected the key, but nobody protected the camera. Windows Hello's threat model assumed trusted camera hardware. The USB specification makes no such guarantee.

A Windows feature that uses the hardware hypervisor to create an isolated virtual environment (Virtual Trust Level 1, or VTL1) separated from the main OS kernel (VTL0). Even if an attacker gains SYSTEM-level access to the Windows kernel, they cannot read memory in VTL1. Windows Hello's Enhanced Sign-in Security uses VBS to isolate biometric processing.

Microsoft's response: ESS and VBS

Microsoft's answer came with Windows 11: Enhanced Sign-in Security (ESS) [@ms-ess], which moved biometric matching into the VBS-protected enclave described above. Even a compromised Windows kernel cannot access templates or tamper with the comparison pipeline there.

flowchart TD subgraph VTL0["VTL0: Normal OS Environment"] A[Windows Kernel] B[Applications] C[Standard Drivers] end subgraph VTL1["VTL1: Secure World -- ESS"] D[Biometric Matching Engine] E[Encrypted Template Storage] F[Credential Isolation] end G[Hypervisor] --- VTL0 G --- VTL1 H[Secure Biometric Sensor] --> D A -.->|Blocked by Hypervisor| D B -.->|Blocked by Hypervisor| E

Alongside ESS, Microsoft rolled out Cloud Trust in 2022 [@ms-cloud-trust-ga], eliminating the need for on-premises PKI for many deployments. Two problems -- biometric isolation and deployment complexity -- were finally being addressed in parallel.

Red Bleed: the NIR assumption shatters (CVE-2025-26644)

The arms race was not over. In August 2025, researchers Bowen Hu, Kuo Wang, and Chip Hong Chang at Nanyang Technological University presented "Red Bleed" [@red-bleed] at USENIX Security 2025. Microsoft had already patched CVE-2025-26644 [@wiz-cve] in April 2025, but the full attack was now public.

Windows Hello's NIR facial recognition relied on a critical assumption: no commercial display can emit near-infrared light. The researchers shattered this assumption [@nvd-red-bleed] with a custom-built LCD screen costing less than $400 that could display NIR images. They trained a Variational Autoencoder to convert widely available RGB photos -- from social media, video calls, public sources -- into convincing NIR facial videos. The result: a presentation attack that bypassed Windows Hello face authentication and prompted liveness-detection hardening [@red-bleed-pdf]. The Red Bleed attack name references the "red bleed" phenomenon in LCD panels where a small amount of near-infrared light leaks through the color filters -- the researchers amplified this effect with a custom panel.

Microsoft's April 2025 patch strengthened liveness detection and anti-spoofing measures for NIR authentication.

Faceplant: the template swap (CVE-2026-20804)

The third major attack came from ERNW Research in August 2025. At Black Hat USA 2025, Baptiste David and Tillmann Oßwald's official conference briefing "Windows Hell No for Business" [@blackhat-windows-hell-no] detailed the Faceplant template-injection attack, which they later documented technically on ERNW's research blog [@faceplant].

In practice, an attacker with local administrator privileges could enroll their own face on one machine, extract the resulting template, and transplant it into the victim's biometric database on the target device. After injection, Windows Hello accepted the attacker's face for the victim's account. ERNW traced the weakness to software-protected templates that a local administrator could extract and replace on non-ESS systems [@faceplant].

ESS blocks this attack completely -- biometric templates in VTL1 are inaccessible even to local administrators. But many enterprise PCs lack ESS-compatible hardware.

Note: Many enterprise PCs -- particularly those shipped without an ESS-certified built-in biometric sensor, including many AMD-based and older Intel-based machines -- lack ESS capability. On these machines, biometric templates remain in software-protected storage vulnerable to the Faceplant attack. Verify hardware compatibility before assuming biometric isolation is active.

flowchart TD A["2015: Windows Hello Launch"] --> B["2021: CVE-2021-34466\nUSB Camera Spoofing"] B --> C["Microsoft Response:\nESS + VBS Isolation"] C --> D["2025: CVE-2025-26644\nRed Bleed NIR Attack"] D --> E["Microsoft Response:\nLiveness Detection Update"] E --> F["2025: CVE-2026-20804\nFaceplant Template Injection"] F --> G["Defense: ESS Hardware\nIsolation Blocks Attack"] G --> H["Ongoing: Adversarial ML\nArms Race"] classDef fake fill:#7a3030,stroke:#c44b4b,color:#fce8e8 class B fake,stroke:#333 class D fake,stroke:#333 class F fake,stroke:#333 classDef real fill:#2f5a3a,stroke:#5fa872,color:#dff5e4 class C real,stroke:#333 class E real,stroke:#333 class G real,stroke:#333

Key idea: Each generation of authentication protected a new layer -- but every layer revealed the next attack surface. The TPM protected the key. ESS protected the biometric pipeline. Liveness detection hardened NIR authentication. Security is never a single solution. It is a stack, and each layer needs its own defense.

The arms race revealed a humbling truth: biometric authentication is not a silver bullet. It is a layered defense -- and each layer needs its own protection. But while researchers probed Windows Hello's defenses, the industry was converging on something bigger.

The Convergence: Passkeys and the Passwordless Future

May 5, 2022. Apple, Google, and Microsoft [@passkeys-announcement] -- three companies that agree on almost nothing -- issued a joint announcement: they were all committing to passkeys.

A FIDO2/WebAuthn credential built on the same public-key model as Windows Hello. Passkeys can be device-bound (like traditional Hello credentials, stored in the TPM) or synced across devices through a credential manager such as iCloud Keychain or Google Password Manager. The local biometric or PIN check stays on-device; the relying party only sees public keys and signatures.

FIDO2 had a usability problem. Credentials were bound to a single device. Lose your laptop, lose your credentials. Passkeys solved this by introducing synced credentials -- private keys encrypted and distributed across a user's devices through their platform credential manager. The FIDO Alliance's protocol [@fido-how] maintained the cryptographic guarantees (no shared secrets, phishing resistance) while adding the portability users demanded."World Password Day" was symbolically renamed "World Passkey Day" in May 2025, when Microsoft announced that new accounts would default to passwordless authentication.

The numbers tell the story

By May 2025, Microsoft made new accounts passwordless by default [@ms-passkeys]:

Nearly 1 million passkey registrations daily [@ms-passkeys]
98% passkey sign-in success rate [@ms-passkeys] vs. 32% for passwords
Passkey sign-ins 8x faster [@ms-passkeys] than password + MFA

How the platforms compare

Dimension	Windows Hello (WHfB)	Apple Face ID / Passkeys	Google Passkeys	FIDO2 Hardware Keys
Hardware root of trust	TPM 2.0	Secure Enclave	TEE / Titan M	On-key secure element
Credential sync	No (device-bound)	Yes (iCloud Keychain)	Yes (Google PM)	No (hardware-bound)
Cross-platform	Windows only	Apple + QR/BT bridge	Android/Chrome + QR/BT	Universal USB/NFC/BT
FAR (face)	< 0.001%	< 0.0001%	Varies by OEM	N/A
Enterprise management	Intune, GP, Conditional Access	Limited (Apple MDM)	Android Enterprise	Manual provisioning
Recovery on device loss	Re-enroll on new device	iCloud backup restore	Google Account restore	Requires backup key
NIST AAL level	AAL2	AAL2	AAL2	AAL3-eligible
Best suited for	Windows enterprise	Apple platform	Android / cross-platform web	High-assurance regulated

Sources: Microsoft biometric requirements [@ms-biometric-reqs], Apple passkey security [@apple-passkeys-security], Google passkeys [@google-passkeys], FIDO specifications [@fido-specs]

Google's passkey story is centered on Google Password Manager: passkeys created on Android or Chrome sync across Android, ChromeOS, Windows, macOS, Linux, and Chrome browsers where the same account is available [@google-passkeys]. FIDO2 hardware security keys (YubiKey, Google Titan) take the opposite approach: the credential stays on a dedicated secure element, works across platforms via USB/NFC/Bluetooth, and must be provisioned deliberately on each account [@fido-u2f; @fido-how]. That trade-off buys the highest assurance available today; multi-factor cryptographic hardware authenticators are the mainstream route to NIST AAL3 [@nist-aal].

sequenceDiagram participant U as User participant B as Browser participant A as Platform Authenticator participant S as Relying Party Server U->>B: Click Register with Passkey B->>S: Request registration options S->>B: Return challenge + relying party info B->>A: navigator.credentials.create() A->>U: Prompt biometric verification U->>A: Present face / fingerprint / PIN A->>A: Generate key pair in TPM A->>B: Return public key + attestation B->>S: Send credential to server S->>S: Store public key for user S->>B: Registration complete

{` // This shows the structure of a WebAuthn registration request. // In production, the challenge comes from your server.

const registrationOptions = { publicKey: { // Random challenge from the server (32 bytes) challenge: crypto.getRandomValues(new Uint8Array(32)),

// Your service identity
rp: {
  name: "Example Corp",
  id: "example.com"
},

// User identity
user: {
  id: new Uint8Array([1, 2, 3, 4]),
  name: "alice@example.com",
  displayName: "Alice"
},

// Acceptable key types (ES256 = ECDSA P-256)
pubKeyCredParams: [
  { type: "public-key", alg: -7 }  // ES256
],

// Request a resident/discoverable credential (passkey)
authenticatorSelection: {
  residentKey: "required",
  userVerification: "required"  // Biometric or PIN
},

// 5-minute timeout
timeout: 300000

} };

console.log("Registration options structure:"); console.log(JSON.stringify(registrationOptions.publicKey.rp, null, 2)); console.log("\nKey algorithm: ES256 (ECDSA P-256)"); console.log("Resident key: required (discoverable passkey)"); console.log("User verification: required (biometric or PIN)"); console.log("\nIn production, call: navigator.credentials.create(registrationOptions)"); `}

Deploying Windows Hello Today

For consumers, the simplest path is built into Windows: open Settings > Accounts > Sign-in options, create a Windows Hello PIN first, then enroll face or fingerprint if the hardware is present [@ms-whfb]. If Windows only offers PIN, the machine lacks a compatible biometric sensor. On a laptop with an IR camera or certified fingerprint reader, enrollment takes a few minutes and the credential becomes device-bound immediately.

For enterprises, Microsoft now recommends starting with Cloud Trust unless certificate-based authentication is a hard requirement. A practical rollout checklist is short: confirm devices are Entra joined or hybrid joined, deploy Microsoft Entra Kerberos, verify Windows 10 21H2+/Windows 11 clients and Windows Server 2016+ read-write domain controllers in each site, then push Use Windows Hello for Business plus Use cloud trust for on-premises authentication through Intune or Group Policy [@ms-cloud-trust-ga]. That is dramatically lighter than standing up PKI, ADFS, and certificate templates.

ESS deserves its own hardware check. A TPM alone is not enough: ESS depends on Windows 11, VBS-capable hardware, and compatible secure biometric sensors [@ms-ess]. Unsupported systems can still use Hello, but they fall back to the older software-protected biometric path. Hardware inventory determines whether you are getting the modern threat model or merely the old UX.

Note: Start with a pilot group, require a Hello PIN for every enrolled user, and issue at least one backup FIDO2 security key to admins and help-desk staff. The cleanest password migration is additive: enroll Hello first, prove recovery works, then remove password prompts from the highest-value workflows last.

For password migration, avoid a flag day. Keep passwords as break-glass recovery while you move device sign-in, Microsoft 365, VPN, and high-value internal apps onto Hello or passkeys first [@ms-entra-passwordless]. Measure enrollment completion, recovery success, and hardware exceptions. Once those numbers stabilize, tighten Conditional Access so phishing-resistant credentials satisfy MFA and passwords become the fallback of last resort.

After 64 years, the password is finally losing its grip. But the story of Windows Hello is not a triumph -- it is a lesson in the limits of security engineering.

The Limits: What Remains Unsolved

Biometrics fail in a way passwords do not: they are hard to rotate.

You cannot change your face. This single fact defines the deepest unsolved problem in biometric authentication.

Passwords can be rotated. Security keys can be replaced. But you have one face, ten fingerprints, and two irises. If a biometric template is compromised, there is no "reset" button.

A technique for generating revocable biometric templates by applying non-invertible mathematical transformations to the original biometric data. If a transformed template is compromised, a new transformation can be applied to create a fresh template from the same biometric trait. In theory, this solves the irrevocability problem. In practice, the trade-off between non-invertibility and matching accuracy remains unresolved.

The biometric floor

The theoretical limit on biometric authentication error is the Bayes error rate [@jain-biometric] -- the minimum achievable error when the genuine-user and impostor score distributions overlap. Per information theory, the error probability is bounded by Fano's inequality:

$$P_e \geq \frac{H(X|Y) - 1}{\log |X|}$$

where $P_e$ is the probability of error, $H(X|Y)$ is the conditional entropy of identity given the biometric sample, and $|X|$ is the number of possible identities. Current systems achieve a FAR of $10^{-5}$ to $10^{-6}$, but the theoretical minimum [@jain-biometric] -- given perfect sensors and optimal classifiers -- could be orders of magnitude lower. The practical gap is driven by sensor noise, environmental variability, and aging of biometric features.

Five open problems

1. Cross-platform credential portability. Passkeys are currently vendor-locked. An Apple passkey does not transfer to a Google account. The FIDO Alliance published draft CXP/CXF specifications [@fido-cxp] in late 2024 for encrypted credential exchange, but full cross-vendor interoperability is not expected before late 2026.

2. The adversarial ML arms race. Generative AI can create increasingly convincing biometric spoofs -- the Red Bleed attack [@red-bleed] used a VAE to convert RGB photos to NIR facial videos. Discriminative AI tries to detect these spoofs. This is an open-ended arms race with no known endpoint.

3. Account recovery. When all biometric and device-based credentials fail, how does a user recover their account? Most services fall back to email or SMS [@ms-entra-passwordless] -- reintroducing the very phishable factors they were designed to eliminate. Recovery codes are functionally passwords.

Note: Systems that fall back to passwords or SMS for account recovery reintroduce the very vulnerabilities they were designed to eliminate. A truly passwordless system needs passwordless recovery -- and no universal solution exists yet.

4. The quantum threat. Shor's algorithm [@nist-pqc] on a sufficiently large quantum computer would break all ECDSA and RSA authentication -- including every FIDO2 credential in existence. NIST finalized post-quantum standards [@nist-pqc] (ML-DSA, SLH-DSA, ML-KEM) in 2024, but no FIDO2 authenticator ships with post-quantum support as of 2026.

All current FIDO2/WebAuthn authentication uses ECDSA P-256, which provides 128-bit classical security. Breaking a single credential requires approximately $2^{128}$ operations -- far beyond any existing computer.

Shor's algorithm changes this equation. A cryptographically relevant quantum computer could factor the elliptic curve discrete logarithm problem in polynomial time, breaking ECDSA entirely. No such computer exists today, but the "harvest now, decrypt later" threat means adversaries may be collecting signed assertions now to verify forged credentials later.

NIST finalized its first post-quantum cryptography standards in 2024 [@nist-pqc]: ML-DSA (formerly CRYSTALS-Dilithium) for signatures, ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation, and SLH-DSA (formerly SPHINCS+) for hash-based signatures. The FIDO Alliance and W3C are exploring hybrid signature schemes that combine classical ECDSA with post-quantum algorithms, but no timeline for standardization has been published.

5. The ESS hardware gap. ESS requires specific secure sensors and VBS-capable CPUs [@ms-ess]. Many enterprise PCs -- particularly those shipped without an ESS-certified built-in biometric sensor, including many AMD-based and older Intel-based machines -- lack ESS capability. On these devices, Windows Hello falls back to the pre-ESS security model, leaving them vulnerable to attacks like Faceplant.

6. Accessibility and inclusion. Biometric authentication creates barriers for people with facial differences, missing fingers, or conditions that affect biometric stability. A passwordless future must ensure that non-biometric alternatives (PINs, hardware keys) remain first-class options, not afterthoughts. Behavioral biometrics -- keystroke dynamics, gait analysis, continuous session verification -- represent an emerging parallel path that may expand authentication options beyond traditional biometric modalities.

Open PowerShell as administrator and run:

Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard -ClassName Win32_DeviceGuard | Select-Object VirtualizationBasedSecurityStatus

A value of 2 means VBS is running. Then check the biometric service:

Get-WinEvent -LogName Microsoft-Windows-Biometrics/Operational -MaxEvents 10 | Format-List

Look for events indicating ESS-protected biometric operations. If your device lacks ESS, consider disabling biometric sign-in on sensitive accounts and using FIDO2 hardware keys instead.

Key idea: Biometric traits are permanent and finite. Unlike passwords, they cannot be changed if compromised. This irrevocability is the deepest unsolved challenge in passwordless authentication -- and no amount of better sensors or smarter algorithms can change the fact that you have one face, ten fingerprints, and two irises.

The theoretically ideal system would combine zero-knowledge biometric verification, post-quantum cryptographic authentication, hardware-attested revocable credentials, and cross-platform portability. None of this exists yet.

The password's 64-year reign is ending, but its replacement is still under construction. Every generation of authentication solved one problem and revealed a deeper one. The question is not whether passwordless authentication will win -- it is whether we can build it before the attackers catch up.

Frequently Asked Questions

No. Biometric data never leaves the device. During enrollment, your face or fingerprint template is stored locally, protected by the operating system (and by VBS on ESS-enabled devices). Only a public key is registered with the identity provider (Azure AD / Entra ID) [@ms-whfb]. Microsoft's servers never receive, store, or process your biometric data. Standard photos cannot. Windows Hello uses near-infrared cameras [@ms-biometric-reqs] with anti-spoofing algorithms that distinguish between live faces and flat images. However, researchers have demonstrated advanced attacks: CVE-2021-34466 [@cyberark-bypass] used a custom USB device emulating an IR camera, and the Red Bleed attack [@red-bleed] used a custom NIR-emitting LCD display. Both have been patched, but the arms race continues. No -- it is more secure. A Windows Hello PIN is device-bound [@ms-whfb]: it unlocks a TPM-stored private key on that specific hardware. A stolen PIN is useless without physical access to the device. A password, by contrast, works from any device on earth and can be phished, reused, or leaked in a breach. Consumer Windows Hello [@ms-whfb] ties authentication to a personal Microsoft account. Windows Hello for Business integrates with Azure AD / Entra ID with enterprise management capabilities: conditional access policies, Intune deployment, multiple trust models (cloud, key, certificate), and group policy controls. They share the same biometric and TPM technology but have different management and security models. No. Passkeys build on Hello's foundation. Windows Hello acts as the platform authenticator for FIDO2 passkeys [@fido-how] on Windows -- your biometric gesture unlocks the passkey stored in the TPM. Passkeys extend Hello's model to cross-platform and cross-service authentication via the WebAuthn standard [@webauthn-3]. With device-bound credentials (traditional Windows Hello), you re-enroll on the new device using your Microsoft or organizational account. With synced passkeys, credentials restore from your credential manager -- iCloud Keychain [@apple-passkeys-security] for Apple, Google Password Manager [@google-passkeys] for Android/Chrome. Registering a FIDO2 hardware security key [@fido-specs] as a backup authenticator is strongly recommended. Not indefinitely. The asymmetric cryptography underlying Hello and FIDO2 (ECDSA P-256) is theoretically vulnerable [@nist-pqc] to quantum computers running Shor's algorithm. No quantum computer can break it today, and the timeline for cryptographically relevant quantum computers remains uncertain. NIST finalized post-quantum cryptography standards in 2024, but no FIDO2 authenticator ships with post-quantum support yet. Migration planning should begin now.

BitLocker on Windows: Architecture, Attacks, and the Limits of Full-Disk Encryption

noreply@paragmali.com (Parag Mali) — Sun, 26 Apr 2026 00:00:00 GMT

**Windows 11 now encrypts your drive with BitLocker by default -- no action required.** The encryption itself (XTS-AES) is solid, but the default TPM-only configuration is vulnerable to physical attacks costing as little as \$5 in hardware. For real security, add a pre-boot PIN, verify software encryption is enforced, and know where your recovery key is stored. This article traces BitLocker's 20-year evolution from an optional enterprise feature to encryption-by-default, explains its cryptographic architecture, catalogs every known attack, and compares it to VeraCrypt, LUKS, and FileVault.

Your Laptop Is Already Encrypted

Your Windows laptop is almost certainly encrypting every sector of its drive right now -- and you probably never turned that on. Since late 2024, every clean install of Windows 11 activates BitLocker by default, silently encrypting the entire volume and uploading a recovery key to Microsoft's cloud [@computerworld-24h2]. This is the culmination of a 20-year engineering effort that began with a stolen laptop containing 26.5 million veterans' medical records.

In May 2006, an employee of the U.S. Department of Veterans Affairs took home a laptop and an external hard drive containing the personal data of 26.5 million veterans and active-duty military personnel. Both were stolen from his home. The data was not encrypted. The breach later resulted in a $20 million class-action settlement and became the defining example of why laptops need full-disk encryption [@ms-bitlocker].

That event accelerated a shift already underway inside Microsoft: from "encryption is something you turn on" to "encryption is something that's always there." Today, the 24H2 update means every new Windows 11 installation has BitLocker active with no user action [@computerworld-24h2]. On Windows Home editions, this takes the form of Device Encryption -- a streamlined subset of BitLocker without Group Policy control or configurable pre-boot PIN.

But here is the tension at the heart of this story. BitLocker encrypts everything by default, yet security researchers keep finding ways past it -- with a $5 chip, a network cable, or a can of compressed air. If your drive is encrypted, why should you care?

The answer lies in how the keys are managed. And that story starts 25 years ago.

Before BitLocker: File-Level Encryption and Its Fatal Flaw

Before BitLocker, Windows had encryption. The Encrypting File System (EFS) shipped with Windows 2000 in 1999, and it encrypted individual files beautifully [@ms-efs]. So why wasn't that enough?

A file-level encryption feature built into NTFS since Windows 2000. EFS encrypts individual files using a randomly generated File Encryption Key (FEK), which is then wrapped with the user's RSA public key certificate. Decryption is transparent while the user is logged in.

EFS worked at the NTFS layer. Each file got its own symmetric key (DESX by default in Windows 2000; AES became the default EFS cipher in Windows XP SP1 and Windows Server 2003), wrapped with the user's public key and stored in a special NTFS attribute. When you were logged in, decryption happened transparently [@ms-efs].

The problem was where it didn't go. EFS encrypts files and folders -- not volumes. The operating system itself, the page file, the hibernation file, the temp directory -- all of that remained in plaintext. An attacker who booted from a USB stick could read the Windows directory, extract cached credentials from the SAM and SECURITY registry hives, and access fragments of "encrypted" files that the OS had swapped to disk [@ms-bitlocker].

The failure mode was concrete: steal a laptop, mount the drive on another machine, and everything the OS touched is readable. EFS protected the documents you remembered to encrypt. It did nothing for the thousands of files the OS created on your behalf. Microsoft also explored a far more ambitious approach. The "Next-Generation Secure Computing Base" (NGSCB), originally codenamed Palladium, proposed a hardware-rooted secure computing environment -- a tamper-resistant "nexus" running alongside Windows. Announced in 2002 under Peter Biddle's leadership, the full vision was scaled back around 2004-2005 under a wave of industry resistance and public backlash over DRM fears. But its core idea -- a Trusted Platform Module providing hardware-rooted key storage -- survived and became BitLocker's anchor [@ngscb-wiki].

A dedicated hardware chip (or firmware module) that provides cryptographic key storage, platform integrity measurement, and sealed storage. The TPM can "seal" a secret to specific Platform Configuration Register (PCR) values, releasing it only when the boot chain matches the expected measurements. Standardized by the Trusted Computing Group (TCG), first as TPM 1.2 and later TPM 2.0.

Microsoft needed something that encrypted everything on the disk -- the OS, the swap file, the hibernation file, the temp files, all of it. But who would design the cipher, and how would the keys be protected without making the user type a 48-character password at every boot?

The Architecture: How BitLocker Actually Works

In 2006, a Dutch cryptographer named Niels Ferguson published a paper describing a new disk encryption scheme [@ferguson-2006]. Two decades later, the core architecture he designed is still running on hundreds of millions of machines -- structurally unchanged.

The Three-Layer Key Hierarchy

BitLocker's design centers on a three-layer key hierarchy that solves an otherwise painful problem: how do you let a user change their password without re-encrypting an entire 2 TB drive?

The symmetric key that directly encrypts and decrypts disk sectors. In XTS-AES-256 mode, this is effectively two 256-bit AES keys -- one for block encryption, one for the XTS "tweak" computation that ensures identical plaintext at different sector locations produces different ciphertext. A key-encrypting key that wraps the FVEK. The VMK itself is encrypted by one or more key protectors. This indirection allows changing authentication methods (adding a PIN, rotating a recovery key) without re-encrypting the entire volume -- only the VMK wrapping changes. An authentication mechanism that independently encrypts the VMK. Common protectors include TPM-only (VMK sealed to Platform Configuration Registers), TPM+PIN (adds a user-supplied PIN), and Recovery Password (a 48-digit numerical backup code). Multiple protectors can coexist on the same volume.

The indirection is the key insight. Your data is encrypted with the FVEK. The FVEK is wrapped by the VMK. The VMK is wrapped by one or more key protectors -- your TPM, your PIN, your recovery password. When you change your PIN, only the VMK wrapper changes. The FVEK stays the same. The entire volume never needs re-encryption [@ms-bitlocker].

TPM Sealing: The Hardware Root of Trust

At boot time, the TPM measures each component of the boot chain -- firmware, bootloader, boot configuration -- and records hashes in its Platform Configuration Registers (PCRs). During BitLocker setup, the TPM seals the VMK to the current PCR values. On every subsequent boot, the TPM re-measures the chain. If the measurements match, the TPM releases the VMK. If anything has changed -- a modified bootloader, a BIOS update, a different boot device -- the TPM refuses, and the user must provide a recovery key [@ms-bitlocker].

A register inside the TPM that stores a hash representing the state of a specific component of the boot chain (firmware, bootloader, OS kernel, etc.). PCR values are "extended" at each boot step -- the new measurement is hashed together with the previous value, creating a tamper-evident chain. BitLocker seals the VMK to specific PCR values so that any modification to the boot process blocks key release. sequenceDiagram participant UEFI as UEFI Firmware participant TPM as TPM Chip participant BL as Windows Boot Manager participant OS as Windows OS UEFI->>TPM: Extend PCR 0-7 (firmware measurements) BL->>TPM: Extend PCR 8-11 (bootloader measurements) BL->>TPM: Request VMK unseal alt PCR values match sealed state TPM->>BL: Release VMK (cleartext) BL->>OS: Decrypt FVEK, mount volume else PCR mismatch (tampered boot chain) TPM->>BL: Refuse unseal BL->>OS: Prompt for recovery key end

Ferguson's Elephant diffuser served BitLocker well from Vista through Windows 7, but it was a custom, non-standard construction. Government compliance frameworks (FIPS 140-2) and the emerging IEEE 1619 standard required a published, peer-reviewed cipher mode [@nist-800-38e]. Ferguson's original 2006 design used AES-128 in CBC mode with a custom "Elephant" diffuser -- a two-pass diffusion algorithm (one pass forward, one pass backward) applied to each 512-byte sector. The Elephant diffuser ensured that flipping one bit of ciphertext would scramble the entire sector of plaintext, raising the bar for sector manipulation attacks. The name was reportedly a nod to the animal's famously long memory -- a reference to diffusion spreading changes across the entire sector.

The removal of the Elephant diffuser in Windows 8 was controversial. Microsoft cited FIPS 140-2 certification requirements and alignment with standardized disk-encryption modes as the primary motivations. Windows 8 kept AES-CBC but removed the proprietary whole-sector diffuser; Windows 10 version 1511 later moved new volumes to XTS-AES. Critics pointed out that both post-Elephant designs lost the diffuser's whole-sector avalanche behavior. Microsoft chose standards compliance over a proprietary advantage -- a pragmatic decision that made BitLocker deployable in regulated environments worldwide [@ms-bitlocker].

Windows 10 version 1511 (November 2015) completed the transition by making XTS-AES-128 the default for new volumes, with XTS-AES-256 available via Group Policy [@ms-bitlocker]. XTS stands for XEX-based Tweaked-codebook mode with ciphertext Stealing, built on Rogaway's XEX (XOR-Encrypt-XOR) construction [@rogaway-2004]. The core XEX pattern works like this: each sector gets a unique "tweak" derived from its sector number, and each 16-byte block within that sector is XORed with the tweak, AES-encrypted, then XORed with the tweak again. XTS extends XEX by adding ciphertext stealing to handle sectors that are not an exact multiple of 16 bytes. The result: identical plaintext at different disk locations produces different ciphertext, and there is no IV management problem like CBC had [@nist-800-38e].

flowchart LR SN["Sector Number"] --> TW["Tweak Generation
(AES encrypt sector #
with tweak key)"] TW --> X1a["XOR with
Tweak"] TW --> X2a["XOR with
Tweak"] TW --> XNa["XOR with
Tweak"] P1["Plaintext
Block 1"] --> X1a --> AES1["AES Encrypt"] --> X1b["XOR with
Tweak"] --> C1["Ciphertext
Block 1"] P2["Plaintext
Block 2"] --> X2a --> AES2["AES Encrypt"] --> X2b["XOR with
Tweak"] --> C2["Ciphertext
Block 2"] PN["Plaintext
Block N"] --> XNa --> AESN["AES Encrypt"] --> XNb["XOR with
Tweak"] --> CN["Ciphertext
Block N"]

This architecture is elegant. The TPM releases the key automatically at boot if nothing has changed. The key hierarchy means operational changes (new PIN, new recovery key) never touch the encrypted data. The cipher mode is standardized, hardware-accelerated via AES-NI on virtually all modern CPUs [@intel-aesni], and FIPS-validated.

But what happens if an attacker gets to the hardware? Princeton researchers were about to find out.

The Cold Wake-Up Call: Attacks That Changed Everything

In 2008, a team at Princeton did something unsettling. They sprayed a laptop's RAM with compressed air, yanked the power cord, and recovered the BitLocker encryption key from the memory that should have been erased. It wasn't [@halderman-2008].

A physical attack exploiting the fact that DRAM retains its contents for seconds to minutes after power loss (a property called "data remanence"). By cooling RAM to extend retention time and quickly rebooting into an attacker-controlled OS, encryption keys can be extracted from residual memory contents. First demonstrated against BitLocker, FileVault, and dm-crypt by Halderman et al. at Princeton in 2008.

J. Alex Halderman and his team demonstrated that DRAM does not instantly lose its contents when power is removed. At room temperature, data decays over seconds. Cooled with compressed air (around -50C), retention extends to minutes. That is enough time to reboot into a USB-based attack environment, scan memory for AES key schedules, and extract the FVEK [@halderman-2008].

DRAM retains its contents for seconds to minutes after power loss... enough time to extract full encryption keys. -- Halderman et al., 2008, adapted from the paper's findings.

The cold boot attack revealed a fundamental truth about every full-disk encryption system: the keys must live in RAM while the OS is running. There is no way around this. Encrypt the keys in memory and you need a key to decrypt those keys -- turtles all the way down. The cold boot paper did not just break BitLocker; it defined the boundary of what FDE can and cannot do.

The $5 Chip That Reads Your Encryption Key

In 2019, Denis Andzakovic at Pulse Security demonstrated something even more unsettling: in BitLocker's default TPM-only configuration, the VMK travels in cleartext on the communication bus (SPI or LPC, depending on hardware) between the discrete TPM chip and the CPU [@andzakovic-2019]. A $40 NZD FPGA, clipped to the right pins, captured the VMK during boot. The drive was decrypted offline in under five minutes.

sequenceDiagram participant CPU as CPU participant SPI as SPI / LPC Bus participant TPM as Discrete TPM participant ATK as Attacker (logic analyzer) Note over CPU,TPM: Normal boot sequence CPU->>SPI: Request VMK unseal SPI->>TPM: Forward request TPM->>SPI: Return VMK (cleartext!) ATK->>SPI: Sniff VMK from bus traffic SPI->>CPU: Deliver VMK Note over ATK: Attacker now has VMK -- Drive can be decrypted offline

The SCRT security team independently reproduced this attack in 2021 [@scrt-tpm-2021], and by 2024, the community had replaced the FPGA with a $5 Raspberry Pi Pico [@tpm-sniffing-repo]. Compass Security documented successful attacks on Lenovo ThinkPad, HP EliteBook, and Microsoft Surface models -- the most common enterprise laptops [@compass-bypasses]. The $40 FPGA that Andzakovic used in 2019 has since been replaced by a $5 Raspberry Pi Pico in community tooling. The TPM-Sniffing repository on GitHub maintains a list of tested laptop models and TPM chips, with specific pinout diagrams for each.

Even adding a TPM+PIN does not fully close this gap. In October 2024, SCRT Security demonstrated that if an attacker knows (or coerces) the PIN, the VMK can still be extracted via SPI bus sniffing [@scrt-tpm-pin-2024]. The real mitigation is a firmware TPM (fTPM, integrated into the CPU) -- when the TPM is on the same die as the processor, there is no external bus to sniff.

The SSD Betrayal

In 2019, Carlo Meijer and Bernard van Gastel at Radboud University published findings that shocked the storage industry. Multiple popular SSDs from Samsung and Critical had critically flawed hardware encryption. In some cases, the data encryption key was stored in plaintext on the drive. In others, the user's password was never actually used for key derivation [@meijer-2019].

Multiple popular SSDs had critically flawed hardware encryption -- in some cases, the data encryption key was stored in plaintext or could be recovered by manipulating firmware. -- Meijer and van Gastel, 2019, summarizing their IEEE S&P findings. This was not a theoretical weakness. BitLocker's "eDrive" mode trusted SSD firmware to perform encryption. On a Samsung 850 EVO or Critical MX300 with eDrive enabled, BitLocker reported the drive as "encrypted" -- but an attacker with physical access could use JTAG debugging or firmware manipulation to read all data in plaintext. The data was never actually encrypted by the hardware [@meijer-2019]. Microsoft issued Security Advisory ADV180028 in November 2018, recommending administrators enforce software encryption, and later changed the default so BitLocker no longer trusts hardware encryption [@adv180028].

DMA and Bitpixie: The Attacks Keep Coming

Ulf Frisk's PCILeech tool (2016) turned DMA attacks into a scriptable operation. Any system with unprotected Thunderbolt, ExpressCard, or PCIe slots was vulnerable to direct memory reads while powered on or in sleep mode [@pcileech]. Björn Ruytenberg's Thunderspy research (2020) found seven vulnerabilities in Intel's Thunderbolt protocol that enabled evil-maid DMA attacks bypassing disk encryption and screen locks. Microsoft introduced Kernel DMA Protection in Windows 10 version 1803, using IOMMU to block unauthorized DMA from external Thunderbolt and PCIe devices -- closing this vector on supported hardware [@ms-kernel-dma].

And in 2023, the "bitpixie" vulnerability (CVE-2023-21563) introduced a purely software-based bypass. An attacker with physical access triggers a PXE network boot, which performs a soft reboot -- leaving the VMK in RAM. The attacker boots into a Linux environment (or, in newer variants using the WinPE approach, a custom Windows PE image that avoids Secure Boot restrictions on third-party Linux loaders), scans memory, and extracts the VMK. The entire attack takes about five minutes and requires no hardware modifications [@cve-2023-21563].

Each attack reinforced the same lesson: full-disk encryption only protects data at rest. The default TPM-only configuration was never designed to resist a determined attacker with physical access. So how did Microsoft respond?

The Evolution: Generation by Generation

What makes BitLocker's history unusual is that each generation was a direct response to a specific failure. The evolution was not planned from the start -- it was forced by attackers.

flowchart TD G0["Gen 0: EFS (2000)
File-level encryption"] -->|"OS/swap/temp left exposed"| G1["Gen 1: Vista BitLocker (2006)
AES-CBC + Elephant diffuser"] G1 -->|"OS drive only; non-standard cipher"| G2["Gen 2: Win 7 (2009)
+ BitLocker To Go"] G2 -->|"Elephant blocks FIPS/IEEE compliance"| G3["Gen 3: Win 8/8.1 (2012-2013)
No Elephant + eDrive + Device Encryption"] G3 -->|"SSD hardware encryption broken (2018)"| G4["Gen 4: Win 10 (2015-2021)
Software-first + cloud management"] G4 -->|"Still not default for consumers"| G5["Gen 5: Win 11 24H2 (2024)
Encryption by default"]

Generation 0 -- EFS (2000): File-level encryption on NTFS. Left the OS, swap, and temp files exposed. Superseded because volume-level encryption was needed [@ms-efs].

Generation 1 -- Vista (2006): Ferguson's AES-CBC + Elephant diffuser. First volume-level encryption in Windows. OS drive only. The cold boot attack (2008) revealed that FDE keys in RAM are vulnerable [@ferguson-2006, @halderman-2008].

Generation 2 -- Windows 7 (2009): Added BitLocker To Go for USB drives and data volumes. The 2006 VA breach had involved a stolen external hard drive, making removable media encryption urgent. The Elephant diffuser persisted, blocking compliance certification [@ms-bitlocker].

Generation 3 -- Windows 8/8.1 (2012-2013): Removed the Elephant diffuser while retaining AES-CBC, introduced eDrive hardware offload in Windows 8, and added consumer Device Encryption in Windows 8.1. The SSD betrayal (2018) destroyed the eDrive trust model [@ms-bitlocker, @meijer-2019].

Generation 4 -- Windows 10 (2015): XTS-AES-128 became the default for new volumes in version 1511. Software encryption was enforced after the Radboud findings. Cloud-based key escrow via Azure AD. TPM sniffing attacks (2019) showed the default TPM-only configuration was vulnerable [@adv180028, @andzakovic-2019].

Generation 5 -- Windows 11 24H2 (2024): Encryption by default on clean installs. Relaxed hardware requirements (no Modern Standby/HSTI needed). TPM 2.0 mandatory. Recovery keys escrowed to Microsoft Account or Azure AD. Hardware-accelerated encryption available in 25H2 [@techpowerup-hwaccel].

gantt title BitLocker Evolution and Attack Timeline dateFormat YYYY axisFormat %Y section Generations EFS (file-level) :g0, 2000, 2006 Vista: AES-CBC+Elephant :g1, 2006, 2009 Win 7: +BitLocker To Go :g2, 2009, 2012 Win 8/8.1: no Elephant+eDrive :g3, 2012, 2015 Win 10: Software-first :g4, 2015, 2024 Win 11 24H2: Default :g5, 2024, 2026 section Attacks Cold boot (Princeton) :milestone, 2008, 0d DMA/PCILeech :milestone, 2016, 0d SSD bypass (Radboud) :milestone, 2018, 0d TPM sniffing :milestone, 2019, 0d Thunderspy :milestone, 2020, 0d Bitpixie (CVE-2023-21563) :milestone, 2023, 0d

By 2024, BitLocker had evolved from an enterprise opt-in feature to encryption that activates without asking. But how does it compare to what Linux and macOS users have?

BitLocker vs. the Competition

BitLocker is not the only option. Every major OS now ships with full-disk encryption, and the open-source world offers capabilities that BitLocker cannot match.

Dimension	BitLocker (Win 11)	VeraCrypt	LUKS2 (dm-crypt)	FileVault 2	SEDs (TCG Opal)
Platform	Windows	Windows, macOS, Linux	Linux	macOS	Any (firmware)
Cipher	XTS-AES-128/256	XTS-AES, Serpent, Twofish, cascades	XTS-AES (default)	XTS-AES-256 (APFS)	AES-256 (vendor)
Key derivation	TPM sealing + optional PIN	PBKDF2 + PIM	Argon2id (memory-hard)	Secure Enclave	Firmware-specific
Open source	No	Yes	Yes	No	No
Audited	FIPS 140-2 certified	Quarkslab 2016; Fraunhofer/BSI 2020	Community-audited	Apple docs published	Radboud found flaws
Enterprise mgmt	Intune, GPO, SCCM	None	Scriptable	MDM (Jamf)	Vendor-specific
Plausible deniability	No	Yes (hidden volumes)	No	No	No
Performance	Minimal (sequential); up to 50% random IOPS loss	Similar	Similar	Near-zero (hardware)	Near-zero (hardware)

VeraCrypt (2013) is the open-source TrueCrypt fork, maintained by Mounir Idrassi [@veracrypt-docs]. It offers cascaded ciphers (AES-Twofish-Serpent), hidden volumes for plausible deniability, and cross-platform support. Its hidden volume feature is particularly notable: a single encrypted container holds two volumes with different passwords, and the outer volume's free space is cryptographically indistinguishable from the hidden volume's ciphertext. An adversary who compels you to reveal a password gets the decoy; the hidden volume remains undetectable. VeraCrypt was audited by Quarkslab in 2016, which found 8 critical and 3 medium-severity vulnerabilities; v1.19 fixed many high-priority issues, while OSTIF noted that some complex findings were handled with documented workarounds rather than complete fixes. It was audited by Fraunhofer SIT, commissioned by the German BSI, in 2020 [@ostif-veracrypt]. What it lacks is enterprise management -- no centralized key escrow, no MDM integration, no Group Policy. For individual privacy, it is unmatched. For a fleet of 10,000 laptops, it is impractical. VeraCrypt's hidden volumes provide plausible deniability -- you can be compelled to reveal a password, and it unlocks a decoy volume while the real data remains hidden in space that is statistically indistinguishable from random data. No other mainstream FDE tool offers this capability.

LUKS2 with dm-crypt is Linux-native full-disk encryption, maintained as part of the cryptsetup project [@cryptsetup-faq]. Its standout feature is the Argon2id key derivation function -- a memory-hard, GPU/ASIC-resistant password hash that provides superior brute-force resistance compared to BitLocker's TPM-based approach or VeraCrypt's PBKDF2 [@argon2-spec]. Why does memory-hardness matter? GPUs and ASICs can test billions of PBKDF2 hashes per second because each attempt needs little memory. Argon2id forces each attempt to allocate a configurable amount of RAM; LUKS2 calibrates the parameters to a target unlock time on the host system rather than using a fixed 1 GB default. That makes parallel brute-force attacks on GPUs prohibitively expensive. LUKS2 supports up to 32 keyslots, allowing multiple users or recovery methods per volume [@cryptsetup-faq]. It integrates with systemd-cryptenroll for TPM2 and FIDO2 token support. But it is Linux-only, and setup requires comfort with the command line.

A memory-hard key derivation function (KDF) that won the Password Hashing Competition in 2015. Argon2id combines the data-dependent memory access pattern of Argon2d with the data-independent access pattern of Argon2i, providing resistance to both GPU-based brute-force attacks and side-channel attacks. Used by LUKS2 as its default KDF, replacing the older PBKDF2.

FileVault 2 is macOS-native full-disk encryption, deeply integrated with Apple's hardware. On APFS volumes (macOS High Sierra and later), FileVault uses XTS-AES-256. On T2-equipped Intel Macs and all Apple Silicon machines, the Secure Enclave -- a dedicated security coprocessor physically isolated from the main CPU -- manages encryption keys in hardware. Unlike a discrete TPM where keys transit an external bus (the vulnerability that enables TPM sniffing), Secure Enclave keys never leave the chip. The SSD controller handles encryption in real-time using dedicated AES hardware. The result is near-zero measurable performance impact. FileVault is what happens when one company controls both the hardware and software.

Self-Encrypting Drives (SEDs) conforming to TCG Opal perform encryption in the drive's firmware with zero CPU overhead. But after the Radboud findings, trusting opaque SSD firmware for security is a gamble. The Meijer and van Gastel research affected drives from Samsung and Critical that, according to the researchers, represented roughly 60% of the consumer SSD market at the time [@meijer-2019].

Each approach makes different trade-offs between transparency, performance, enterprise management, and trust. But they all share one theoretical limitation.

The Limits: What No Full-Disk Encryption Can Do

Here is the uncomfortable truth that no vendor will put on the box: full-disk encryption cannot protect your data while your computer is running. That is not a bug. It is a fundamental impossibility.

Any full-disk encryption system must hold decryption keys in volatile memory while the OS is running. Full protection is available only when the device is powered off.

Any FDE system -- BitLocker, VeraCrypt, LUKS, FileVault -- must load the decryption key into RAM to service I/O requests. While the key is in RAM, it is vulnerable to cold boot attacks, DMA attacks, and any malware running with kernel privileges. This is not a design flaw. It is an impossibility result. You cannot encrypt and decrypt data simultaneously without holding a key somewhere accessible [@halderman-2008].

The XTS Semantic Security Gap

XTS mode has a narrower theoretical limitation. It uses a sector-derived tweak, so identical plaintext at the same block offset in different sectors does not produce identical ciphertext. The limitation is narrower diffusion: each 16-byte block is protected independently within the sector, so a targeted ciphertext modification corrupts the corresponding 16-byte plaintext block rather than avalanching across the entire sector. Phillip Rogaway's tweakable-block-cipher work explains why narrow-block disk modes have this shape [@rogaway-2004].

Wide-block modes like EME and CMC, proposed by Shai Halevi and Rogaway, encrypt an entire sector as a single block -- changing one bit of plaintext changes every bit of ciphertext across the sector [@halevi-rogaway-eme]. These modes provide stronger semantic security but at higher computational cost, and no major FDE system has adopted them.

NIST SP 800-111 recommends pre-boot authentication for full-disk encryption in government systems [@nist-sp800-111]. Organizations subject to NIST guidelines may find TPM-only mode insufficient for compliance -- both because of the bus sniffing vulnerability and because of the XTS narrow-block limitation. The practical recommendation is TPM+PIN with XTS-AES-256, which satisfies most regulatory frameworks even if it does not close the theoretical semantic security gap.

The Performance Reality

Software-based BitLocker on fast NVMe SSDs carries a real cost. TechPowerUp measured a 375% increase in CPU cycles per I/O when software BitLocker is active, with random 4K IOPS dropping by up to 50% [@techpowerup-hwaccel]. Sequential throughput impact is typically under 5% thanks to AES-NI acceleration, but the random I/O penalty matters for database workloads and developer builds.

Microsoft's hardware-accelerated BitLocker, available in Windows 11 25H2, uses CPU crypto instructions and NVMe controller integration to close this gap. Early benchmarks show random 4K IOPS doubling compared to software mode, with CPU usage dropping by over 70% -- approaching unencrypted performance [@techpowerup-hwaccel].

Metric	No BitLocker	Software BitLocker	HW-Accelerated BitLocker (25H2)
Sequential read/write	Baseline	~5% overhead	~0% overhead
Random 4K IOPS	Baseline	Up to 50% loss	~10% loss
CPU cycles per I/O	Baseline	+375%	~+30%

If the fundamental limits are known, what problems remain unsolved?

Open Problems: What Keeps Researchers Awake

BitLocker is mature, battle-tested, and now ubiquitous. Yet at least five significant problems remain open -- and some of them could invalidate the entire trust model.

Post-quantum readiness. AES-256 survives Grover's algorithm with an effective 128-bit security level -- still intractable for foreseeable quantum computers [@nist-800-38e]. But the key management layer is not quantum-safe. TPM 2.0 attestation and Azure AD key escrow use RSA-2048 or ECC P-256, both vulnerable to Shor's algorithm. NIST finalized post-quantum key encapsulation (ML-KEM) and digital signature (ML-DSA) standards in 2024 [@nist-pqc], but no shipping FDE system integrates post-quantum cryptography into its key management chain yet.

SSD firmware auditability. There is no standard mechanism to verify that a self-encrypting drive's firmware actually implements encryption correctly. The Radboud findings proved this is not hypothetical. Microsoft's policy of defaulting to software encryption works around the problem but does not solve it for hardware-only use cases [@meijer-2019].

Secure Boot trust chain revocation. The bitpixie attack persists because older, vulnerable bootloaders remain trusted by Secure Boot. Revoking old certificates via DBX updates is slow and risks bricking devices on heterogeneous hardware fleets. Microsoft's KB5025885 provides a phased revocation approach, but the transition from the 2011 Microsoft UEFI CA to the 2023 CA is incomplete [@cve-2023-21563].

Recovery key awareness. Encryption-by-default means millions of non-technical users have BitLocker active without understanding recovery key management. If a TPM is replaced, a BIOS update changes PCR values, or the motherboard is swapped, users who do not know they have a recovery key -- or where it is stored -- may permanently lose access to all their data [@elcomsoft-forensics].

Forensic and legal implications. As every Windows device becomes encrypted by default, law enforcement and digital forensics face increasing difficulty accessing data on seized devices. Courts are grappling with compelled decryption and Fifth Amendment implications. Forensic vendors maintain tools that exploit known weaknesses (like bitpixie), but these become less effective as mitigations are deployed [@elcomsoft-forensics]. Twenty years after BitLocker first shipped, the symmetric encryption itself (AES-256) is solved. The unsolved problems are all about trust -- in hardware, in firmware, in cloud key escrow, and in users' ability to manage their own recovery keys.

Practical Guide: Deploying BitLocker Correctly

Theory is useful. Configuration is what actually protects your data. Here is how to deploy BitLocker in a way that addresses the known attack surface.

Recommended Configuration

For sensitive systems, the recommended configuration is:

TPM+PIN -- Closes the TPM bus sniffing gap. The PIN adds a knowledge factor that the TPM requires before releasing the VMK. Even on discrete TPM chips, the attacker cannot extract the VMK without the PIN (though the PIN itself must be strong enough to resist brute-force) [@andzakovic-2019, @scrt-tpm-pin-2024].
XTS-AES-256 -- The maximum key length available. Configure via Group Policy: Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives > Choose drive encryption method and cipher strength.
Software encryption mode -- Do not trust SSD hardware encryption. Force software mode via Group Policy: Configure use of hardware-based encryption for operating system drives: Disabled [@adv180028].
Verify recovery key location -- Check that your recovery key is stored somewhere you can access. For consumers: https://account.microsoft.com/devices/recoverykey. For enterprises: verify Azure AD / Entra ID escrow.

Verification Commands

{` // Simulates the logic of manage-bde -status and Get-BitLockerVolume // In production, run these PowerShell commands: // manage-bde -status C: // Get-BitLockerVolume -MountPoint C: | Select-Object *

const config = { volume: "C:", encryptionMethod: "XTS-AES-256", protectors: ["Tpm", "RecoveryPassword"], encryptionPercentage: 100, lockStatus: "Unlocked", hardwareEncryption: false };

// Check 1: Is a PIN configured? const hasPIN = config.protectors.some(p => p === "TpmPin" || p === "TpmPinStartupKey" ); console.log(hasPIN ? "OK: Pre-boot PIN is configured" : "WARNING: No pre-boot PIN -- vulnerable to TPM bus sniffing" );

// Check 2: Is encryption AES-256? const is256 = config.encryptionMethod.includes("256"); console.log(is256 ? "OK: Using AES-256" : "INFO: Using AES-128 (consider upgrading to 256)" );

// Check 3: Software encryption? console.log(!config.hardwareEncryption ? "OK: Software encryption (not trusting SSD firmware)" : "WARNING: Hardware encryption in use -- verify SSD firmware integrity" );

// Check 4: Recovery password exists? const hasRecovery = config.protectors.includes("RecoveryPassword"); console.log(hasRecovery ? "OK: Recovery password protector exists" : "WARNING: No recovery password -- data may be irrecoverable" );

// Check 5: Fully encrypted? console.log(config.encryptionPercentage === 100 ? "OK: Volume is fully encrypted" : "WARNING: Encryption is " + config.encryptionPercentage + "% complete" );

console.log("\n--- Recommendation ---"); if (!hasPIN) { console.log("Run: manage-bde -protectors -add C: -TPMAndPIN"); console.log("This adds a pre-boot PIN to mitigate bus sniffing attacks."); } `}

Common Pitfalls

Firmware updates triggering recovery mode: BIOS/UEFI updates change PCR values, causing the TPM to refuse VMK release. Always suspend BitLocker before firmware updates: manage-bde -protectors -disable C: [@ms-bitlocker-ps].
Dual-boot scenarios: BitLocker encrypts the Windows volume; Linux cannot natively read BitLocker partitions (though the dislocker tool provides limited read support [@dislocker-github]). Plan partition layouts carefully.
Hardware swaps: Replacing the motherboard or TPM chip triggers recovery mode. Ensure the recovery key is accessible before hardware changes.
Recovery key in deleted Microsoft Account: If the Microsoft Account used during setup is later deleted, the escrowed recovery key is lost. Verify the key is backed up to multiple locations.

No. Full-disk encryption protects data at rest -- meaning when the device is powered off. While the OS is running, the decryption key is in RAM and vulnerable to DMA attacks, cold boot attacks, and malware with kernel access. While in sleep mode, the key is still in RAM. The protection window is narrower than most people assume: it really only covers a powered-off device stolen by someone without your recovery key. BitLocker's source code is not publicly available, so independent code audits are not possible. However, the cryptographic design is published (Ferguson's 2006 paper), the implementation is FIPS 140-2 certified by an independent lab, and the XTS-AES cipher mode is standardized by IEEE and NIST. The recovery key escrow to Microsoft's cloud is not a "backdoor" -- it is a documented feature. If you do not want Microsoft to hold your recovery key, you can store it locally or in on-premises Active Directory instead. No -- not without independent verification. The Radboud University research (Meijer and van Gastel, 2019) proved that Samsung and Critical SSDs had critically broken hardware encryption, affecting drives that the researchers said represented roughly 60% of the consumer SSD market. Microsoft now defaults to software encryption and recommends against relying on SSD hardware encryption unless independently validated. Force software mode via Group Policy. Yes. Your Windows login password protects against *online* attacks -- someone trying to log in while the OS is running. It does nothing against *offline* attacks. An attacker who removes your drive and connects it to another machine bypasses the login screen entirely. Without encryption, your data is readable. A strong login password and full-disk encryption solve different problems. It depends on the workload. Sequential read/write performance drops by about 5% with software BitLocker, barely noticeable in daily use thanks to AES-NI hardware acceleration. Random 4K IOPS -- important for databases and development builds -- can drop by up to 50%, with CPU cycles per I/O increasing by 375%. Microsoft's hardware-accelerated BitLocker in Windows 11 25H2 closes most of this gap, bringing random IOPS to within 10% of unencrypted performance. Your data is permanently inaccessible. There is no master key, no backdoor, and no way to brute-force AES-256. Check these locations for your recovery key: (1) Microsoft Account at account.microsoft.com/devices/recoverykey, (2) Azure AD / Entra ID if your device is enterprise-managed, (3) a printed copy if you saved one during setup. If none of these have the key, the data is gone. Yes, especially on laptops with discrete TPM chips. Without a PIN, the TPM releases the encryption key automatically at every boot with no human input. An attacker with brief physical access can sniff the key from the TPM's SPI bus using a \$5 Raspberry Pi Pico. A pre-boot PIN adds a knowledge factor that the TPM requires before release. Run: `manage-bde -protectors -add C: -TPMAndPIN` to enable it.

What Comes Next

Twenty years of BitLocker history tell a consistent story: the encryption itself was never the weak link. AES has held. XTS mode is mathematically sound. Ferguson's key hierarchy design from 2006 still works.

Every real-world failure -- every headline, every conference demo, every CVE -- targeted the trust boundary around the encryption. The trust that RAM clears instantly (it does not). The trust that SSD firmware encrypts honestly (it did not). The trust that the TPM bus is not observable (it is). The trust that users understand their recovery keys (they do not).

The next chapter of this story will be written by quantum computers and post-quantum cryptography. AES-256 will survive Grover's algorithm. But the RSA and ECC that protect key exchange, TPM attestation, and cloud escrow will not survive Shor's. No shipping FDE system has integrated post-quantum key management yet [@nist-pqc]. The clock is ticking -- and the question is whether the industry will act before the deadline, or after the first quantum key recovery makes the news.

For now, the practical advice is simple: enable TPM+PIN, enforce software encryption, know where your recovery key is, and remember that BitLocker protects your data only when your machine is off.