Parag Mali - tag: secure-kernel

The Driver That Was Signed and the Driver That Won't Load: Windows Kernel Code Integrity, 2006-2026

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

**Windows ships a list of Microsoft-signed drivers it refuses to load.** That list -- `DriverSiPolicy.p7b` -- exists because every previous generation of kernel-driver trust assumed a signed driver was a safe driver, and a twenty-year run of Bring-Your-Own-Vulnerable-Driver attacks (Stuxnet, Capcom.sys, RTCore64.sys, gdrv.sys) proved that assumption wrong. The 2026 default-on stack -- KMCS, the block list, HVCI in VTL1, Smart App Control, and Defender ASR coverage -- is five gates doing what one ideal gate cannot do: name the specific weakness, not just the publisher. The architectural gap that motivates the stack is undecidable in principle and will not close.

1. The Driver That Loaded

On 13 September 2016, the researcher Matt Nelson posted on his enigma0x3 blog that a Capcom-published kernel driver, Capcom.sys, exposed IOCTL 0xAA013044 and used it to execute a user-supplied function pointer in kernel mode, with SMEP disabled along the way [@gh-tandasat-capcom] [@gh-tandasat-capcom]. Within two weeks the technique was operational in Metasploit. Later in September 2016, Capcom pushed the same driver to Street Fighter V's entire installed base as part of an anti-cheat update; 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 often-told version of this story compresses three distinct events into one. Matt Nelson's Let's Be Bad Guys post on 13 September 2016 disclosed the IOCTL number and the function-pointer-execution primitive. OJ Reeves opened the canonical Metasploit pull request, rapid7/metasploit-framework#7363 [@gh-msf-pr-7363], shortly after; the PR was created on 27 September 2016 and merged the following day [@gh-msf-pr-7363]. Satoshi Tanda's tandasat/ExploitCapcom repository was first published in October 2016 and is the canonical standalone PoC, and the artefact this article cites for the IOCTL number and SHA-1 hash.

The driver was properly Authenticode-signed. It chained to a Microsoft-recognised root. It loaded cleanly on every default-configured Windows 7, 8.1, and 10 machine in the world.

That is the puzzle this article 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 article. The catalogue includes Micro-Star's RTCore64.sys (the kernel component of MSI Afterburner), Gigabyte's gdrv.sys, and the KProcessHacker driver shipped with Process Hacker. Section 4 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.

Key idea: Windows in 2026 ships a curated list of Microsoft-signed drivers it refuses to load. Understanding that list is understanding why every previous attempt to make kernel-mode trust mean safety instead of just identity eventually broke.

The current Windows 11 22H2 client honours %windir%\system32\CodeIntegrity\DriverSiPolicy.p7b, a Microsoft-signed deny list enforced by a hypervisor-isolated code-integrity engine sitting in Virtual Trust Level 1. The same engine refuses to map any kernel page that is simultaneously writable and executable. Both behaviours are documented on Microsoft Learn's Memory Integrity page [@ms-hvci-vbs] and the Microsoft-recommended driver block rules page [@ms-driver-block-rules] [@ms-hvci-vbs] [@ms-driver-block-rules]. 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.

2. 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" [@ms-crypto-tools] [@ms-crypto-tools]. 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?

Microsoft's PKCS#7-based code-signing format for Windows binaries. Authenticode attests to the publisher's identity by binding the binary's hash to a certificate chain anchored at a trusted root. It does not analyse the program's behaviour.

For drivers, the user-mode signing primitive was paired with a separate quality program. The Windows Hardware Quality Labs programme, documented today via the Hardware Lab Kit [@ms-hlk], 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 [@ms-hlk]. 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.

Microsoft's compatibility-test programme for third-party drivers. A driver that passes the HLK test suite receives a Microsoft counter-signature and is eligible for OEM and Windows Update distribution. The programme produces a quality signal, not a load-time enforcement decision.

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 [@ms-kmcs-policy] acknowledges by contrast: under advisory policy, the prompt is the policy, and a prompt is exactly as strong as the user clicking past it [@ms-kmcs-policy].

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 [@wp-code-signing] [@wp-code-signing].The Sony BMG XCP rootkit triggered class-action lawsuits, FTC settlements, and an industry-wide reconsideration of what "the user clicked OK" actually authorises. From a kernel-trust perspective, the lesson is narrower: any policy that ends in a dismissible dialog has the same threat model as no policy at all, against an attacker who can show the user a dialog.

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.

3. KMCS: The Vista x64 Revolution (2006-2016)

In November 2006, Vista x64 made a decision that x86 never could: it refused to load any unsigned kernel driver, full stop.

The mechanism was Kernel-Mode Code Signing, or KMCS. The previous-versions Microsoft Learn page on Vista-era driver signing [@learn-microsoft-com-design-dn653567vvs85]) records the policy [@ms-dn653567]. At the point where the I/O manager called IoLoadDriver, the Code Integrity module (ci.dll) intercepted the load, extracted the Authenticode signature embedded in the PE image or attached via a published catalogue, 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.

The Vista-era mandatory load-time signature policy on 64-bit Windows. Before mapping a kernel driver's PE image, the Code Integrity module verifies that the image's Authenticode signature chains to a Microsoft-trusted root. Drivers that fail the check are refused at load time, not at install time.

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) [@ms-cross-cert-archive] -- 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-recognised root [@ms-cross-cert-archive]. The architecture is documented on the cross-certificates for kernel-mode code signing page [@ms-cross-cert], which now opens with a sentence that did not exist in 2006: "Cross-signing is no longer accepted for driver signing" [@ms-cross-cert]. We will come back to that.

sequenceDiagram participant IO as I/O Manager participant CI as Code Integrity (ci.dll) participant CA as Cross-certified CA chain participant Root as Microsoft trusted root

IO->>CI: Map PE for kernel driver
CI->>CI: Extract Authenticode signature (PKCS#7)
CI->>CA: Walk certificate chain
CA->>Root: Anchor at Microsoft cross-cert
alt Chain valid and not revoked
    CI->>IO: Allow section creation
    IO->>IO: Load driver into kernel address space
else Chain invalid or unsigned
    CI->>IO: STATUS_INVALID_IMAGE_HASH
    IO->>IO: Abort load
end

Documented escape hatches

KMCS shipped with three documented bypasses for developers and special cases, all enumerated on the KMCS policy page [@ms-kmcs-policy] [@ms-kmcs-policy]:

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.Microsoft has been formally clear about this since at least 2016: the administrator-to-kernel transition is not a security boundary in the MSRC servicing-criteria sense. Elastic Security Labs writes the position out explicitly in their analysis of vulnerable-driver mitigations [@elastic-admin] [@elastic-admin]. The historical irony is that Vista x64 KMCS was widely read at the time as a defence against admin-level adversaries; it was actually a defence against unprivileged or pre-admin ones.

PatchGuard: the parallel runtime defence

KMCS was a load-time check. The runtime parallel arrived in 2005 with Kernel Patch Protection, informally PatchGuard or KPP, which the Wikipedia entry on Kernel Patch Protection [@wp-kpp] describes as a feature of 64-bit Windows that prevents patching of critical kernel structures [@wp-kpp]. KPP polls a set of integrity-critical kernel objects -- the System Service Descriptor Table, IDT, GDT, certain function prologues -- and triggers a bug check if it detects tampering. 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.

4. Stuxnet, BYOVD, and the Two Things Vista Did Not Fix

On 17 June 2010, researchers in Belarus and Iran identified Stuxnet, a worm targeting supervisory control and data acquisition systems [@wp-stuxnet] used in industrial-control environments [@wp-stuxnet]. 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.Stuxnet is widely reported to have used stolen signing keys from two real semiconductor vendors. The malware-analysis literature is consistent on the pattern; specific cert-holder attributions are reproduced in many places but the primary advisory record we cite here is the Wikipedia Stuxnet article [@wp-stuxnet] and the general framing in the Wikipedia code-signing article [@wp-code-signing] [@wp-stuxnet] [@wp-code-signing]. 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 [@gh-tandasat-capcom] remains the canonical reference, including the SHA-1 of the binary (c1d5cf8c43e7679b782630e93f5e6420ca1749a7) [@gh-tandasat-capcom].

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.

A signed driver means only that someone Microsoft can identify shipped this binary. It does not mean the driver lacks a function-pointer IOCTL.

That observation is the first of three reframes in this article 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.

An attack pattern in which an adversary, having obtained or already holding administrator privileges, installs a signed but design-vulnerable third-party kernel driver and uses its exposed primitives -- arbitrary memory read/write, port I/O, MSR access, or function-pointer dispatch -- to gain ring-zero capability. The signature primitive does not refuse the load because the driver is, on signature alone, legitimate.

The catalogue grows

The BYOVD catalogue 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 [@nvd-cve-2019-16098] is unusually direct: "These signed drivers can also be used to bypass the Microsoft driver-signing policy to deploy malicious code." [@nvd-cve-2019-16098] The driver became a workhorse for ransomware crews. Sophos's October 2022 incident analysis of BlackByte's new variant [@sophos-blackbyte] 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" [@sophos-blackbyte].

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 [@nvd-cve-2018-19320] is on CISA's Known Exploited Vulnerabilities catalogue [@nvd-cve-2018-19320]. The RobinHood ransomware abused it during the 2019 Baltimore municipal-government attack -- a connection widely documented by Sophos and CrowdStrike incident-response teams, though absent from the bare NVD record.

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. CrowdStrike's DoppelPaymer write-up [@cs-doppelpaymer] 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)." [@cs-doppelpaymer]

sequenceDiagram participant Adv as Adversary (admin user mode) participant SCM as Service Control Manager participant CI as Code Integrity (ci.dll) participant Drv as Signed vulnerable driver participant K as Kernel state

Adv->>SCM: Install signed driver as kernel service
SCM->>CI: Request load
CI->>CI: Authenticode check passes
CI->>SCM: Allow
SCM->>Drv: Load into kernel
Adv->>Drv: IOCTL with attacker-supplied pointers
Drv->>K: Write attacker bytes at arbitrary kernel address
K->>K: Clear EDR notify routine / escalate token

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." [@trustedsec-gcioptions] 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. Every commercial-CA cert that was ever issued is still loadable. The policy decision has to move out of the attacker's reach. And the kernel itself has to stop being the thing that decides.

5. Microsoft as the Only Signer (2016-2024)

In August 2016, Microsoft did something the WHQL programme 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 [@ms-kmcs-policy] 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 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 [@ms-kmcs-policy]. 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 programme, documented on Microsoft Learn [@ms-hlk] [@ms-hlk]. 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 [@ms-attestation], did not require an HLK run [@ms-attestation]. 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.

The lower-friction post-2016 Microsoft signing path for Windows kernel drivers. The publisher uploads a CAB to the Hardware Dev Center; Microsoft runs malware scanning and an automated policy check; on pass, Microsoft applies its counter-signature. The path replaces full HLK testing for client-only drivers.

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." [@ms-vdrc-blog]

flowchart LR A[Publisher EV cert + driver CAB] --> B[Hardware Dev Center upload] B --> C[Malware scan] C --> D{HLK required?} D -- "Yes" --> E[HLK compatibility test pass] D -- "No" --> F[Attestation policy check] E --> G[Microsoft counter-sign] F --> G G --> H[Optional Windows Update distribution]

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.

The KMCS policy page [@ms-kmcs-policy] is candid about the carve-outs: "Cross-signed drivers are still permitted if any of the following are true: The PC was upgraded from an earlier release of Windows to Windows 10, version 1607. Secure Boot is off in the BIOS. Drivers was signed with an end-entity certificate issued prior to July 29th 2015 that chains to a supported cross-signed CA." [@ms-kmcs-policy]

Operationally, every signed-but-vulnerable driver from the 2006-2015 era remains loadable on a meaningful population of Windows machines: upgraded installs, devices with Secure Boot disabled in firmware, and drivers with pre-cutoff end-entity certs whose chains are still valid. Capcom.sys, RTCore64.sys, gdrv.sys, KProcessHacker -- the entire 2010s BYOVD catalogue -- continues to chain to roots Windows still accepts.

What attestation signing catches and what it does not

The malware scan inside attestation signing looks for known dangerous behaviour. 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." [@ms-vdrc-blog] 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 -- gives the attacker the Microsoft-only-signing flavour of the Stuxnet problem. The signed-by-Microsoft chain is exactly as strong as the EV key's safekeeping at the publisher.

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.

6. 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 virtualisation layer that exists on every modern Windows installation that meets the hardware requirements. Hypervisor-protected 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 [@ms-hvci-vbs] is the canonical primary source [@ms-hvci-vbs]. TrustedSec called out the conflation explicitly in their g_CiOptions in a virtualized world post [@trustedsec-gcioptions] [@trustedsec-gcioptions].

Key idea: A security check that shares a trust domain with what it is checking has, by definition, already lost. HVCI moves the check out of the attacker's trust domain. It is the answer to who decides. It is not the answer to what gets decided.

That sentence is the second of this article'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 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 VBS abstraction that partitions a Windows installation into two execution environments. VTL0 is the normal Windows kernel and its drivers. VTL1 is a much smaller Secure Kernel and a curated set of "trustlets" -- isolated user-mode processes that hold the most sensitive secrets. VTL1 can read and write VTL0 memory; VTL0 cannot read or write VTL1 memory. Code-integrity policy lives in VTL1.

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.

flowchart TD subgraph VTL1 [VTL1 -- Secure Kernel] SK[Secure Kernel] SKCI[SKCI -- Code Integrity] Policy["Code Integrity policy
(DriverSiPolicy.p7b)"] SK --> SKCI SKCI --> Policy end subgraph VTL0 [VTL0 -- Normal Windows] Kern[NT Kernel] Drv[Driver attempting load] CI[ci.dll user-side] Kern --> CI CI --> Drv end Hypervisor{"Hyper-V SLAT"} Kern -->|"Section create"| Hypervisor Hypervisor -->|"Forward"| SKCI SKCI -->|"Allow or deny"| Hypervisor Hypervisor -->|"Result"| Kern

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 IoLoadDriver entry point a load goes through later [@ms-hvci-vbs]. 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 [@ms-hvci-vbs] 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." [@ms-hvci-vbs]Mode-Based Execute Control (MBEC) is the Intel feature that lets the hypervisor distinguish "executable in supervisor mode" from "executable in user mode" at the page-table-entry level. AMD's Guest Mode Execute Trap (GMET) is the structurally equivalent feature. Older silicon falls back to Restricted User Mode emulation, which works correctly but pays a meaningfully larger performance tax. The hardware cutoff is a major reason HVCI defaulted off on pre-2017 OEM hardware for years.

What HVCI fixed

The g_CiOptions patching family, the third bypass we met in section 4, closes on HVCI-on systems. TrustedSec's post [@trustedsec-gcioptions] 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 [@trustedsec-gcioptions]. 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 analyse the driver's behaviour. The 2019 RTCore64.sys driver passes SKCI section-mapping unchanged: it is signed by MSI through a Microsoft-recognised 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.

Note: The Memory Integrity page [@ms-hvci-vbs] is explicit that "some applications and hardware device drivers may be incompatible with memory integrity. This incompatibility can cause devices or software to malfunction and in rare cases may result in a boot failure (blue screen)." [@ms-hvci-vbs] For years OEM and gaming-system vendors shipped with HVCI off because legacy ISV drivers, anti-cheat kernel components, or older virtualisation tools could not coexist with it. On an HVCI-off system the g_CiOptions patching family is back in play, the kernel-CI engine and the kernel it polices are in the same trust domain, and the analysis of section 4 applies unchanged. The 2026 default-on baseline is real, but it is not yet universal.

HVCI is the answer to who decides. It is not the answer to what gets decided. We still need a way to say: this specific signed binary is one we do not trust.

7. The Block List: Naming the Weakness (2020-present)

In October 2020, Microsoft started shipping something it had spent twenty-five years avoiding: a list of specific drivers it would refuse to load by name.

The artefact 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 [@ms-driver-block-rules] is the primary source, and is unusually rich for a Microsoft Learn page [@ms-driver-block-rules].

Microsoft's policy-driven application-control engine. An App Control policy is a signed XML or binary file that lists allow rules, deny rules, and signer-level rules; at load time, the policy engine consults the rules and either allows or refuses the image. `DriverSiPolicy.p7b` is itself an App Control policy whose body is all deny rules.

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 [@ms-driver-block-rules] on a quarterly schedule and pushes the binary DriverSiPolicy.p7b to client devices through monthly Windows servicing [@ms-driver-block-rules]. Microsoft's Security Baselines team also publishes a running update post [@ms-tc-blocklist-baselines] cataloguing the changes [@ms-tc-blocklist-baselines].

The candid admission on the block-rules page [@ms-driver-block-rules] is the part of the story that is most worth understanding.

The blocklist included in this article and in the associated downloadable files usually contains a more complete set of known vulnerable drivers than the version in the OS and delivered by Windows Update. It's often necessary for us to hold back some blocks to avoid breaking existing functionality. -- Microsoft Learn, *Microsoft-recommended driver block rules* [@ms-driver-block-rules]

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 section 9.

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-protected Code Integrity, Smart App Control, or Windows in S-mode [@ms-kb5020779] [@ms-kb5020779]. With the Windows 11 2022 Update, also known as 22H2 [@ms-blogs-win11-2022], released on 20 September 2022, default-on coverage extended to every client device, not just the HVCI-on subset [@ms-blogs-win11-2022]. The 22H2 release is the moment the block list became universal Windows client behaviour, six years after the first BYOVD primitive that motivated it.

The block-rules page [@ms-driver-block-rules] notes a single explicit carve-out worth flagging."Except on Windows Server 2016, the vulnerable driver blocklist is also enforced when either memory integrity (also known as hypervisor-protected code integrity or HVCI), Smart App Control, or S mode is active." [@ms-driver-block-rules] Windows Server 2016 does not get the default-on block list even when HVCI is on. An enterprise admin managing Server 2016 has to deploy an explicit App Control policy to get the same coverage. The October 2022 preview cycle saw a documented quirk -- KB5020779 [@ms-kb5020779] explains that a preview release shipped without an actual blocklist refresh, addressed by a subsequent servicing update [@ms-kb5020779].The KB5020779 episode is a useful reminder that the in-box block list ships through the same Windows Update cycle as everything else. Preview releases do not always carry a fresh policy, and the cadence on the block-rules page [@ms-driver-block-rules] describes the intended steady state rather than every individual update [@ms-driver-block-rules].

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; only with both in place could DriverSiPolicy.p7b actually do its job.

flowchart TD A[Driver image requested for load] --> B[Hypervisor mediates section create] B --> C[SKCI verifies Authenticode chain] C --> D{"Chain OK?"} D -- "No" --> X[Refuse] D -- "Yes" --> E[Consult DriverSiPolicy.p7b deny rules] E --> F{"Hash, name, or signer on deny list?"} F -- "Yes" --> X F -- "No" --> G[Allow section creation] G --> H[Driver maps into kernel address space]

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 [@ms-vdrc-blog] 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." [@ms-vdrc-blog] The post explicitly lists the historical CVE backdrop that motivated the centre, 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 [@ms-vdrc-blog].

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 centre 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 [@ms-asr-rules] include "Block abuse of exploited vulnerable signed drivers" (56a863a9-875e-4185-98a7-b882c64b5ce5) as part of the standard ASR protection set [@ms-asr-rules]. 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 [@ms-vdrc-blog]. 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 catalogue of vulnerable Windows drivers. The community-maintained LOLDrivers project [@loldrivers-io] -- "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 [@gh-loldrivers] [@loldrivers-io]. As of the source verification for this article, 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 [@cpr-byovd]: a public catalogue 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." [@cpr-byovd] Defenders use the list for hardening; attackers use it for shopping. Both effects are real.

Note: Defenders who can tolerate compatibility risk can compile the source XML from the block-rules page [@ms-driver-block-rules] into an App Control policy and deploy it directly, picking up the entries Microsoft holds back from the in-box list. Optionally layer the LOLDrivers App Control policy [@gh-loldrivers] on top for community-curated coverage. Test in audit mode first -- both lists are more aggressive than the shipped baseline and may flag drivers your environment depends on [@ms-driver-block-rules] [@gh-loldrivers].

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.

{` // Simplified model of the App Control / WDAC rule-evaluation engine. // Deny rules win, allow rules permit the remainder, and an explicit // default action handles images neither denied nor allowed.

const policy = { denyByHash: new Set(["c1d5cf8c43e7679b782630e93f5e6420ca1749a7"]), // Capcom.sys denyByName: new Set(["RTCore64.sys"]), denyBySigner: new Set(["CN=Some Compromised Publisher, O=Example"]), allowBySigner: new Set(["CN=Microsoft Windows, O=Microsoft Corporation"]), defaultAction: "BLOCK", };

function evaluate(image, policy) { if (policy.denyByHash.has(image.sha1)) return "BLOCK (hash on deny list)"; if (policy.denyByName.has(image.fileName)) return "BLOCK (name on deny list)"; if (policy.denyBySigner.has(image.signer)) return "BLOCK (signer on deny list)"; if (policy.allowBySigner.has(image.signer)) return "ALLOW (signer on allow list)"; return policy.defaultAction === "ALLOW" ? "ALLOW (default)" : "BLOCK (default)"; }

const cases = [ { sha1: "c1d5cf8c43e7679b782630e93f5e6420ca1749a7", fileName: "Capcom.sys", signer: "CN=CAPCOM Co., Ltd." }, { sha1: "0000000000000000000000000000000000000000", fileName: "RTCore64.sys", signer: "CN=Micro-Star International Co., Ltd." }, { sha1: "1111111111111111111111111111111111111111", fileName: "ntfs.sys", signer: "CN=Microsoft Windows, O=Microsoft Corporation" }, ]; for (const c of cases) console.log(c.fileName, "->", evaluate(c, policy)); `}

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?

8. The 2026 Stack: Defence in Depth Made Concrete

On a default-configured Windows 11 22H2 machine in 2026, a kernel driver that tries to load passes through five distinct gates. Each one closes a blind spot the previous one cannot reach.

The order matters, and so do the dependencies. The gates are:

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 [@ms-kmcs-policy] [@ms-kmcs-policy].
The Vulnerable Driver Block List. SKCI consults DriverSiPolicy.p7b for hash, file-name, and signer-level deny rules. The list is default-on for every client device since Windows 11 22H2 [@ms-blogs-win11-2022], and is updated quarterly through Microsoft Learn's published source XML and monthly through Windows servicing [@ms-driver-block-rules] [@ms-blogs-win11-2022].
HVCI / SKCI. The Code Integrity engine runs in VTL1, verifies signatures at section-mapping time rather than only at IoLoadDriver, and enforces W^X on kernel memory. The policy engine is structurally out of reach of a fully compromised VTL0 kernel [@ms-hvci-vbs].
App Control / Smart App Control. Enterprise admins author explicit App Control allowlists; consumer devices on clean Windows 11 installs run Smart App Control [@ms-sac-faq], a Microsoft-authored allowlist policy backed by cloud reputation [@ms-sac-faq] [@ms-appcontrol].
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 [@ms-asr-rules].

The Windows 11 22H2+ consumer-facing front end for App Control for Business. SAC enforces a Microsoft-authored policy and supplements it with cloud reputation lookups from the Intelligent Security Graph. SAC is only available on clean installs and is shipped in evaluation mode by default; once turned on, it also unconditionally enforces the vulnerable driver block list [@ms-sac-faq]. The cloud-backed reputation service that Smart App Control consults to predict whether a given binary is safe. When confident, ISG approves the binary; when unconfident, SAC falls back to signature checks; absent both, the binary is blocked [@ms-sac-faq].

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.

Gate	Catches	Misses
KMCS	Unsigned and cross-cert-only-signed drivers	Signed-but-vulnerable drivers
Block list	Known-vulnerable signed drivers (post-disclosure)	Unknown-vulnerable signed drivers
HVCI / SKCI	`g_CiOptions`-patching from VTL0; writable+executable kernel pages	Behavioural BYOVD inside a properly-signed driver
WDAC / SAC	Anything not on the allowlist (enterprise) or unknown-reputation (consumer)	Allowlisted drivers with unknown defects
Defender ASR	Block-list entries on HVCI-off machines (where the rule is enabled)	Drivers not on Microsoft's blocklist

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 section 9 explains why they cannot.

Smart App Control's particulars

SAC merits a few specifics because its behaviour 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 behaviour, 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 [@ms-sac-faq] made SAC re-enableable from Windows Security, turning SAC off used to require a clean install to bring it back [@ms-sac-faq]. Fourth, on enterprise-managed devices, SAC turns itself off automatically after 48 hours; managed environments are expected to deploy WDAC instead [@ms-appcontrol].

The cold-start failure mode is worth knowing. A small independent hardware vendor whose driver has never been seen at scale lacks a cloud reputation when SAC asks about it. The fallback is signature, but a signed driver from an unknown publisher does not always clear SAC's confidence threshold. Small IHVs occasionally find their drivers blocked on consumer hardware running SAC for that reason alone.

flowchart TD A[Driver image requested] --> B[Gate 1: KMCS Authenticode chain] B --> C{"Microsoft-rooted?"} C -- "No" --> X[Refuse] C -- "Yes" --> D[Gate 2: DriverSiPolicy.p7b] D --> E{"On block list?"} E -- "Yes" --> X E -- "No" --> F[Gate 3: HVCI / SKCI section mapping] F --> G{"Signature OK, W^X satisfied?"} G -- "No" --> X G -- "Yes" --> H[Gate 4: App Control / SAC] H --> I{"On allowlist or reputable?"} I -- "No" --> X I -- "Yes" --> J[Gate 5: Defender ASR rule applicable] J --> K[Driver loads into VTL0 kernel]

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.

Two commands answer most of the question. From an elevated PowerShell prompt, `Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard` returns a structure whose `SecurityServicesRunning` array enumerates the services in operation; a value of **1** indicates **Credential Guard**, a value of **2** indicates **HVCI / Memory Integrity**, and additional values cover newer services (System Guard Secure Launch, SMM Firmware Measurement, Kernel-mode Hardware-enforced Stack Protection, and Hypervisor-Enforced Paging Translation) [@ms-hvci-vbs]. `bcdedit /enum {default}` shows whether `hypervisorlaunchtype` is set to `Auto`, the prerequisite for VBS being on at all. The block list file itself lives at `%windir%\system32\CodeIntegrity\DriverSiPolicy.p7b`; if it is missing, the in-box list is not deployed on that machine. None of these tell you whether your Defender ASR rule is active without a separate `Get-MpPreference` check.

A toy decoder helps make the WMI surface concrete.

{` // Mirror of the integer codes the Win32_DeviceGuard WMI class reports // for SecurityServicesRunning. Documented on Microsoft Learn under // the Memory Integrity / HVCI guidance.

const SERVICE_NAMES = { 1: "Credential Guard", 2: "Hypervisor-protected Code Integrity (HVCI / Memory Integrity)", 3: "System Guard Secure Launch", 4: "SMM Firmware Measurement", 5: "Kernel-mode Hardware-enforced Stack Protection", 6: "Kernel-mode Hardware-enforced Stack Protection (Audit mode)", 7: "Hypervisor-Enforced Paging Translation", };

function explain(servicesRunning) { if (!servicesRunning.length) { return "No VBS-rooted security services are running on this device."; } return servicesRunning .map((code) => SERVICE_NAMES[code] || ("unknown service " + code)) .map((s) => " - " + s) .join("\n"); }

console.log("Sample 1: HVCI on, Credential Guard on"); console.log(explain([1, 2])); console.log("\nSample 2: nothing running"); console.log(explain([])); console.log("\nSample 3: full stack on a Secured-core PC"); console.log(explain([1, 2, 3, 4, 5])); `}

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.

9. 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 article 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. 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 all kernel drivers 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}$. 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 analysers will catch more of the not-obvious cases; but the unrestricted version of the problem has no complete solution.

Key idea: Whether an arbitrary signed driver can be coerced into giving an attacker a kernel-write primitive is undecidable. No static signing scheme can ever block exactly the unsafe drivers. The Windows answer is therefore not a single perfect gate; it is defence in depth that narrows, but does not close, the gap.

Microsoft's formal acknowledgement

Microsoft has been formally clear about a related point for years: the administrator-to-kernel transition is not, in the MSRC servicing-criteria [@elastic-admin] sense, a security boundary [@elastic-admin]. Elastic Security Labs put the position 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." [@elastic-admin]

Administrator-to-kernel is not a security boundary, in the MSRC servicing-criteria sense. The defence-in-depth mechanisms described here mitigate it; from the impossibility result, none can close it.

The MSRC framing is engineering policy. 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 defence-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." [@ms-driver-block-rules]The published-vs-shipped gap is the closeable part. An administrator who can author or import an App Control policy can deploy the published XML directly and pick up Microsoft's full curation. The irreducible part of the gap sits behind it: even the published list lists only what someone has already disclosed. The undecidability result applies to finding unsafe drivers, not to listing known-unsafe ones. Defenders willing to accept compatibility risk can close it on their own machines today.

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. The complexity bounds for each layer are well-defined.

Authenticode signature verification is bounded below by one public-key operation and one cryptographic hash over the PE image, regardless of policy. SKCI's per-section cost is dominated by that constant. The Memory Integrity page is conspicuously silent on a published benchmark number; in practice the overhead is small but non-zero on Intel Kabylake-and-later or AMD Zen-2-and-later silicon with MBEC/GMET hardware acceleration, and meaningfully higher on the emulated Restricted-User-Mode fallback path that older silicon falls back to [@ms-hvci-vbs].

WDAC allowlist evaluation is $O(\log r)$ per image on $r$ rules with a hashed index, or $O(r)$ on the naïve linear scan; the deny-rule check in DriverSiPolicy.p7b follows the same bound.

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 months today. Forthcoming WHCP submission-time analyses can compress it.
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. Section 11 returns to the SBOM axis specifically because it is the one Microsoft is building into the submission flow right now.

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 is being built now.

10. 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 [@docs-kernel-module-sig] catalogues 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." [@docs-kernel-module-sig] 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." [@docs-kernel-module-sig]

Most mainstream distributions ship permissive: unsigned modules taint the kernel but load. The defender-shipping-restrictive-enforcement model is real on Secure-Boot-on RHEL and modern Ubuntu, paired with the Linux lockdown security module, which restricts certain root-level kernel-modification paths even on signed builds.The Linux lockdown LSM is the closest mainline-Linux analogue to HVCI's policy-out-of-reach property. The kernel_lockdown(7) man page [@man7-kernel-lockdown] describes lockdown as "designed to prevent both direct and indirect access to a running kernel image" and enumerates the restricted surfaces: /dev/mem, /dev/kmem, /dev/kcore, kprobes, BPF, MSR alteration, ACPI table overrides, and unsigned kexec [@man7-kernel-lockdown]. It is a partial analogue, not equivalent: lockdown still runs in the same trust domain as the kernel it polices, so a sufficient kernel exploit defeats it. HVCI's VTL0/VTL1 split is structurally stronger.

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 [@apple-legacy-extensions] in 2019, Apple deprecated legacy kernel extensions for third parties and pushed them onto the DriverKit [@apple-driverkit] framework instead [@apple-legacy-extensions] [@apple-driverkit].

Apple's user-space driver framework, introduced with macOS Catalina 10.15. Third-party drivers ship as `.dext` user-space extensions linked against a curated IOKit subset; they receive IOKit messages from the kernel and respond with the same operations they used to perform in ring zero, but the code itself runs in user mode under sandbox restrictions. The kernel side of the new model exposes a controlled message surface; the third-party side cannot directly execute kernel code.

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 [@apple-sip] (since 2015) and, on Apple Silicon, Kernel Integrity Protection (KIP), which makes the kernel page tables read-only after boot [@apple-sip].

The price was paid by Apple's IHV community. Whole categories of third-party drivers -- deep audio, virtualisation, 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 [@apple-kext-aux] 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" [@apple-kext-aux].

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.

Dimension	Windows (2026)	Linux (mainline + RHEL-class hardening)	macOS (Catalina+ / Apple Silicon)
Default signature enforcement	Mandatory on x64 since 2006	Permissive (taints kernel); restrictive on hardened distros	Mandatory; legacy kexts deprecated
Curated denylist of signed-but-vulnerable artefacts	`DriverSiPolicy.p7b`, default-on since 22H2	None at kernel loader; per-distro CVE trackers	Not needed -- third-party kexts removed
Policy engine isolated from kernel it polices	HVCI in VTL1	Lockdown LSM (same trust domain)	KIP and SIP on Apple Silicon
Third-party drivers in kernel	Yes, still the model	Yes	No -- DriverKit user-space dexts
Operational price of the model	Compatibility carve-outs, opt-outs	Permissive default	Multi-year IHV migration

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.

11. 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 artefact. 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 [@gh-sbom-tool], that produces SPDX-compatible SBOMs as part of a build pipeline [@gh-sbom-tool]. 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." [@gh-sbom-tool]

A machine-readable inventory of components and dependencies inside a software artefact. For a Windows kernel driver, an SBOM lists the third-party static libraries linked into the PE, the open-source code paths bundled with the driver, and the versions of each, in a format (SPDX, CycloneDX) that automated tools can consume to answer "is any component of this driver subject to a known vulnerability?"

The piece that affects Windows drivers specifically is the Windows Hardware Compatibility Program SBOM requirement. The Microsoft Q&A entry on Hardware Dev Center and CRA compliance [@ms-qa-cra] is candid: "The WHCP SBOM requirement (Device.DevFund.Security.SoftwareBillofMaterials) has been deferred and will only be enforced starting in H2 2026." [@ms-qa-cra] The deferral aligns the WHCP rollout with the European Union's Cyber Resilience Act compliance window.

The EU Cyber Resilience Act sets phased compliance obligations for products with digital elements sold into the EU market. Among them is a requirement to produce a machine-readable SBOM that customers and regulators can inspect. Microsoft's WHCP SBOM mandate, scheduled for H2 2026, is the Windows-specific implementation of the same requirement, applied to kernel drivers submitted through the Hardware Dev Center. For regulated-industry IHVs, the WHCP gate and the CRA gate land at the same time and concern the same artefact [@ms-qa-cra].

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. The WHCP submission flow is expected to bind the SBOM cryptographically to the artefact it describes so that a recipient can verify the binding, but the public documentation for the binding mechanism is still light beyond the WHCP SBOM mandate itself [@ms-qa-cra] [@ms-qa-cra].

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 programmes show how dynamic analysis at scale can compress it.

The first is the EURECOM/Politecnico di Milano NDSS 2026 paper on the authors' publication page [@eurecom-paper]. The team built a DRAKVUF-based instrumentation layer called Kernelmon and traced every kernel function executed by signed drivers under malware-loaded workloads [@eurecom-paper]. The numbers are unusually concrete: the paper PDF [@eurecom-paper-pdf] 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" [@eurecom-paper-pdf]. The companion S3 blog post [@eurecom-s3-blog] corroborates the 48-flagged / 7-disclosed numbers and notes that one of the seven received CVE-2024-26506 [@eurecom-s3-blog]. 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 [@cpr-byovd], 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." [@cpr-byovd] 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 defences have to recognise

Cisco Talos's BYOVD work, summarised in their Exploring vulnerable Windows drivers post [@talos-byovd], classifies the post-load payloads attackers actually run [@talos-byovd]. Three behaviour 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)." [@ms-vdrc-blog] The payload classes have stayed remarkably stable for fifteen years.

Note: The structural gap between signed and safe cannot close. It can be narrowed along three independent axes. Reactiveness: how long disclosure-to-enforcement takes (closeable by submission-time dynamic analysis along the lines of the EURECOM NDSS 2026 paper [@eurecom-paper] [@eurecom-paper] and Check Point's mass-hunt methodology [@cpr-byovd] [@cpr-byovd]). Coverage of unknown-bad signed drivers (extended by reputation-backed allowlists like Smart App Control and by WDAC enterprise policies). Visibility into binary contents (the H2 2026 WHCP SBOM mandate [@ms-qa-cra] and the SBOM-to-artefact binding the submission flow is expected to enforce [@ms-qa-cra]). Each axis closes a different blind spot. None substitutes for another.

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 drivers have no cloud reputation to fall through to signature, and signature alone is exactly what we already established does not answer the 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. And the next one is already being written into the WHCP submission flow.

12. 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. A DriverSiPolicy.p7b in %windir%\system32\CodeIntegrity\ confirms the in-box block list is deployed. If you can tolerate the compatibility risk, compile the published block-rules XML [@ms-driver-block-rules] into an App Control policy and deploy it (audit mode first) [@ms-driver-block-rules]. If you run Windows Server 2016, you have to deploy an explicit policy yourself because the in-box default does not apply there [@ms-driver-block-rules]. If you ship through the Hardware Dev Center, schedule the H2 2026 WHCP SBOM gate now [@ms-qa-cra]. Subscribe to the Vulnerable & Malicious Driver Reporting Center cadence for new disclosures [@ms-vdrc-blog].

Driver authors. Assume your IOCTL surface will be read by Check Point's import-table mass hunt [@cpr-byovd] and exercised by EURECOM's Kernelmon [@eurecom-paper] [@cpr-byovd] [@eurecom-paper]. Any handler that takes a user-supplied address and returns kernel data, or that dispatches a user-supplied function pointer, will end up on a block list on its current trajectory.

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.

Note: Windows 11 22H2 ships with a list of drivers Microsoft will not load. The next list will be longer. The story has been adversarial since 1996 and the trajectory does not reverse: every layer was added because the previous one met an attacker. The structural gap is undecidable; the engineering gap, narrowable; the work, unfinished.

Frequently Asked Questions

No. HVCI verifies the Authenticode signature at section-mapping time and enforces a write-xor-execute invariant on kernel memory; it does not analyse the driver's IOCTL surface. A signed driver with an unsafe IOCTL passes HVCI unchanged and proceeds to execute its handler in kernel mode with kernel privilege. That is what the Vulnerable Driver Block List is for: HVCI gates *who decides*; the block list gates *what gets decided*. See the Memory Integrity page [@ms-hvci-vbs] [@ms-hvci-vbs]. Yes. Microsoft publishes the source XML on the Microsoft-recommended driver block rules page [@ms-driver-block-rules] [@ms-driver-block-rules]. You can compile it into a binary App Control policy with the standard tooling and deploy it directly, picking up entries Microsoft holds back from the in-box list. Test in audit mode first because the published list is more inclusive than the shipped list and may flag drivers your environment depends on. Many defenders layer the LOLDrivers App Control policy [@gh-loldrivers] on top for community-curated coverage [@gh-loldrivers]. Windows Server 2016 does not enforce the block list by default, even when Memory Integrity is on. The block-rules page [@ms-driver-block-rules] calls this out explicitly [@ms-driver-block-rules]. If you administer Server 2016, deploy an explicit App Control policy to get the same coverage as the default-on 22H2 client. App Control for Business (the engine formerly known as WDAC) is a policy *you* author. You define what signers, hashes, and paths are allowed; you ship and enforce the policy yourself. Smart App Control is a Microsoft-authored policy bundled with cloud reputation lookups via the Intelligent Security Graph. SAC is the consumer-friendly front end; App Control is the enterprise back end. SAC's default policy ships at `%windir%\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml`. SAC is consumer-only and turns itself off after 48 hours on enterprise-managed devices, where the expectation is that the operator deploys an App Control policy directly. See the Smart App Control FAQ [@ms-sac-faq] and the App Control for Business overview [@ms-appcontrol] [@ms-sac-faq] [@ms-appcontrol]. Increasingly yes. Major anti-cheat vendors have shipped HVCI-compatible kernel components since around 2023, but a meaningful tail of older configurations still requires HVCI off. On those configurations, the `g_CiOptions`-patching technique TrustedSec describes [@trustedsec-gcioptions] is back in play because the policy variable is no longer protected behind VTL1 [@trustedsec-gcioptions]. Audit your gaming-rig population if you care about coverage. The in-box block list is Microsoft-curated with explicit compatibility holdbacks; the LOLDrivers catalogue [@loldrivers-io] is community-curated, considerably more inclusive (approximately 2,132 entries as of the source verification for this article), and ships with App Control deny policies, Sigma, YARA, ClamAV, and Sysmon detection content alongside the entries [@loldrivers-io] [@gh-loldrivers]. For threat hunting, use both. For enforcement, layer the LOLDrivers App Control policy on top of the in-box list if your environment can tolerate the compatibility risk. Check Point Research [@cpr-byovd] has documented the dual-use externality of any such public list -- attackers also read them -- but the defender net benefit of broader coverage outweighs the marginal attacker advantage on most environments [@cpr-byovd].

From /hotpatch to \$1.50 a Core: The Live-Patch Pipeline Microsoft Built and Then Made Public

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

**Windows hot patching is a three-layer pipeline, not a feature.** A kernel mechanism rewrites a process's `.text` in place, directed by HPAT metadata baked into every patchable PE and brokered by the Secure Kernel. A servicing model ships one Cumulative Update per quarter and two hot-patch-only months between baselines. A management plane (Azure Update Manager, Intune Autopatch, or Azure Arc) selects eligible fleets and falls back to the regular reboot path for everything else.

The mechanism has been running on the Azure host fleet for years [@ms-techcommunity-hotpatch-nov2021] before Microsoft turned it into a product. The public products arrived in three waves: Windows Server 2022 Datacenter: Azure Edition [@techcommunity-server2022-ga-feb2022] (February 16, 2022, free on Azure), Windows 11 Enterprise 24H2 [@ms-techcommunity-hotpatch-client-apr2025] (April 2, 2025, license-gated via Intune Autopatch), and Windows Server 2025 outside Azure [@ms-blog-server2025-hotpatch] (July 1, 2025, $1.50 USD per CPU core per month over Azure Arc). The architectural innovation -- the part that separates the modern design from Microsoft's failed 2003 attempt and from Linux's ftrace-based livepatch -- is the trust anchor. The Secure Kernel verifies signed patch payloads and performs the rewrite under HVCI. Static-data-layout changes still force a reboot, and they always will. That is not an engineering shortcoming. It is a corollary of Rice's theorem.

1. The hook: a $1.50-per-core-per-month reboot bill

Microsoft's Visual C++ compiler ships a /hotpatch switch. The flag is small, almost forgettable: when set, the compiler guarantees that the first instruction of every function is at least two bytes long and that no jump within the function targets the prologue [@ms-cpp-hotpatch]. Those two bytes are the enabling primitive for everything that follows in this article. They are the place where a running operating system can be quietly amended without being stopped.

On July 1, 2025, Microsoft began charging $1.50 USD per CPU core per month for the right to use that primitive on Windows Server 2025 outside Azure [@ms-blog-server2025-hotpatch]. The 26 years in between are the subject of this article.

The replacement of executable code inside a running process or kernel without first stopping the program. Microsoft uses the term as an umbrella for the *mechanism* (in-memory binary rewriting), the *delivery pipeline* (signed payloads, servicing cadence), and the *operational plane* (which fleets are eligible and how rollout is staged). Linux uses *livepatch* (in-tree) and *kpatch* / *kGraft* / *Ksplice* (out-of-tree or vendor) for closely related but mechanically distinct primitives. The shared goal is to apply security fixes without paying the downtime cost of a reboot.

The shock of a metered subscription on a 30-year-old compiler feature is the question this article exists to answer. Three current Windows hot-patch products run on top of a single internal engineering pipeline:

Windows Server 2022 Datacenter: Azure Edition, GA on February 16, 2022, free for Azure VMs [@techcommunity-server2022-ga-feb2022]. The first public surface of the modern pipeline.
Windows 11 Enterprise 24H2 client, GA on April 2, 2025 [@ms-techcommunity-hotpatch-client-apr2025], license-gated through Intune Autopatch.
Windows Server 2025, GA on July 1, 2025 over Azure Arc at $1.50 USD per CPU core per month [@ms-blog-server2025-hotpatch] for on-premises and multi-cloud machines, with the reboot frequency reduced from 12 times a year to 4 [@ms-blog-server2025-hotpatch].

Hotpatching is an impact-less update technology which has been keeping the Azure fleet up-to-date for years with zero impact on customer workloads. -- Microsoft's Windows OS Platform team, November 2021 [@ms-techcommunity-hotpatch-nov2021]

That single sentence is the load-bearing claim. The customer-facing product launched in February 2022 was not a research result. It was the externalization of an internal pipeline that had been quietly servicing Azure for years. The 2022, 2025, and 2025 GA dates are the points at which Microsoft turned the same engineering machine outward, one customer surface at a time.

At Build 2025, Mark Russinovich presented hot patching alongside two other Azure availability primitives [@ms-research-build2025-russinovich]: VMPHU (Virtual Machine Preserving Host Update), which patches the host while preserving running guests through the host reboot, and Kernel Soft Reboot, which is a fast in-place kernel transition that skips firmware. These are not the same thing. VMPHU is host-side. Kernel Soft Reboot still costs a kernel transition. Hot patching is the only one that rewrites code in flight on the running guest. Conflating the three is the second-most-common mistake in this space.

So the question. Microsoft did not invent in-memory function replacement on Windows in 2022. Microsoft shipped it in 2003. Why did it take 17 years to come back? The answer threads through a failed first attempt, a state-aligned APT, the entire Linux live-patching family tree, and an architectural change that did not exist when the original mechanism was designed. The compiler flag does not change. Everything around it does.

2. The 2003 original: Server 2003 SP1 hotpatching and why it mattered

In May 2011, a German systems engineer named Johannes Passing sat down with a Server 2003 kernel and a debugger and reverse-engineered, function by function, how an MS06-030 hot patch landed in memory. His walkthrough [@jpassing-hotpatching] is one of the cleanest contemporaneous records of a Microsoft feature that nearly nobody used. The trace looks like this, copied verbatim from his debugger session:

nt!MmLoadSystemImage
nt!MmHotPatchRoutine+0x59
nt!ExApplyCodePatch+0x191
nt!NtSetSystemInformation+0xa1e

NtSetSystemInformation, with the magic class SystemHotpatchInformation, dispatched into ExApplyCodePatch, which called MmHotPatchRoutine, which finally called MiPerformHotPatch to walk the patch image's metadata and rewrite the target driver's instructions. The example Passing followed targeted mrxsmb.sys and rdbss.sys for the SMB bug that MS06-030 fixed. The patch worked. It worked in production. And almost nobody ever shipped one.

The enabling primitive is the compiler flag from §1. The MSVC documentation states the contract: when /hotpatch is used at compile time, every function begins with an at-least-two-byte first instruction with no internal jumps to it [@ms-cpp-hotpatch]. The x86 convention that fell out of this was the famous mov edi, edi instruction at the start of every Windows function [@oldnewthing-mov-edi-edi] -- a 2-byte NOP-equivalent that, per Raymond Chen's verbatim Microsoft DevBlogs description, can be replaced with a two-byte JMP $-5 instruction to redirect control to five bytes of patch space that comes immediately before the start of the function [@oldnewthing-mov-edi-edi] without ever being read in a half-modified state.The mov edi, edi instruction is itself an artifact. On x86 it is the compiler's chosen 2-byte placeholder; on x64 and Arm64 the compiler guarantees the hotpatchable prologue without an explicit placeholder instruction [@ms-cpp-hotpatch], because those architectures' calling conventions and alignment requirements give the linker more freedom. The fossil-like sequence survives in x86 code today as a quiet reminder that every Windows function used to be hotpatchable by construction.

The 2003 design paired this prologue convention with a payload format and a delivery syscall. The OpenRCE community published the format details in 2006 [@openrce-patching-internals]: the hot-patch image was a normal PE module with a section called .hotp1, at least 80 bytes long, beginning with a HOTPATCH_HEADER followed by a relocation-and-replacement table. On kernel-mode targets, MmHotPatchRoutine walked the headers and rewrote the live .text. On user-mode targets, an updating agent enumerated the running processes and injected a remote thread into each one [@openrce-patching-internals] to perform the equivalent rewrite. The mechanism shipped in Server 2003 SP1 and was available on XP SP2 across x86, IA-64, and x64.Primary sources disagree on the service-pack attribution: the OpenRCE 2006 writeup [@openrce-patching-internals] labels availability as "Server 2003 SP0, XP SP2 x86, ia64, x64," while Johannes Passing's 2011 walkthrough [@jpassing-hotpatching] and Microsoft's 2016 MMPC blog both say "Server 2003 SP1." The article picks the Microsoft-leaning side; the OpenRCE attribution remains in tension.

It also never really shipped. The Server 2003 hotpatch engine was a credible developer feature that did not become an operational habit. A handful of advisories ever produced a .hotp1 payload; the feature was quietly retired by Windows 8. Why? Three structural reasons -- and a fourth that did not become visible until 2016.

Microsoft's pre-cumulative-update servicing model split each Windows binary into two parallel build streams: GDR (General Distribution Release), which carried only the security fixes shipped publicly, and QFE (Quick Fix Engineering), which carried the union of every per-customer hotfix Microsoft had issued. A 2003-era hot patch had to apply cleanly to *both* branches because customers were on different branches. Producing the patch was double the work, and the work duplicated everything that was already going into GDR. The cumulative-update model that replaced GDR/QFE in 2016 is one of the precise preconditions that made the modern hot-patch pipeline economical.

So the four failures of the 2003 design:

No consistency model. The prologue overwrite was atomic at the instruction level, but the design said nothing about a thread that was already executing the function body. If an in-flight call could finish in the old code while a new call into the same function landed in the new code, certain bug fixes that changed semantics across the call were unsound. The 2003 engine handled the easy cases and trusted the patch author for the rest.
No architectural trust anchor. Any kernel-mode code with permission to call NtSetSystemInformation(SystemHotpatchInformation) could install a "hot patch." Driver signing [@ms-pe-format] and Authenticode were the only line of defense, and Microsoft would discover ten years later that they were not enough.
No servicing-model integration. Hot patches were ad-hoc per-advisory artifacts. There was no quarterly baseline, no hotpatch-month cadence, no servicing-stack-level expectation that a customer would receive a hot patch instead of a reboot. Operations teams had to opt into each one.
Limited content coverage. Function-body replacement only. No struct-layout migration, no driver-version transitions in the boot path, no ELAM. The pool of advisories that could ship as a .hotp1 was small.

The fourth failure -- the one Microsoft discovered the hard way -- is the subject of the next section.

3. Why the 2003 pipeline failed: politics, operations, and PLATINUM

In April 2016, Microsoft Threat Intelligence published a report on a state-aligned APT group it tracked as PLATINUM. The mainstream coverage of that report [@thehackernews-platinum] named the group's activity as dating to 2009 and described its tradecraft: PLATINUM was abusing the same NtSetSystemInformation(SystemHotpatchInformation) interface Microsoft itself had shipped, to inject backdoors named Dipsing, Adbupd, and JPIN into winlogon.exe, lsass.exe, and svchost.exe. Microsoft's own MMPC blog said of the hot-patch tradecraft itself, preserved verbatim on the Wayback Machine [@ms-mmpc-platinum-2016-wayback]: "Using hotpatching in the malicious context has been theorized, but has not been observed in the wild before." The April 2016 disclosure was the first in-the-wild observation. The exact start date for PLATINUM's use of the technique is not in the public record; what is in the record is that the mechanism Microsoft had introduced as a customer feature had quietly become a detection-evasion technique by the time Microsoft caught it.

Note: PLATINUM's tradecraft was structurally identical to the 2003 hot-patch engine's design. The group obtained the SeDebugPrivilege-equivalent privileges that the documented NtSetSystemInformation(SystemHotpatchInformation) call required, then used the same syscall path Microsoft had documented for legitimate hot patching [@thehackernews-platinum] to inject code into long-running system processes. Microsoft's MMPC blog framed this as the first in-the-wild observation of the technique, not as evidence of a long-running campaign with a known start date. The point is not that the syscall was a backdoor. The point is that hot patching, as designed in 2003, had no trust anchor architecturally distinct from the kernel that performed the patch. Authenticode validated the binary on disk; nothing validated the in-memory operation. Once an attacker reached kernel mode, the patch path was just another tool.

Microsoft's original PLATINUM writeup lived at blogs.technet.microsoft.com/mmpc/2016/04/26/digging-deep-for-platinum/. That URL has not survived the multiple Microsoft CMS migrations between 2016 and 2026. The Hacker News's contemporaneous coverage [@thehackernews-platinum] preserves the load-bearing details: target processes, backdoor names, the 2009 first-observation date, and the NtSetSystemInformation abuse pattern.

In retrospect Microsoft drew a two-part lesson, visible in the structure of the modern design. First: in-memory code mutation is necessary if you want to live-patch a fleet at any reasonable scale, because reboots are too expensive and operationally too political to schedule monthly. Second: in-memory code mutation cannot ship safely without an architectural trust anchor distinct from the kernel code being mutated, and it cannot ship operationally without a delivery system that constrains what mutations are allowed. The Server 2003 engine had the first half. It had nothing resembling the second half.

Both halves of that lesson took 17 years to be ready. Hardware-mediated isolation under Virtualization-Based Security (VBS) shipped in Windows 10 in 2015; HVCI (the Hypervisor-protected Code Integrity component) and the Secure Kernel matured through subsequent releases; and the cumulative-update servicing model [@wikipedia-windows-update] that replaced the GDR/QFE branch split arrived with Windows 10 and was back-ported to Windows 7 and 8.1 in October 2016 [@wikipedia-windows-update]. Each of those preconditions had to be standard before a successor hot-patch design could exist.

Key idea: The mechanism of hot patching is older than the product. Microsoft did not invent in-memory function replacement on Windows in 2022. It shipped it in 2003, watched it fail operationally, and then discovered in April 2016 that PLATINUM, a group active since 2009, had been weaponizing the same primitive. The work that took 17 years was not the binary rewriting. It was the trust anchor, the servicing discipline, and the management plane that would make rewriting a fleet's .text safe to operate.

While Microsoft's 2003 attempt was atrophying in the field, an MIT graduate student named Jeff Arnold was about to publish what would become the canonical academic treatment of the same problem -- and the Linux community was about to spend a decade and a half working through every consistency-model variant a function-replacement system can have. The Linux side of the story is the next four sections in compressed form.

4. Linux takes the wheel: Ksplice, kpatch and kGraft, mainline livepatch

In June 2008, Jeff Arnold submitted his MIT Master of Engineering thesis. The cover page names him and his supervisor, M. Frans Kaashoek, only [@arnold-mit-thesis-2008]. The thesis's claim, presented as a measurement rather than a hope: 42 of 50 (84%) of all significant x86-32 Linux security patches from May 2005 to December 2007 could be applied to a running kernel by Ksplice without a human writing new code. The patches were applied by treating the source diff as a binary diff and lifting the object-level differences onto the running kernel under stop_machine() quiescence.The Ksplice EuroSys 2009 paper has exactly two authors: Jeff Arnold and M. Frans Kaashoek, both at MIT. The DSpace record at MIT names them verbatim; the PDF title page does the same [@arnold-eurosys-2009-pdf]. Web search engines have occasionally produced five- and six-author lists for this paper. Those are hallucinations. The thesis-to-paper extension at EuroSys is two authors. The Ksplice startup later employed more engineers; the academic record does not.

Ten months after the thesis, in April 2009, Arnold and Kaashoek's EuroSys paper tightened the headline number [@arnold-eurosys-2009-dspace]: 56 of 64 patches from May 2005 to May 2008, or 88% of significant x86-32 Linux kernel security patches, applied with no new code. That number became the founding empirical claim of the entire field. Every live-patcher built since has been measured against it.

Then the field stalled. Oracle acquired Ksplice on July 21, 2011 [@wikipedia-ksplice], pulled Red Hat support, and made the technology Oracle Linux Premier Support customers only [@mit-ksplice-page]. For three years, Linux had no community-shipped live patcher.

timeline title Live-patching, 1996 to 2026 1996-1999 : MSVC /hotpatch ships 2005 : Server 2003 SP1 hotpatch engine 2008-2009 : Ksplice (Arnold and Kaashoek) 2011 : Oracle acquires Ksplice 2014 : kGraft (SUSE) and kpatch (Red Hat) 2015 : Linux 4.0 merges in-tree livepatch 2016+ : Hybrid consistency model lands 2016+ : VBS and HVCI mature in Windows 10 2018-2021 : Microsoft Azure host fleet on internal hot patch Feb 2022 : Server 2022 Azure Edition public GA Apr 2025 : Win11 Enterprise 24H2 client GA Jul 2025 : Server 2025 over Arc at \$1.50/core/month

Two timeline brackets are editorial inferences worth flagging explicitly. The 1996-1999 MSVC /hotpatch row uses the MSVC 6.0 / 7.x toolchain window as the introduction range; the MSVC compiler reference [@ms-cpp-hotpatch] documents current behavior but does not state the original ship year. The 2018-2021 Microsoft Azure host fleet on internal hot patch row brackets the "for years" framing in the November 2021 Windows OS Platform team blog [@ms-techcommunity-hotpatch-nov2021], which is the load-bearing primary attestation that the engine was internal-Azure for years before the February 2022 GA. Both brackets are editorial; the surrounding text and citations carry the unambiguous dates (1996+ for MSVC, 2022 GA for the public product).

The stall ended in early 2014 with two near-simultaneous re-attempts at the same problem. SUSE's Jiri Kosina and Jiri Slaby published kGraft on February 3, 2014 [@lwn-kgraft-584016], as a 600-line patch that built on the kernel's existing ftrace infrastructure plus a per-task "two universe" model, with switchover at kernel-exit. SUSE presented kGraft at the Linux Foundation Collaboration Summit on March 27, 2014 [@collabsummit-2014-sched], and issued a press release crediting SUSE Labs as the origin [@suse-kgraft-pressrelease]. Red Hat's kpatch project had announced publicly on February 26, 2014 [@wikipedia-kpatch]; on May 1, 2014, Josh Poimboeuf sent the kpatch RFC to LKML [@lwn-kpatch-597123], with Seth Jennings co-named on the development team. Red Hat published Poimboeuf's introductory blog [@redhat-kpatch-blog] describing kpatch's four components: a build tool, a per-fix hot-patch module, the kpatch core module that hooked ftrace, and a userspace utility.

Linux's in-kernel function tracer. ftrace works by reserving a small region of NOP space at the start of every traceable kernel function (the `mcount` reservation, similar in spirit to MSVC's `/hotpatch` prologue but separately implemented), then rewriting that NOP region at runtime to call a tracer or, in the live-patch case, to call a replacement function. Both kpatch and kGraft layered live patching on top of ftrace because ftrace had already solved the safe-rewriting problem in the kernel; the live-patcher's job was reduced to "redirect this function" rather than "rewrite this code." The choice of ftrace is the single biggest mechanical difference between Linux live patching and Windows hot patching.

The two designs differed at exactly one place: the consistency model. Kpatch chose stop_machine plus a backtrace check [@lwn-kpatch-597407] -- "a sledgehammer," in LWN's contemporaneous phrase, that halted every CPU and walked every task's stack to verify the old code was not in flight before swapping it for the new. kGraft chose a per-task flag and a lazy migration at kernel-exit [@lwn-kgraft-596854] -- elegant in concept, but with an unbounded transition tail for tasks that never crossed back into user mode. Kpatch could not patch always-on-stack functions like schedule(), do_wait(), or irq_thread(); LWN estimated a few dozen such functions in a typical kernel [@lwn-kpatch-597407]. kGraft could in principle patch anything but might never finish converging.

Generation	Year	System	Primitive	Consistency model	Trust anchor
Gen 0	2005	Server 2003 SP1 hotpatch	`/hotpatch` prologue + `.hotp1` PE section	Atomic prologue swap, no in-flight story	Authenticode + driver signing
Gen 1	2008 to 2011	Ksplice (MIT, then Oracle)	Object-code diff, `stop_machine` quiescence	Global pause, stack check	Out-of-tree kernel module, GPLv2
Gen 2a	2014	kpatch (Red Hat)	ftrace-based fentry trampoline	`stop_machine` plus per-task backtrace check	Module signing
Gen 2b	2014	kGraft (SUSE)	ftrace plus INT3/IPI-NMI rewriting	Per-task flag, kernel-exit migration	Module signing
Gen 3	Apr 2015	Mainline `livepatch` v1	ftrace-based common substrate	Deferred -- both front-ends survive	In-tree module signing
Gen 4	2016+	Mainline `livepatch` hybrid	Same	kGraft per-task plus kpatch stack-check plus kernel-exit plus idle-loop	In-tree module signing
Gen 5	2018 to 2021	Microsoft Azure internal hot patch	HPAT plus IMAGE_HOT_PATCH_BASE plus VSM	Per-process callback, no global pause	Secure Kernel under HVCI
Gen 6	2022, 2025	Windows Modern Hotpatch (three product waves)	Same as Gen 5	Same	Same

Two near-equivalent re-attempts, one tree-shaped politics problem: only one design could be merged. LWN's coverage of the contest [@lwn-kpatch-597407] is now the canonical retrospective. The compromise came in Linux 4.0, released April 12, 2015 [@kernelnewbies-linux-4-0]: merge the ftrace-based common core, defer the consistency-model question. Both kpatch and kGraft survived as out-of-tree front-ends on top of the in-tree core.

A year later, Josh Poimboeuf landed the hybrid consistency model [@lwn-livepatch-consistency-634649] that the in-tree v1 had postponed. The result is what the kernel.org documentation today calls [@kernel-livepatch-doc], in three converged paragraphs of formerly contested design:

Livepatch has a consistency model which is a hybrid of kGraft and kpatch: it uses kGraft's per-task consistency and syscall barrier switching combined with kpatch's stack trace switching. -- `Documentation/livepatch/livepatch.rst`, kernel.org [@kernel-livepatch-doc]

The hybrid uses three convergence approaches in sequence: walk every task's stack at a quiescent point (kpatch's stack-check), transition any remaining tasks lazily at kernel-exit (kGraft's per-task), and finally handle idle "swapper" tasks and forked tasks with separate convergence rules. The architecture is gated on HAVE_RELIABLE_STACKTRACE [@kernel-livepatch-doc], which is itself a non-trivial per-architecture invariant.

{` // Toy simulator of the hybrid livepatch consistency model. // Each task is in one universe (0 = old, 1 = new). The transition // finishes when every task has migrated.

// Phase 1: stack check (kpatch). Migrate every task whose stack does NOT contain // a patched function. We model this as a per-task pass probability. for (const t of tasks) { if (Math.random() < stackCheckPass) { t.universe = 1; converged++; } }

// Phase 2: per-task kernel-exit (kGraft). Each tick, a fraction of remaining // tasks transition the next time they cross from kernel to user mode. while (converged < nTasks && tick < 1000) { tick++; for (const t of tasks) { if (t.universe === 0 && Math.random() < perTickKernelExit) { t.universe = 1; converged++; } } }

return { tick, converged, total: nTasks }; }

const r = simulate({ nTasks: 100, perTickKernelExit: 0.20, stackCheckPass: 0.60 }); console.log('Converged ' + r.converged + '/' + r.total + ' tasks in ' + r.tick + ' ticks'); console.log('Phase 1 (stack check) caught ~60 percent; phase 2 (kernel-exit) caught the rest.'); `}

The key insight from this decade and a half of Linux engineering, stated as an empirical observation that has not been overturned: function-level live patching is tractable if and only if you accept that struct-layout changes still require a reboot. Every Linux generation between 2008 and 2026 confirms this rule. Ksplice's 88% [@arnold-eurosys-2009-dspace] is precisely the fraction of patches that happen to leave data structures alone.

While the Linux community was building the hybrid, Microsoft was watching from inside Azure -- and was rebuilding hot patching from scratch on a different foundation.

5. The modern mechanism: HPAT, IMAGE_HOT_PATCH_BASE, NtManageHotPatch, and the Secure Kernel

On November 19, 2021, the Windows OS Platform blog published a piece called "Hotpatching on Windows" [@ms-techcommunity-hotpatch-nov2021]. Buried in the second paragraph is the load-bearing sentence: "The hotpatch engine requires the Secure Kernel to be running." That single requirement is the architectural pivot. It is what separates the modern pipeline from the 2003 original, from Ksplice, and from every Linux livepatch design built before or since. It is also the answer to the trust-anchor failure that PLATINUM exploited.

Walk the chain of structures, in the order the kernel walks them. There are six steps.

5.1. Compile time: hot-patch metadata into every patchable PE

The target binary is built with hot-patch metadata. The eligible scope, according to the November 2021 blog [@ms-techcommunity-hotpatch-nov2021], covers user-mode DLLs and EXEs, kernel-mode drivers, the hypervisor, and the Secure Kernel itself. Modern Microsoft compiler toolchains lay the metadata into a structured table inside the binary; the published reference is the PE optional header's load-config directory.

A structure pointed to by the optional header of every modern PE32+ image (`IMAGE_LOAD_CONFIG_DIRECTORY64`). The directory carries security-and-loading configuration that the kernel needs before user-mode code starts running: cookie offsets, CFG and CET metadata, SafeSEH tables, and so on. Microsoft's reference [@ms-image-load-config64] lists `DWORD HotPatchTableOffset;` as a member of this directory in modern Windows SDKs. That single 32-bit RVA is the entry point to every other hot-patch structure described in this section.

5.2. Image metadata: the IMAGE_HOT_PATCH_INFO and IMAGE_HOT_PATCH_BASE chain

HotPatchTableOffset points at an IMAGE_HOT_PATCH_INFO structure. The Microsoft Rust bindings [@ms-rs-image-hot-patch-info] document its fields verbatim: Version, Size, SequenceNumber, BaseImageList, BaseImageCount, BufferOffset, ExtraPatchSize. The BaseImageList is itself an RVA into one or more IMAGE_HOT_PATCH_BASE records, with fields [@ms-rs-image-hot-patch-base] SequenceNumber, Flags, OriginalTimeDateStamp, OriginalCheckSum, CodeIntegrityInfo, CodeIntegritySize, PatchTable, and BufferOffset.

The two fields that are doing the real work, semantically, are OriginalTimeDateStamp and OriginalCheckSum. They name the exact base image to which the patch binds. The HPAT proper -- the Hot Patch Address Table reachable from the PatchTable field -- enumerates each patchable site inside the base image: where the prologue lives, what bytes go there, and how to redirect to the replacement function body.

The patch-site table reachable from `IMAGE_HOT_PATCH_BASE.PatchTable`. The HPAT enumerates every individual function-level patch site that a hot patch wants to install in the base image: source RVA, target RVA, byte counts, and any per-site flags the patch engine needs. The Signal Labs reverse-engineering writeup [@signal-labs-hotpatching] documents the table's structure and the kernel's expectations for it as observed in Windows 11 builds. flowchart TD A[PE optional header] --> B["IMAGE_LOAD_CONFIG_DIRECTORY64"] B --> C["HotPatchTableOffset (RVA)"] C --> D["IMAGE_HOT_PATCH_INFO\nVersion / Size / SequenceNumber\nBaseImageList / BaseImageCount"] D --> E["IMAGE_HOT_PATCH_BASE\nOriginalTimeDateStamp\nOriginalCheckSum\nCodeIntegrityInfo / Size\nPatchTable"] E --> F["HPAT entries\nper-function patch sites"] F --> G["Replacement function bodies\n(in the patch PE)"]

5.3. Patch payload: a separate signed PE32+

Each hot patch ships as a separate signed PE32+ image [@signal-labs-hotpatching]. The patch image's own IMAGE_HOT_PATCH_BASE.OriginalTimeDateStamp and OriginalCheckSum must match the base image's load-time fields exactly. The kernel refuses to apply a hot patch whose binding metadata does not match the running base. This is the binding rule that prevents a hot patch produced for kernel32.dll build N from accidentally landing on build N+1.

The patch PE may export a special function __PatchMainCallout__. If present, it is invoked automatically after the patch is loaded in each process [@signal-labs-hotpatching] as a per-process initialization hook -- a hot-patch equivalent of a DLL's DllMain.

5.4. NtManageHotPatch: the dedicated syscall

The 2003 design overloaded NtSetSystemInformation(SystemHotpatchInformation). The modern design has its own syscall. The ntdoc reference [@ntdoc-ntmanagehotpatch] records the signature verbatim:

NTSTATUS NtManageHotPatch(
    _In_      HOT_PATCH_INFORMATION_CLASS HotPatchInformationClass,
    _Out_writes_bytes_opt_(HotPatchInformationLength) PVOID HotPatchInformation,
    _In_      ULONG HotPatchInformationLength,
    _Out_opt_ PULONG ReturnLength
);

The same reference notes the syscall's PHNT_VERSION >= PHNT_WINDOWS_11 [@ntdoc-ntmanagehotpatch] availability gate, which corresponds operationally to Windows 11 and Windows Server 2022 and later. The call dispatches on HotPatchInformationClass in the style of NtQuerySystemInformation, with separate operations to create, activate, map, and list patches.

The dedicated NT syscall through which hot patches are managed. Class-dispatched on `HOT_PATCH_INFORMATION_CLASS`, with operations including patch creation, activation, mapping into target processes, and enumeration of currently active patches. Introduced in the Windows 11 / Server 2022 family [@ntdoc-ntmanagehotpatch]. Unlike the 2003 design, this syscall is the *only* documented entry point to hot patching, which means EDR vendors can instrument it as a discrete operation rather than guessing from `NtSetSystemInformation` parameter blocks.

5.5. Trust anchor: the Secure Kernel under HVCI

The pivotal architectural difference. Per the Windows OS Platform team's November 2021 blog [@ms-techcommunity-hotpatch-nov2021]: the Secure Kernel mediates patch validation and the actual .text rewrite. The Secure Kernel is the kernel-side counterpart to the Isolated User Mode (IUM) trustlet world, running in Virtual Trust Level 1 (VTL1) under VBS, with HVCI enforcing the invariant that executable code pages must be signed by an entity the normal kernel trusts.

Note: HVCI's bedrock invariant is that no code page becomes executable unless it was signed by Microsoft (or a trust chain Microsoft endorses) at attestation time. A hot patch rewrites .text. Naively, that breaks the invariant. The architectural escape is that the new .text came from a signed PE whose signature chains to Microsoft -- and that signature is verified by the Secure Kernel, in VTL1, before the rewrite happens. The normal kernel cannot bypass that verification, because the normal kernel does not perform the rewrite. The Secure Kernel does. This is the structural advance over both Microsoft's 2003 self and over Linux livepatch -- where the same kernel both verifies module signatures and applies the patch. Trust comes from the verifier being architecturally distinct from the verified.

5.6. Per-process rollout: ntdll callback and PatchMainCallout

No global stop-the-world. The kernel enumerates running processes and calls a notification callback inside ntdll.dll [@signal-labs-hotpatching] in each process, which re-maps the patched code from a kernel-curated view into the process's address space. If the patch PE exports __PatchMainCallout__, that function runs in each process immediately after the patch lands. The per-process model means the patch transition is asynchronous and decentralized; there is no equivalent of Linux's stop_machine() quiescence, and no equivalent of kGraft's per-task universe flag. The cost is a more complex security boundary -- the Signal Labs analysis observes that a process can attempt to load a hot patch repeatedly with a payload that fails validation [@signal-labs-hotpatching], producing a denial-of-service vector against specific target processes if administrative privileges have been compromised.

sequenceDiagram actor Admin as Administrator participant UM as User-mode caller participant NK as Normal kernel participant SK as Secure Kernel (VTL1) participant Proc as Each running process participant NTDLL as ntdll.dll per process

Admin->>UM: Initiate patch install
UM->>NK: NtManageHotPatch(class=Activate)
NK->>SK: Forward patch PE for validation
SK->>SK: Verify signature, OriginalTimeDateStamp,\nOriginalCheckSum, code-integrity hash
SK->>SK: Walk HPAT, rewrite .text under HVCI
SK-->>NK: SUCCESS
NK->>Proc: Walk processes that mapped the base image
NK->>NTDLL: Invoke per-process notification callback
NTDLL->>NTDLL: Re-map patched code into address space
alt Patch exports __PatchMainCallout__
    NTDLL->>Proc: Invoke __PatchMainCallout__()
end
NTDLL-->>NK: Per-process completion

Walking the HPAT chain in code

The chain from optional header to per-function patch site is small enough to walk by hand. The block below is a teaching skeleton: it does not execute against a real PE binary; it shows the field-by-field traversal that a kernel-side validator performs every time NtManageHotPatch(Activate) is called.

{` // Teaching skeleton. The shapes match the public Microsoft documentation // (ms-image-load-config64, ms-rs-image-hot-patch-info, ms-rs-image-hot-patch-base). // The structures are populated with placeholder values; a real kernel-side // validator reads bytes from the on-disk PE and the in-memory image.

function walkPatchChain(peImage) { const optionalHeader = peImage.optionalHeader; const loadConfig = peImage.read(optionalHeader.loadConfigRVA, 'IMAGE_LOAD_CONFIG_DIRECTORY64'); const hpatTableRVA = loadConfig.HotPatchTableOffset; if (!hpatTableRVA) { return { eligible: false, reason: 'no HotPatchTableOffset; binary not compiled hotpatchable' }; }

const info = peImage.read(hpatTableRVA, 'IMAGE_HOT_PATCH_INFO'); const bases = []; for (let i = 0; i < info.BaseImageCount; i++) { const baseOffset = info.BaseImageList + i * peImage.sizeOf('IMAGE_HOT_PATCH_BASE'); const base = peImage.read(baseOffset, 'IMAGE_HOT_PATCH_BASE'); bases.push(base); }

// The kernel verifies a patch by matching THIS image's OriginalTimeDateStamp // and OriginalCheckSum against the patch PE's corresponding fields. If they // mismatch, the kernel refuses the patch with STATUS_HOT_PATCH_FAILED. return { eligible: true, info, bases, bindingFields: bases.map(b => ({ stamp: b.OriginalTimeDateStamp, checksum: b.OriginalCheckSum, patchTableRVA: b.PatchTable })) }; } `}

The three architectural differentiators

Three differences from the 2003 design, stated bluntly because they are the load-bearing distinctions:

Dedicated NtManageHotPatch syscall instead of overloaded NtSetSystemInformation. Distinct attack surface, instrumentable separately, with its own access-control rules.
Signed PE32+ patch images verified by the Secure Kernel, not bare driver-signing on a .hotp1 payload. The verifier sits in VTL1, architecturally distinct from the kernel that holds the .text mapping.
HPAT metadata baked into every patchable binary at compile time, not a single-flag prologue plus .hotp1 section pair. The metadata names the patchable sites individually, with a per-site flag vocabulary that admits future operations the 2003 engine could not represent.

Key idea: The Secure Kernel is the load-bearing innovation, not HPAT. HPAT is mechanism -- a structurally cleaner version of the 2003 metadata, with per-site flags and binding fields the older format did not have. The architectural advance is that HVCI's "executable pages were signed" invariant is preserved across a hot patch because the new pages came from a signed PE whose signature chains to Microsoft and the normal kernel cannot bypass that verification. Linux livepatch trusts the standard module-signing policy enforced by the kernel it is patching. Microsoft's modern design moves the verifier into a different, architecturally isolated kernel.

The mechanism is now complete. What remains is the pipeline around it.

6. The three-stack decomposition: mechanism, delivery, management

There is no single thing called "Windows hot patching." There are three layers that look like one thing if you squint -- and explaining them as one thing is the most common pedagogical mistake in this space. Each layer has its own engineering team, its own failure modes, its own primary documentation. Treat them in order.

Layer A -- the kernel mechanism. Everything in §5: HPAT, IMAGE_HOT_PATCH_BASE, NtManageHotPatch, and the Secure Kernel. Microsoft documents Layer A unevenly. The structure definitions are public via the Rust windows-docs bindings (IMAGE_HOT_PATCH_INFO [@ms-rs-image-hot-patch-info], IMAGE_HOT_PATCH_BASE [@ms-rs-image-hot-patch-base]) and the IMAGE_LOAD_CONFIG_DIRECTORY64 reference [@ms-image-load-config64]. The syscall signature is in the community-maintained ntdoc reference [@ntdoc-ntmanagehotpatch]. The most thorough public field-level documentation of the runtime behavior is Signal Labs' reverse-engineering writeup [@signal-labs-hotpatching] and an independent PoC repository [@github-ntmanagehotpatchtests] that exercises the syscall. There is no equivalent of the kernel.org Documentation/livepatch/livepatch.rst file inside Microsoft's official docs.

Layer B -- the servicing model. This is where the operational pipeline lives. The Microsoft Learn reference for Hotpatch on Windows Server [@ms-server-hotpatch] describes the cadence verbatim: hot patching first establishes a baseline with the current Cumulative Update for Windows Server, and every three months that baseline refreshes with the latest Cumulative Update. Between baselines, two hotpatch-only releases ship: months in which the only payload is the security-update delta as a signed hot-patch PE.

**LCU**: Latest Cumulative Update. The single, full security-and-quality update bundle that Microsoft has issued monthly for Windows since the 2016 cumulative-update model. An LCU contains the union of all security fixes since the previous baseline, and applying it always requires a reboot because it lays down replacement binaries on disk and rebinds the running kernel.

SSU: Servicing Stack Update. A specialized monthly update to the component that applies updates (wusa.exe, usoclient.exe, the Windows Update agent state machine). SSUs cannot ship as hot patches because they update the patcher itself. They are part of the reason "unplanned baselines" exist: a month in which security content cannot ship as a hot patch falls back to a regular LCU.

There are two types of baselines, again per Microsoft Learn [@ms-server-hotpatch]. Planned baselines are the quarterly LCU drops that follow the cumulative-update cadence -- one each January, April, July, October. Unplanned baselines preempt a hotpatch month when the month's security content cannot ship as a hot patch: a kernel struct-layout change, a driver update, an SSU, a language-pack update, or any security fix in a non-hotpatchable component. The promise is that the channel maintains parity with the content of security updates issued to the regular non-Hotpatch Windows update channel [@ms-server-hotpatch]. Customers who run hot patching are not getting a curated subset of fixes. They are getting the same fix set, in a different delivery mode.

gantt title Windows Hotpatch servicing cadence dateFormat YYYY-MM-DD axisFormat %b section Servicing Planned baseline LCU (reboot) :crit, b1, 2026-01-01, 30d Hotpatch only :h1, 2026-02-01, 30d Hotpatch only :h2, 2026-03-01, 30d Planned baseline LCU (reboot) :crit, b2, 2026-04-01, 30d Hotpatch only :h3, 2026-05-01, 30d Hotpatch only :h4, 2026-06-01, 30d Planned baseline LCU (reboot) :crit, b3, 2026-07-01, 30d Hotpatch only :h5, 2026-08-01, 30d Hotpatch only :h6, 2026-09-01, 30d Planned baseline LCU (reboot) :crit, b4, 2026-10-01, 30d Hotpatch only :h7, 2026-11-01, 30d Hotpatch only :h8, 2026-12-01, 30d

The reboot frequency on a hot-patch-eligible fleet drops from 12 a year to 4 a year, per Microsoft's April 24, 2025 Windows Server blog [@ms-blog-server2025-hotpatch]. That 3:1 reduction is the operational claim. It is conditional on the fleet being eligible every month -- on no month's security content being non-hotpatchable -- so the realized reduction depends on which CVEs Microsoft has to fix in any given quarter.

Layer C -- the management plane. Layer C is where compliance, telemetry, ring-based rollout, eligibility detection, and fallback behavior live. There are three management surfaces for the three product variants:

Azure Update Manager for Azure VMs running Server 2022 Datacenter: Azure Edition and Server 2025 Datacenter: Azure Edition. The control plane is built into the VM SKU; onboarding is a SKU selection and an update-management association.
Intune Autopatch for Windows 11 Enterprise 24H2 clients. The Microsoft Learn doc for Autopatch hot patching [@ms-autopatch-hotpatch] lays out the license requirements (Windows 11 Enterprise E3/E5, Microsoft 365 F3, Education A3/A5, M365 Business Premium, or Windows 365 Enterprise), the prerequisite that VBS must be turned on, and the silent-fallback behavior for ineligible devices: a Hotpatch-policy-enrolled device that does not meet the prerequisites simply receives the regular LCU instead.
Azure Arc Hotpatch for Server 2025 outside Azure. The connection to Azure Arc is the delivery channel; the meter that runs at $1.50 per CPU core per month is operationalized through Arc [@ms-blog-server2025-hotpatch].

Telemetry is a property of Layer C. The kernel patch engine reports per-process completion to the normal kernel; the normal kernel reports per-machine completion to whichever Layer C surface is in charge of that machine. Conflating "the kernel reports patch success" with "Microsoft is telemetering my workload" is wrong in the same way conflating Layer A with Layer C is wrong.

flowchart LR subgraph LayerA["Layer A: Kernel mechanism"] A1["HPAT + IMAGE_HOT_PATCH_BASE"] A2["NtManageHotPatch syscall"] A3["Secure Kernel under HVCI"] A1 --> A2 --> A3 end subgraph LayerB["Layer B: Servicing model"] B1["Quarterly baseline LCU"] B2["2 hotpatch-only months between baselines"] B3["Unplanned baselines for non-hotpatchable content"] B1 --> B2 --> B3 end subgraph LayerC["Layer C: Management plane"] C1["Azure Update Manager (Server, Azure)"] C2["Intune Autopatch (Win11 24H2 clients)"] C3["Azure Arc Hotpatch (Server 2025, outside Azure)"] end LayerC --> LayerB --> LayerA

So: what is hot-patchable? Per the Microsoft Learn Hotpatch Autopatch documentation [@ms-autopatch-hotpatch], Hotpatch updates are Monthly B-release security updates that install and take effect without requiring you to restart the device [@ms-autopatch-hotpatch]. And what is not?

Hot-patchable	Not hot-patchable
Security updates to function bodies inside hotpatch-compiled PEs	Updates that change the layout, size, or invariants of static data structures
User-mode DLLs and EXEs compiled with hot-patch metadata	Drivers, including ELAM drivers
Kernel-mode drivers compiled with hot-patch metadata	Boot loader components
The hypervisor and the Secure Kernel itself	Secure-Launch / DRTM measurement-scoped binaries
Win11 24H2 Enterprise B-release security updates on eligible (VBS-on, non-CHPE) devices	Servicing Stack Updates (the patcher patches itself)
	Language pack updates
	Defender platform updates outside the OS channel
	.NET updates outside the OS channel
	Any update issued outside the dedicated Hotpatch channel

On Arm64 Win11 24H2 clients, Hotpatch is additionally incompatible with servicing CHPE OS binaries [@ms-autopatch-hotpatch] located in %SystemRoot%\SyChpe32. Operators who depend on CHPE for x86-on-Arm64 app compatibility cannot enable Hotpatch on those devices today.

The experience is so seamless you don't even know what happened. There are no process restarts, no logging out, no performance impact. No glitch in the video playing or transaction dropping. Everything just works as if nothing has happened. -- Nevine Geissa, Partner Group PM, Windows Servicing and Delivery, Microsoft Inside Track [@ms-insidetrack-hotpatch]

Three layers, three failure modes. The Linux side of the story made different choices at each. The next section does the head-to-head along the axes that actually matter.

7. Windows hot patching vs Linux livepatching: different primitives, same problem

Two well-engineered systems. One shared goal. Four divergent answers. The comparison is not "Windows is better" or "Linux is better." The comparison is that each design made specific architectural choices that follow logically from preconditions the other system did not have.

Axis	Windows Modern Hotpatch	Linux livepatch (in-tree, hybrid)
Redirection primitive	In-place `.text` rewrite of a signed PE image directed by HPAT	ftrace `mcount`/`fentry` trampoline redirecting callers to a replacement function loaded as a kernel module
Consistency model	Per-process notification callback in `ntdll`, no global pause	Hybrid: per-task (kGraft) + stack-trace (kpatch) + kernel-exit + idle "swapper" task + forced-signal fallback
Trust anchor	Secure Kernel signature validation under HVCI in VTL1	Kernel module signing policy enforced by the same kernel being patched
Scope	User-mode DLLs/EXEs, kernel drivers, hypervisor, Secure Kernel itself	Kernel only (Oracle Ksplice adds glibc/OpenSSL user-mode on Oracle Linux Premier Support)
Cadence and pricing	Quarterly baseline + 2 hotpatch months; free on Azure IaaS, paid Arc subscription outside Azure ($1.50/core/month for Server 2025)	Ad-hoc per-CVE; distribution-included pricing on RHEL/SLES/Ubuntu/Oracle Linux

The trust-anchor row is the load-bearing one. Linux's in-tree livepatch documentation [@kernel-livepatch-doc] describes the consistency model in considerable detail; it describes the kernel-module-signing policy in less detail because the policy is the same one Linux uses for any kernel module. The verifier is the kernel itself. If an attacker who has obtained the necessary capability to install kernel modules can also forge or replace the module-signing key, the verifier is downstream of the attacker. Windows's design moves the verifier behind an architectural boundary. The normal kernel that mediates the syscall does not perform the verification. The Secure Kernel does, in VTL1, behind a hypervisor that the normal kernel cannot subvert without first compromising the Secure Kernel directly.

The redirection row is the next most consequential. The Linux design uses ftrace trampolines because ftrace had already solved the safe-rewriting problem inside Linux when kpatch and kGraft started. Layering live patching on top of ftrace meant the live-patcher's mechanical scope was small: "redirect callers of this function." The Windows design rewrites the function prologue directly with an instruction-sized atomic write. The two primitives have different failure modes. ftrace adds a permanent indirection cost to every traced function on the system; the in-place rewrite has zero steady-state cost but a more complex one-time write.

flowchart TD Start["Start: install patch P"] --> Phase1{"Phase 1: stack check (kpatch)"} Phase1 -- "Task's stack clean" --> Migrate1["Migrate task to new universe"] Phase1 -- "Patched fn on stack" --> Phase2{"Phase 2: wait for kernel-exit (kGraft)"} Phase2 -- "Task crosses kernel-exit" --> Migrate2["Migrate at exit"] Phase2 -- "Stuck in kernel" --> Phase3{"Phase 3: idle-loop + forced-signal fallback"} Phase3 -- "Idle swapper" --> Migrate3["Migrate idle task"] Phase3 -- "kthread" --> Special["Reliable-stacktrace gate; kthreads remain hard"] Migrate1 --> Done["Patch live for task"] Migrate2 --> Done Migrate3 --> Done

The scope row tells a related story. The November 2021 Windows OS Platform blog explicitly says Windows hot patches can target user-mode binaries, drivers, the hypervisor, and the Secure Kernel itself [@ms-techcommunity-hotpatch-nov2021]. Linux's livepatch is kernel-only by design; Oracle's Ksplice has user-mode add-ons for glibc and OpenSSL available to Oracle Linux Premier Support customers [@mit-ksplice-page], but no other mainstream Linux live-patcher covers user-mode. The Windows choice to cover user-mode is operationally significant: many high-impact security fixes target services that run in lsass.exe, svchost.exe, or product-specific user-mode daemons, and Linux's userspace equivalent of those fixes still requires the affected processes to be restarted.The kpatch project entered maintenance mode as of Linux 6.19 [@github-kpatch]; new live-patch builds are now expected to use the upstream klp-build script in scripts/livepatch/. The kpatch project isn't gone -- the runtime remains, the build tooling is migrating into the tree.

A brief tour of what is going on in the field today. Ksplice is Oracle-Linux-Premier-Support-only [@mit-ksplice-page] since the 2011 acquisition, with the glibc/OpenSSL user-mode coverage being the most distinctive remaining feature. kpatch is in maintenance mode; the build tooling has been promoted into the kernel tree as klp-build, and the project's GitHub README [@github-kpatch] documents the deprecation explicitly. kGraft survives as an out-of-tree front-end primarily for SUSE customers, with the relevant consistency-model logic having been merged into the in-tree hybrid years ago. Windows Modern Hotpatch is the system this article is about.

Both systems work. Both have ceilings. The next section is where the ceiling actually is.

8. The theoretical ceiling: what no function-replacement system can ever do

Every live-patching system on Earth ships with the same warning, in different words. There is a class of patches that none of them can apply. The class is well-defined and the explanation is not engineering -- it is logic.

Data-layout changes. A patch that changes the layout, size, or invariants of any static data structure read or written by code not also being patched in the same transaction breaks every function-replacement live-patcher. Ksplice's 88% headline [@arnold-eurosys-2009-dspace] is precisely the fraction of patches that happen to leave data structures alone. The 12% that does not is what every live-patching design defers to reboot.

The reason is structural. Suppose a kernel struct foo has fields (a, b, c) and the patch wants to add a field d. Every function that reads or writes a foo operates on the old layout; new functions added by the patch operate on the new layout. The transition window contains threads in flight that hold pointers into the old struct, and any new code that allocates or writes a foo would corrupt them. The general algorithmic question -- "can this layout change be applied safely to an arbitrary running kernel?" -- is undecidable in the general case, because deciding it is equivalent to deciding what an arbitrary running program's memory invariants are.

Note: Rice's theorem says that every non-trivial semantic property of a program is undecidable. The property "this layout change is safe on the running kernel" is non-trivial and is a semantic property of the running program. Therefore no general algorithm decides it. Ksplice's shadow-data-member trick handles the easy case (additive-only fields) by allocating the new field out-of-band per object; it works because additive changes have a closed-form correctness argument. The hard cases -- changing field types, changing alignment, reordering, removing a field used elsewhere -- have no closed-form argument, and no live-patcher ever invented one.

Boot-anchored measurements. ELAM (Early Launch Anti-Malware) drivers, DRTM (Dynamic Root of Trust for Measurement) and Secure Launch components, and other measurement-scoped binaries have their hashes extended into TPM PCRs at boot. A hot patch that mutates such a binary after attestation breaks the post-attestation invariant: the verifier downstream of the attestation expected a measured value that no longer corresponds to the running binary. The post-rewrite memory is not inside the original attestation envelope; the attestation has to be re-rooted, which requires a reboot. Microsoft's exclusion list reflects this -- drivers (including ELAM), boot-loader components, and Secure Launch / DRTM measurement-scoped binaries are not hot-patchable in the published servicing model [@ms-server-hotpatch].

Inlined or always-on-stack code. Function-replacement systems require a single entry point per logical function. A function that has been inlined into every caller has no entry point to patch. A function that is always somewhere on a stack -- kpatch's classic examples of schedule(), do_wait(), and irq_thread() -- effectively behaves as if inlined for the purpose of the live-patcher, because the stack-check phase can never converge on a quiescent moment. LWN's coverage estimated a few dozen such functions on a typical Linux kernel [@lwn-kpatch-597407]; the equivalent class for Windows is the never-quiescent kernel entry points that one cannot patch without first taking the system out of operation.

Concurrency invariants. Lock-free algorithms, RCU readers in flight, and code execution orderings that the patch quietly changes require quiescence beyond what any function-replacement primitive offers. The Linux livepatch consistency-model debate at LWN 634649 [@lwn-livepatch-consistency-634649] and the kernel.org livepatch.rst §7 "Limitations" [@kernel-livepatch-doc] document this class of constraint: a patch that subtly changes the order of memory operations in a function that participates in a lock-free protocol can leave readers observing impossible states across the transition. The literature on this is mostly cautionary, not exhaustive; the live-patcher's job is to assume any patch that touches concurrent code is unsafe by default and require the patch author to argue otherwise.

The empirical upper bound, again, is the Ksplice 88% number from a finite window of x86-32 Linux security patches between May 2005 and May 2008. Microsoft has not published a comparable automation-rate study for the modern Windows pipeline; the public claim is that the channel maintains parity with the content of security updates [@ms-server-hotpatch] issued to the regular non-Hotpatch channel, with unplanned baselines preempting hotpatch months when the content is not eligible. That is an operational claim, not a percent-of-CVEs measurement.

Key idea: The ceiling on every live-patching system is Rice's theorem applied to memory-layout semantics. No general algorithm decides whether an arbitrary data-layout change is safe to apply to an in-flight program; therefore every live-patcher treats data-layout changes the same way -- defer to reboot. The 12% that remains is the open research problem live-patching has been carrying for 18 years; Ksplice's 88% set the ceiling no successor has moved.

The remaining 12% is the problem of the next generation. The open problems are the subject of §9.

9. Open problems: where the pipeline is still evolving

Hot patching is "done" only in the sense that it ships. Four problems remain open as of May 2026.

9.1. Confidential VMs and the attestation envelope

AMD SEV-SNP [@azure-confidential-vm-overview] and Intel TDX [@intel-tdx-overview] provide a measured launch of a guest VM image attested to a relying party. Microsoft's own Azure confidential-VM documentation states the contract verbatim: "Azure confidential VMs boot only after successful attestation of the platform's critical components and security settings" [@azure-confidential-vm-overview], and an in-VM workload can issue an attestation request to "verify that your confidential VMs are running a hardware instance with either AMD SEV-SNP, or Intel TDX enabled processors." The attestation establishes that a specific image -- byte for byte, hash for hash -- is what is running inside the confidential VM. If NtManageHotPatch later rewrites guest .text, is the post-rewrite memory inside the attestation envelope? Does the relying party need to re-verify? Microsoft has not publicly documented this interaction. The hot-patch SKU eligibility list [@ms-server-hotpatch] covers Server 2022 and Server 2025 Datacenter: Azure Edition; confidential VM SKUs run on adjacent Azure infrastructure; the documented intersection is a gap. Framed as a documented gap, not speculated beyond.

9.2. The subscription metering question

$1.50 per CPU core per month for Server 2025 hot patching over Azure Arc is the first time a major OS vendor has metered live patching with a per-CPU-core meter [@ms-blog-server2025-hotpatch] rather than per-machine (Canonical Livepatch via Ubuntu Pro) or per-CPU-pair (Oracle Ksplice bundled into Oracle Linux Premier Support). Azure Arc is itself a management plane, so the framing is "metered, per-core, on a management plane" rather than "metered outside any subscription tier." Forbes' coverage [@forbes-150-hotpatch] confirms the pricing and the July 1, 2025 GA. The economic question -- does pricing accelerate or decelerate patch adoption across the global Windows Server fleet? -- has no public data yet. The fairness question -- should faster patching cost more, when faster patching makes the world safer? -- has no answer that does not depend on assumptions about which fleets are doing the patching.

9.3. Detection and abuse of the same primitive

Signal Labs has shown that the same NtManageHotPatch mechanism can be repurposed for in-memory code injection PoCs under specific privilege conditions [@signal-labs-hotpatching]; an independent PoC repository [@github-ntmanagehotpatchtests] corroborates by exercising the syscall against a controlled target. The risk is structurally similar to the 2003-era hot-patch abuse Microsoft disclosed in April 2016, but with two important differences: the modern path requires the Secure Kernel to validate a signed payload (the 2003 path did not), and operators have an explicit registry knob -- HotPatchRestrictions=1 at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management [@ms-autopatch-hotpatch] -- documented as the way to disable CHPE servicing on Arm64 so those devices remain eligible for hot patching. EDR vendors who want to distinguish legitimate Microsoft-signed hot patches from hostile injection have to instrument both the syscall and the registry state. This is solvable, but it is not solved by default in every EDR.

9.4. Arm64 client porting and CHPE

Arm64 Windows 11 24H2 hot patching [@ms-techcommunity-hotpatch-client-apr2025] remains in preview as of the April 2025 GA for x64, with the CHPE compatibility issue [@ms-autopatch-hotpatch] acting as the visible technical gate.The CHPE constraint is documented at Microsoft Learn verbatim: Hotpatch updates are not compatible with servicing CHPE OS binaries located in the %SystemRoot%\SyChpe32 folder [@ms-autopatch-hotpatch]. CHPE (Compiled Hybrid Portable Executable) is the format Windows uses to speed up x86 applications on Arm64 by inlining native Arm64 code into x86 binaries. The hot-patch metadata format and the CHPE format have an unresolved interaction in the current toolchain.

The Linux equivalent of the Arm64 porting story is the HAVE_RELIABLE_STACKTRACE gate [@kernel-livepatch-doc] and the related kthread caveats. Kthreads on architectures without reliable stack-trace support remain a hard case for the in-tree hybrid consistency model.

For an operator deciding today which of these open problems matters, the answer depends on which of the three Windows products is theirs. The next section is the practical decision tree.

10. The operator's decision: adopting hot patching in 2026

The operator question is not "should I hot-patch?" but "which of the three products is mine and what does it actually cost?" Walk through the tree.

10.1. Windows Server 2022 Datacenter: Azure Edition

Free on Azure IaaS. The product was announced as generally available on February 16, 2022 [@techcommunity-server2022-ga-feb2022] (this is also confirmed by a contemporaneous external mirror [@thewindowsupdate-2022]). Onboarding is a SKU selection (-Hotpatch suffix variants), an Azure Update Manager association, and a baseline alignment to the current LCU. The Server 2022 hotpatch initially shipped Server-Core-only; the Desktop Experience GA on July 18, 2023 [@techcommunity-server-desktop-experience] removed the operationally-large adoption blocker for admins who refused Server Core. From that date forward, all common Server 2022 Azure Edition VM configurations are hot-patch-eligible.

10.2. Windows Server 2025 Datacenter / Standard via Azure Arc

$1.50 USD per CPU core per month outside Azure, generally available since July 1, 2025 [@ms-blog-server2025-hotpatch]. Free on Azure IaaS / Azure Local for Server 2025 Datacenter: Azure Edition VMs. The math at $1.50/core/month is mechanical: a 128-core machine is $192/month or $2,304/year for the hot-patch subscription; an eight-machine 128-core cluster is $18,432/year. Whether that price is justified depends on the operator's per-reboot cost.

This is not a CFO-style break-even calculation -- the inputs differ too much across organizations to make a one-line answer useful. The framing question is: what does a reboot actually cost in your fleet? Revenue downtime during the maintenance window, on-call coordination overhead, the deferred-patch security risk created by the inevitable delay between Patch Tuesday and the night the operations team is willing to schedule the reboot. Microsoft Inside Track [@ms-insidetrack-hotpatch] quantifies Microsoft Digital's own number; every operator has to compute their own. A useful first-pass formula is below.

{` // Per-fleet break-even calculator. Inputs are organization-specific. // The function returns whether the Arc hot-patch subscription is cheaper // than the cost of the avoided reboots, assuming 8 hot-patch months a year // (4 reboots/year baseline vs 12 without hot patching).

// Example: a 128-core box, 100-machine fleet, $1,200 per reboot event // (coordination, downtime, ops overhead). 8 hotpatch months avoided per year. const r = breakEven({ cores: 128, fleetSize: 100, costPerRebootEvent: 1200, rebootsAvoidedPerYear: 8 }); console.log('Subscription annual: $' + r.subscriptionAnnual.toLocaleString()); console.log('Avoided reboot cost: $' + r.avoidedRebootCost.toLocaleString()); console.log('Net savings : $' + r.netSavings.toLocaleString()); console.log('Worth it : ' + r.worthIt); `}

Note: The formula is: subscription cost = cores x \$1.50 x 12 x fleet_size. The avoided reboot cost is cost_per_reboot_event x rebootsAvoided x fleet_size. The intersection is your decision point. The most-underestimated input is the coordination cost of scheduling the reboot window across multiple operations teams in regulated organizations -- it is rarely zero and is often the largest single line item.

10.3. Windows 11 Enterprise 24H2 client

License-gated through Intune Autopatch. The license bar, per Microsoft Learn [@ms-autopatch-hotpatch], is one of Windows 11 Enterprise E3/E5, Microsoft 365 F3, Education A3/A5, M365 Business Premium, or Windows 365 Enterprise. VBS must be on. Ineligible devices (VBS off, CHPE binaries present on Arm64, or any other policy mismatch) silently fall back to LCU; the device's user experience is unchanged except that hot-patch months still require the usual monthly reboot. Hot patching is staged via Intune Autopatch quality update policy with the hot-patch toggle enabled; eligibility detection runs per device. The Bleeping Computer coverage of the April 2025 client GA [@bleepingcomputer-win11-hotpatch] cross-confirms the dates and the licensing model.

The Autopatch default-on flip [@techcommunity-autopatch-on-by-default-2026] turns hot patching into the default for eligible Windows 11 24H2 Enterprise devices in the May 2026 servicing cycle; opt-out controls become effective on April 1, 2026 for organizations that need to delay the transition.

10.4. Operational rules that apply to all three

Quarterly baseline alignment is non-negotiable. A machine that drifts off the current quarterly baseline cannot consume the next hot-patch month; it falls back to a full LCU until it realigns.
Unplanned baselines preempt hot-patch months for un-hotpatchable security content. Operators cannot opt out of an unplanned baseline. The fix Microsoft has to ship for a kernel-struct-changing zero-day will land as a reboot-requiring LCU regardless of Hotpatch policy.
Monitor patch state via the management plane. Azure Update Manager (Server, Azure), Intune Autopatch dashboards (clients), and Arc Hotpatch (Server outside Azure) each report per-device or per-VM patch state. Alert on baseline drift; alert on Hotpatch-policy-enrolled devices that have silently fallen back to LCU.

Microsoft Digital's compliance numbers are the best public dataset on real-world hot-patch adoption: 81% compliance within 24 hours; 90% within 5 days; 95% within 3 weeks across 4.5 million devices since Windows 11 24H2 GA in April 2025 [@ms-insidetrack-hotpatch]. The Xbox team's reduction was from "weeks down to just a couple of days." These are best-case numbers from a deeply Microsoft-fluent operations org; they are achievable, not universal.

For operators under NIST, HIPAA, PCI, or SOX-style controls, "patched but not rebooted" is a status that did not cleanly exist in audit frameworks five years ago. Hot patching changes what "patched" means in a way that some auditor checklists were not written for. Operators in regulated environments should clear the new patch state with their auditor before depending on it for compliance reporting. The mechanism is sound; the audit framework's recognition of it is the operational variable. On a Win11 24H2 Enterprise client, the eligibility surface is partly visible via the `HotPatchRestrictions` registry key (Autopatch policy state), the VBS status (`Get-CimInstance -ClassName Win32_DeviceGuard | Select-Object SecurityServicesRunning, VirtualizationBasedSecurityStatus`), and the current servicing baseline build. Combining the three -- VBS on, Hotpatch policy enrolled, current quarterly baseline applied -- predicts whether the next month's release will land as a hot patch or as an LCU.

The remaining questions are the ones every reader hits. The FAQ is next.

11. Frequently asked questions

No. The mechanism is different (in-place `.text` rewrite of a signed PE image directed by HPAT, instead of an ftrace `mcount` trampoline redirecting callers to a replacement function). The trust anchor is different (the Secure Kernel in VTL1 under HVCI, instead of the kernel module-signing policy enforced by the same kernel being patched). The scope is different (user-mode DLLs and EXEs, drivers, the hypervisor, and the Secure Kernel itself, vs kernel-only on Linux mainline). The consistency model is different (per-process callback in `ntdll`, no global pause, vs Linux's hybrid kGraft + kpatch + idle-loop + forced-signal model [@kernel-livepatch-doc]). The two systems solve the same operational problem with structurally different primitives. No. Per Microsoft's April 2025 Windows Server blog [@ms-blog-server2025-hotpatch], reboots drop from 12 a year to 4 a year on eligible fleets. The four quarterly baseline LCUs remain mandatory. Unplanned baselines (kernel struct changes, SSUs, drivers, language packs, any non-hotpatchable security content) preempt hot-patch months and require a reboot. No. Drivers are excluded from the Hotpatch envelope [@ms-server-hotpatch], including ELAM drivers and boot-loader components. Driver updates that ship as security fixes will land via the regular LCU on the next quarterly baseline (or sooner, as an unplanned baseline). Microsoft frames Azure Arc as the delivery channel for Server 2025 hot patching outside Azure and meters the subscription at \$1.50 USD per CPU core per month [@ms-blog-server2025-hotpatch]. On Azure IaaS and Azure Local for Server 2025 Datacenter: Azure Edition VMs, hot patching is free. The Arc subscription is the first time a major OS vendor has metered live patching with a per-CPU-core meter (Canonical Livepatch is priced per machine; Oracle Ksplice is bundled into Oracle Linux Premier Support priced per CPU pair). The economic case is fleet-dependent and is the subject of §10. In practice, yes. The Windows OS Platform team's November 2021 blog [@ms-techcommunity-hotpatch-nov2021] is explicit: the hotpatch engine requires the Secure Kernel to be running. The Autopatch documentation [@ms-autopatch-hotpatch] extends the requirement to clients: VBS must be turned on for a device to be offered Hotpatch updates. Server 2025 / Server 2022 Azure Edition treat the Secure Kernel as load-bearing for patch validation. VBS-off devices silently fall back to LCU. Yes, technically. The Server 2003 SP1 hot-patch engine shipped via the `/hotpatch` compile flag, `.hotp1` PE sections [@openrce-patching-internals], and `NtSetSystemInformation(SystemHotpatchInformation)` (as walked through in Johannes Passing's 2011 reverse-engineering writeup [@jpassing-hotpatching]). It was operationally rare, never had a trust anchor architecturally distinct from the kernel code it mutated, and was first publicly documented as an APT code-injection primitive in Microsoft's April 2016 PLATINUM report [@thehackernews-platinum] (PLATINUM as a group dates to 2009; the exact start date for its hot-patch tradecraft is not in the public record). The modern pipeline is a 17-year revival on a different foundation -- a dedicated syscall, signed PE32+ patch images, and verification by the Secure Kernel in VTL1.

Hot patching is a pipeline, not a feature. The mechanism Microsoft shipped in February 2022 is older than the public product; the real engineering work between 2003 and 2022 was the trust anchor (the Secure Kernel under HVCI, mature only after 2015), the servicing discipline (cumulative-update model from 2016, hot-patch / baseline cadence from 2022), and the management plane (Azure Update Manager, then Intune Autopatch, then Azure Arc, each a separate operations product layered on the same kernel engine). The mechanism is the easy part. The hard part is the architecture around it that makes in-memory mutation safe to operate at fleet scale.

Whether $1.50 per CPU core per month is worth it for your fleet is a math problem you can now do. Whether the Confidential VM attestation interaction gets cleanly documented before the next product wave is somebody else's problem. The compiler flag has not changed in 30 years. Everything around it has.

VBS Trustlets: What Actually Runs in the Secure Kernel

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

**Trustlets are the user-mode processes Microsoft places in Virtual Trust Level 1** to hold the secrets a SYSTEM-privilege attacker on the Windows kernel must never reach: NTLM hashes, Kerberos tickets, biometric templates, virtual TPM keys, and (in 2025-2026) just-in-time admin tokens. A binary becomes a trustlet by passing five gates at load time: a process attribute, two specific signing EKUs at Signature Level 12, a `.tpolicy` PE section containing `s_IumPolicyMetadata`, a Trustlet Instance GUID, and a stripped-down loader path. Once loaded, the trustlet talks to the rest of Windows over ALPC, services an agent process in VTL0, and uses only 48 of NT's roughly 480 syscalls. The Hyper-V hypervisor refuses to map its pages into VTL0. That is what "isolated" means.

1. 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 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 and Kerberos Ticket-Granting Tickets sitting in lsass.exe. The user's fingerprint template, in whatever process the Windows Hello biometric pipeline puts it. 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 secrets. Four user-mode processes. And on this 2026 machine, four locked rooms whose pages the operator's kernel write primitive cannot touch and whose contents the operator's kernel does not have permission to ask.

Those four processes are trustlets. They 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. The operator owns the NT kernel; the NT kernel does not own them. That sentence is what changed in 2015, and the rest of this piece 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: the user-mode processes that hold the secrets no longer live in the operating system the attacker compromised. The hypervisor refuses to map their pages into Virtual Trust Level 0 ("VTL0"), and the operator's kernel is in VTL0.

Key idea: Four user-mode processes survive a SYSTEM kernel write primitive on a 2026 Windows 11 box. That is what changed in 2015, and trustlets are the reason.

The promise of this piece is to 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." By the end, four locked rooms will have become something you can name, list, audit, and reason about. Where the public record runs out (some trustlet binary names and IDs are not on Microsoft's published list as of mid-2026), the piece will say so, and it will tell you 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.

2. 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 [@multicians-protection] [@multicians-papers]. The hardware that shipped this design was the Honeywell 6180 in 1973 [@wiki-protection-ring]. 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 [@wiki-multics].

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 [@wiki-hydra]. 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 [@levy-capabook].Hydra's "policy versus mechanism" phrasing still appears verbatim in modern object-capability literature, in the design discussion of WebAssembly's component model, and in seL4's published rationale.

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 [@wiki-l4]. His 1995 SOSP paper "On µ-Kernel Construction" was inducted into the ACM SIGOPS Hall of Fame in 2015 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 [@wiki-l4].

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 [@sel4-sosp-paper]. seL4 was open-sourced in July 2014 [@wiki-sel4]; the seL4 Foundation's About page states plainly that seL4 stands out because of its thoroughgoing formal verification [@sel4-about]. 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.

timeline title User-mode-in-higher-privilege lineage 1972 : Multics 8-ring hardware : Honeywell 6180 ring brackets 1974 : Hydra capabilities 1975 : Policy vs mechanism 1993 : L4 microkernel : Fast user-mode IPC : Windows NT ships ring 0/3 2007 : Vista Protected Processes 2009 : seL4 verification 2013 : Windows 8.1 PPL 2015 : Windows 10 IUM ships : Trustlets 0-3 enumerated 2024 : VBS Enclaves go third-party 2026 : Administrator Protection

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.

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

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 [@wiki-pmp]. 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 [@wiki-pmp]. 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) [@wiki-uwp]. 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 defence 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 [@forshaw-2018]:

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 generalised the Vista mechanism into a signer-level lattice. Each protected process now had a two-dimensional protection level: a signer (WinTcb, Windows, Antimalware, Authenticode, others) and a protection type (PsProtectedSignerTcb, PsProtectedSignerAuthenticode, others). 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 [@msdocs-protecting-am].

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 [@itm4n-runasppl].

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" [@ionescu-ppp3] [@ionescu-ppp1]. 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 [@forshaw-2018]. 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 [@itm4n-runasppl]. 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 [@itm4n-end-of-ppldump]. 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.

Mechanism	Year	Enforcer	Threat model	Defeated by	Status today
Vista Protected Process	2007	NT kernel	Untrusted user code reading DRM-protected media buffers	Signed kernel drivers; Ionescu Jan 2007 [@wiki-pmp]	Superseded by PPL for non-DRM use
AppContainer / LowBox	2012	NT kernel	Untrusted store-app code escaping its capability sandbox	SYSTEM-owned directory creation via service impersonation [@forshaw-2018]	Active for sandboxing untrusted code; not a trustlet substitute
Protected Process Light (`RunAsPPL`)	2013	NT kernel	Userland administrative attacker reading LSASS credential material	`DefineDosDevice` plus Known-DLL hijack; PPLdump 2021 [@itm4n-runasppl]	Active as defence-in-depth; closed in build 19044.1826, July 2022
Isolated User Mode / trustlets	2015	Hypervisor + Secure Kernel	VTL0 kernel attacker reading user-mode secrets	Secure-call interface bugs; agent-side RPC residual [@amar-bh2020]	Active; subject of this article

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:

VBS uses hardware virtualization and the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised. -- Microsoft, OEM VBS hardware requirements [@msdocs-oem-vbs]

Note: RunAsPPL is useful defence in depth. It is not, and has never been, a substitute for Credential Guard. itm4n's 2021 PPLdump release was the proof for the userland half of that statement; signed-driver loaders are the proof for the ring-zero half. If your threat model includes a determined attacker with administrative rights, Credential Guard is the boundary; PPL is the speed bump in front of it [@itm4n-runasppl].

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.

4. July 2015: The Hypervisor Becomes the Arbiter

On 29 July 2015 Microsoft shipped Windows 10 build 10240 [@wiki-win10-history]. 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 [@wiki-hyperv]. 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.

A hypervisor-managed privilege axis added on top of x86's existing ring 0 / ring 3 split. Each VTL has its own kernel mode and its own user mode. Higher VTLs can read and write lower-VTL memory; lower VTLs cannot read or write higher-VTL memory at all. The Hyper-V Top-Level Functional Specification reserves up to 16 VTLs; the current Hyper-V implementation defines `#define HV_NUM_VTLS 2` [@msdocs-vsm].

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" [@msdocs-vsm]. The NT kernel runs in VTL0 ring 0; user-mode applications run in VTL0 ring 3. The Secure Kernel 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 [@quarkslab-virtual-journey].The architectural cap of sixteen VTLs is in the published specification but is not deployed. Stocking the unused slots would require both hypervisor changes and a new design for who manages the additional kernel images. The two-VTL design is the entire shipped product.

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" [@quarkslab-debug-ium].

That sentence is the architectural fact the whole article 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.On Intel hardware, the per-VTL permissions are implemented with Extended Page Tables (EPT); on AMD they use Nested Page Tables (NPT). The hypervisor keeps the per-VTL EPT/NPT entries in its own memory, not in the guest's.

The hardware mechanism (Intel EPT, AMD NPT) that lets a hypervisor define page-level read, write, and execute permissions independent of the guest's own page tables. With VTLs, SLAT entries are per-VTL: a page's permissions when the CPU is executing VTL1 code can differ from the same page's permissions when the CPU is executing VTL0 code. 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. flowchart LR subgraph VTL0["VTL0 (Normal World)"] ring3_0["Ring 3: lsass.exe, vmwp.exe, user apps"] ring0_0["Ring 0: NT kernel + signed drivers"] ring3_0 --> ring0_0 end subgraph VTL1["VTL1 (Secure World)"] ring3_1["Ring 3: LsaIso.exe, vmsp.exe, trustlets"] ring0_1["Ring 0: Secure Kernel (securekernel.exe)"] ring3_1 --> ring0_1 end VTL0 -. ALPC over agent ALPC port .-> VTL1 VTL1 -. read VTL0 memory .-> VTL0 hv["Hyper-V hypervisor: per-VTL SLAT permissions"] VTL0 --> hv VTL1 --> hv

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 in §6) also shipped on the RTM image and were enumerated a week later by Ionescu's Black Hat reverse-engineering [@msdocs-ium] [@ionescu-bh2015]. Microsoft Learn's IUM page introduces the vocabulary the rest of this piece 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 [@ionescu-bh2015-infocondb]. 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 [@ionescu-bh2015]. Almost every concrete fact in the next section -- 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?

5. 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 recognise 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 [@windows-internals-7e-pt2].

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 load-time conditions: a process attribute, two signing EKUs at Signature Level 12, a `.tpolicy` PE section containing `s_IumPolicyMetadata`, a Trustlet Instance GUID, and a stripped-down loader path. Trustlets are sometimes also called "trusted processes," "secure processes," or "IUM processes" [@msdocs-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 [@quarkslab-debug-ium] [@msdocs-ium].

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 honour it [@ionescu-bh2015].

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.

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" [@ionescu-bh2015].

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`) checks the requested EKU against the actual certificate at signature time and refuses to load the image if the EKU is missing or the certificate is not chained to a trusted root [@ionescu-ppp3].

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.The system-component EKU check is skipped when both Test Signing is enabled and the local machine trusts the Microsoft Test Root. That is the exact attack class Ionescu names verbatim in the BH2015 deck: "compromise the platform via Test Signing" disables the signing gate that defines trustlet identity.

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 export 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 [@ionescu-bh2015].

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.

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 [@ionescu-bh2015].

Gate 5: the stripped-down loader

A trustlet's image loader is not the standard NT loader. The Secure Kernel routes trustlet loads through a path 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 roughly fifty allowed entries. Ionescu's deck states the count verbatim: "Only 48 system calls are currently allowed from IUM Trustlets" [@ionescu-bh2015].

sequenceDiagram participant Caller as Caller (VTL1 or brokered VTL0) participant NT as NtCreateUserProcess participant CI as ci.dll (CipMincryptToSigningLevel) participant SK as Secure Kernel (SkpspFindPolicy) participant Ldr as LdrpIsSecureProcess participant Iset as IumSetTrustletInstance Caller->>NT: Create with PsAttributeSecureProcess + Trustlet ID NT->>CI: Verify EKUs System Component plus IUM and Signing Level ge 12 CI-->>NT: Pass or fail NT->>SK: Parse .tpolicy, validate s_IumPolicyMetadata SK-->>NT: Pass or fail NT->>Ldr: Strip down loader and deny VTL0-triggered DLL loads Ldr-->>NT: Image mapped under IUM rules NT->>Iset: Bind Trustlet Instance GUID Iset-->>NT: Trustlet alive in VTL1

Gate	What it checks	Where it lives	Failure outcome
1. Process attribute	`PsAttributeSecureProcess` with 64-bit Trustlet ID, requested via `NtCreateUserProcess`	NT kernel boot path	Normal NT process; no IUM bit ever set [@ionescu-bh2015]
2. EKUs + Signing Level	Windows System Component EKU (`1.3.6.1.4.1.311.10.3.6`) AND IUM EKU (`1.3.6.1.4.1.311.10.3.37`); Signing Level >= 12	`ci.dll` integrity check, `CipMincryptToSigningLevel`	Load refused; no trustlet [@ionescu-ppp3] [@ionescu-bh2015]
3. `.tpolicy` + `s_IumPolicyMetadata`	PE section with version 1, matching Trustlet ID, and per-trustlet policy entries	Secure Kernel `SkpspFindPolicy`	Load refused; no trustlet [@ionescu-bh2015]
4. Trustlet Instance GUID	`IumSetTrustletInstance` secure-call ordinal `0x80000001`; per-partition scoping for vTPM	Secure Kernel runtime	Process exists but cannot bind to per-instance secret storage
5. Loader strip-down	Skip Application Verifier, IFEO, SxS, CSRSS, Safer, AuthZ, SRP; deny VTL0-triggered DLL loads	NT `LdrpIsSecureProcess`	Normal NT loader runs; image loads but is not isolated

The pseudocode below walks each gate in order against a fake binary descriptor. It is not a loader, it is not an exploit, and it is not a security tool. It is a teaching aid: if you can read it, you can read the trustlet load path.

{` // Trustlet load-time gate check (educational pseudocode). // Inspired by Ionescu BH2015 reverse-engineering of Win10 RTM (2015). // Not a real loader; not a security tool.

const WINDOWS_SYSTEM_COMPONENT_EKU = "1.3.6.1.4.1.311.10.3.6"; const IUM_EKU = "1.3.6.1.4.1.311.10.3.37"; const MIN_SIGNING_LEVEL = 12; // "Windows"

function loadTrustlet(bin) { // Gate 1: process attribute if (!bin.attr || !bin.attr.PsAttributeSecureProcess) { return "fail at gate 1: no PsAttributeSecureProcess attribute"; } const requestedId = bin.attr.PsAttributeSecureProcess.trustletId;

// Gate 2: two EKUs at Signing Level 12+ const ekus = (bin.cert && bin.cert.ekus) || []; if (!ekus.includes(WINDOWS_SYSTEM_COMPONENT_EKU)) { return "fail at gate 2: missing Windows System Component EKU"; } if (!ekus.includes(IUM_EKU)) { return "fail at gate 2: missing IUM EKU"; } if ((bin.cert.signingLevel || 0) < MIN_SIGNING_LEVEL) { return "fail at gate 2: signing level below 12"; }

// Gate 3: .tpolicy section with s_IumPolicyMetadata const tpol = bin.sections && bin.sections[".tpolicy"]; if (!tpol || !tpol.exports || !tpol.exports.s_IumPolicyMetadata) { return "fail at gate 3: no .tpolicy section with s_IumPolicyMetadata"; } const meta = tpol.exports.s_IumPolicyMetadata; if (meta.version !== 1 || meta.trustletId !== requestedId) { return "fail at gate 3: malformed or mismatched s_IumPolicyMetadata"; }

// Gate 4: Trustlet Instance GUID (bound at runtime via IumSetTrustletInstance) const instance = bin.runtime && bin.runtime.instanceGuid; if (!instance) { return "fail at gate 4: no Trustlet Instance GUID bound"; }

// Gate 5: stripped-down loader (skip Application Verifier, IFEO, SxS, CSRSS, // Safer, AuthZ, SRP; deny VTL0-triggered DLL loads). // We don't simulate the loader here; we just refuse VTL0-injected DLL loads. if (bin.loaderTriggers && bin.loaderTriggers.fromVtl0) { return "fail at gate 5: VTL0-triggered DLL load denied"; }

return "trustlet loaded: id=" + requestedId + " instance=" + instance; }

// Smoke test. const sample = { attr: { PsAttributeSecureProcess: { trustletId: 1 } }, cert: { ekus: [ "1.3.6.1.4.1.311.10.3.6", "1.3.6.1.4.1.311.10.3.37", ], signingLevel: 12 }, sections: { ".tpolicy": { exports: { s_IumPolicyMetadata: { version: 1, trustletId: 1 }, } } }, runtime: { instanceGuid: "" }, loaderTriggers: { fromVtl0: false }, }; console.log(loadTrustlet(sample)); `}

Key idea: A trustlet is what passes all five gates. There is no other definition. Status is mechanical, not categorical: it is what the Secure Kernel's load path produces when a properly signed binary with a properly formed .tpolicy section calls NtCreateUserProcess with a proper secure-process attribute.

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?

6. The Inbox Roster

Five gates. Pass them all and you become a trustlet. Microsoft passes them on behalf of -- as of mid-2026 -- this list.

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 Asynchronous Local Procedure Call port whose server end is hosted by the trustlet.

A Windows inter-process communication primitive optimised for fast, fixed-size 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. flowchart LR NetClient[Network or local client] Agent["lsass.exe (VTL0 agent)
protocol parsing
session state
network I/O"] SK["Secure Kernel
(VTL1 ring 0)
marshals secure calls"] Trustlet["LsaIso.exe (VTL1 trustlet)
NTLM hashes
Kerberos TGTs
EncryptData / DecryptData"] NetClient -->|"network protocol"| Agent Agent -->|"ALPC: LSA_ISO_RPC_SERVER"| SK SK -->|"IUM Base API"| Trustlet Trustlet -->|"opaque blob"| SK SK --> Agent

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 [@ionescu-bh2015].

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 [@msdocs-credential-guard].

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 [@msdocs-credential-guard].

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. The hash never leaves VTL1. That is the entire point.

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

The Hyper-V Virtual Trusted Platform Module on the host side. 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 [@ionescu-bh2015] [@msdocs-guarded-fabric].

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" [@msdocs-guarded-fabric]. 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.

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 [@ionescu-bh2015]. 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.

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 [@msdocs-ess].

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 architectural placement is a trustlet. The naming is not on the record.

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

In October 2025 Microsoft shipped a preview of Administrator Protection in KB5067036 [@kb5067036] and reverted the rollout in the same update note [@msdocs-admin-protection]. 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 [@msdocs-admin-protection].

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 commitment Microsoft makes for VBS-isolated components. 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.

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

For the first time since 2015, the trustlet primitive is exposed to third-party developers. 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 [@msdocs-vbs-enclaves].

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 identical: the host (the rest of the process, including its VTL0 code) is the attacker, the enclave is the defender [@pulapaka-vbs-enclaves].

Roster table

Trustlet ID	Binary	VTL0 agent	ALPC endpoint	Secret / operation	Source
0	Secure Kernel Process	(internal; no external agent)	(internal)	Device Guard / HVCI policy decisions	[@ionescu-bh2015]
1	`LsaIso.exe`	`lsass.exe`	`LSA_ISO_RPC_SERVER`	NTLM hashes, Kerberos TGTs; `EncryptData` / `DecryptData`	[@msdocs-credential-guard] [@ionescu-bh2015]
2	`vmsp.exe`	`vmwp.exe` (per partition)	per-instance, partition GUID scoped	Hyper-V vTPM, host side; secure storage `Get`	[@ionescu-bh2015] [@msdocs-guarded-fabric]
3	vTPM provisioning trustlet	(Hyper-V provisioning agent)	per-instance, partition GUID scoped	Initial secret provisioning; secure storage `Set`	[@ionescu-bh2015]
(unpublished)	ESS face-algorithm component	Hello biometric pipeline; sensor-issued cert auth	not publicly named	Face template matching (fingerprint matching under ESS is match-on-sensor)	[@msdocs-ess]
(unpublished)	Administrator Protection issuer	UAC / Authorization Manager broker	not publicly named	Just-in-time admin token issuance	[@msdocs-admin-protection]
(third-party)	VBS Enclave DLL	host process (`CreateEnclave` caller)	direct calls via `CallEnclave`	Application-defined; e.g., Azure SQL Always Encrypted	[@msdocs-vbs-enclaves] [@pulapaka-vbs-enclaves]

The published authoritative trustlet list still stops at Trustlet IDs 0-3 from August 2015. Every roster published after that point has been inferred from secondary evidence: kernel symbols, ALPC port enumeration via NtQuerySystemInformation, documented architectural placements. Microsoft has not republished an authoritative roster for any later Windows release.

Two trustlets in the list above are *architecturally* trustlets per Microsoft's published documentation but have not been publicly named or numbered. The ESS face-algorithm matcher is documented to live in VBS-isolated memory, with sensor-certificate authentication and template-encryption keys held in VBS, but the binary's name and Trustlet ID are not on the public record [@msdocs-ess]. The Administrator Protection token issuer's implementation surface is even less precisely specified -- "a hidden, system-generated, profile-separated user account" inside "a new security boundary," but no commitment to whether the issuer is a trustlet, a VBS Enclave, or a separate isolated process [@msdocs-admin-protection]. This article will not invent names or numbers for either. Empirical enumeration via `NtQuerySystemInformation(SystemIsolatedUserModeInformation)` on a current Windows 11 build is the only way to obtain a current roster, and that route is outside the scope of this piece.

Note: Credential Guard prevents the memory-resident NTLM hash or Kerberos TGT from being read out of VTL0. It does not protect typed-in credentials, the agent-side relay surface, plaintext-secret protocols (CredSSP / NTLMv1 / MS-CHAPv2 / Digest), or liveness; the full four-item enumeration with citations lives in Section 10. 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" [@msdocs-credential-guard].

The published roster stops at Trustlet IDs 0-3 from 2015. The actual roster on a 2026 box is bigger. How much bigger Microsoft hasn't said. That is one of the open problems Section 9 will pick up.

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

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 [@wiki-tee].

Intel SGX

Software Guard Extensions launched with the sixth-generation Intel Core processors (Skylake) in 2015 [@wiki-sgx]. 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) [@intel-sdm-sgx]. 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 [@foreshadow-usenix]. The Foreshadow team's site states the consequence:

Foreshadow demonstrates how speculative execution can be exploited for reading the contents of SGX-protected memory as well as extracting the machine's private attestation key... due to SGX's privacy features, an attestation report cannot be linked to the identity of its signer. Thus, it only takes a single compromised SGX machine to erode trust in the entire SGX system. -- Foreshadow project site [@foreshadow-attack-eu]

SGAxe (attestation-key extraction) [@sgaxe], Plundervolt (software-controlled undervolting to fault SGX computations) [@plundervolt], SgxPectre (branch-target injection across the enclave boundary) [@sgxpectre], 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 [@wiki-sgx]. SGX continues on Xeon for confidential cloud workloads but is no longer a target architects pick on Windows clients.The Ultra HD Blu-ray collapse is the closest the SGX deprecation has come to mainstream visibility. PowerDVD's SGX dependency meant that a client SGX deprecation broke a consumer product line, and Cyberlink had to ship updates rerouting around the dropped CPU feature.

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) [@wiki-amd-epyc], and Intel's Trust Domain Extensions (TDX), introduced on 4th-generation Xeon Scalable (Sapphire Rapids, launched 10 January 2023) [@wiki-sapphire-rapids], provide whole-VM confidential computing [@amd-sev-overview] [@intel-tdx-overview]. 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" [@amd-sev-overview]. 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)" [@intel-tdx-overview]. The AMD SEV-SNP whitepaper "Strengthening VM Isolation with Integrity Protection and More" is the canonical technical reference [@amd-sev-snp-whitepaper].

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 on every Cortex-A processor since the mid-2000s -- the Wikipedia ARM architecture article states verbatim that "the Security Extensions, marketed as TrustZone Technology, is in ARMv6KZ and later application profile architectures," the lineage every Cortex-A core inherits [@wiki-arm-architecture]. 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 [@optee-about]. 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" [@optee-about].

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

Concept	Windows VBS / IUM	ARM TrustZone / OP-TEE
Isolation primitive	Hyper-V hypervisor + SLAT	TrustZone Address Space Controller; CPU NS/S bit
Secure-side kernel	Secure Kernel (VTL1 ring 0)	OP-TEE OS (Secure World EL-1)
Secure-side user mode	IUM (VTL1 ring 3)	Trusted Applications (Secure World EL-0)
Agent / supplicant	The trustlet's VTL0 agent (e.g., `lsass.exe`)	`tee-supplicant` and TEE Client API on the Linux side
Trust gate	Microsoft EKUs + Signature Level 12	OP-TEE TA signing key configured at build time

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 [@apple-sep]. 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 [@apple-sep].

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

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 [@sel4-sosp-paper] [@sel4-about]. 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 defence (the DARPA HACMS programme), automotive ECUs, and Qualcomm's Hexagon DSP secure OS.

When to pick which

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

You want	Pick
Protect a user-mode Windows process from a SYSTEM kernel write primitive	Trustlet (inbox) or VBS Enclave (third-party) [@msdocs-vbs-enclaves]
Protect an entire VM from your cloud provider's host	AMD SEV-SNP or Intel TDX [@amd-sev-overview] [@intel-tdx-overview]
Protect a user-mode Linux-on-ARM service from a compromised Linux kernel	TrustZone + OP-TEE Trusted Application [@optee-about]
Hold an iPhone owner's Touch ID / Face ID template safely from iOS	Apple SEP [@apple-sep]
Build a high-assurance system with a machine-checked proof of kernel correctness	seL4 [@sel4-sosp-paper]
Run Intel SGX enclaves on Xeon for confidential cloud	SGX (modulo Foreshadow-class side channels) [@foreshadow-attack-eu]

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?

8. 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 [@amar-bh2020]. 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 [@amar-publications].

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 [@amar-bh2020]. 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 [@nvd-cve-2020-0917] [@nvd-cve-2020-0918] [@amar-bh2020]. 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 [@amar-bh2020].

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 of Section 5 and operates with VTL1 privilege. The trustlet model itself remains intact; the trust roots underneath it are what fail [@ionescu-bh2015].

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:

VTL0 can DOS VTL1 by design. -- Saar Amar and Daniel King, Black Hat USA 2020 [@amar-bh2020]

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" [@lyak-pass-the-challenge]. 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 [@lyak-pass-the-challenge].

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" [@msdocs-credential-guard]. 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 read and write storage blobs the Secure Kernel scopes per-Instance. The pair vmsp.exe and the vTPM provisioning trustlet uses exactly this primitive: provisioning writes, vmsp.exe reads, the Secure Kernel hard-codes which Trustlet IDs may invoke SecureStorageSet versus SecureStorageGet on each Instance GUID. The defence is in the SkCapabilities table; bugs in that table are exploit-class.

In Ionescu's vocabulary, a "malwarelet" is the worst case here: an attacker-controlled trustlet -- enabled by a Secure Boot or Test Signing compromise -- could request access to the Instance GUIDs of other trustlets, and any missing rule in SkCapabilities would let it read what those trustlets stored. There are no public exploits in this class as of mid-2026. There also is not a published audit of the table.

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" [@ionescu-bh2015]. 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 [@wojtczuk-bh2016]. The firmware below VBS is the substrate trustlets sit on; the trustlet model is no stronger than that substrate.

flowchart TD Attacker["VTL0 kernel attacker"] SK["Secure Kernel"] Trustlet["Trustlet (VTL1 user)"] Agent["VTL0 agent process (lsass.exe, vmwp.exe...)"] Substrate["Substrate: UEFI firmware, Secure Boot, signing roots"] Attacker -->|"1. Secure-call interface bugs
CVE-2020-0917, CVE-2020-0918"| SK Attacker -->|"2. DoS by design (out of scope)"| SK Attacker -->|"3. Agent RPC surface
Pass-the-Challenge"| Agent Agent -->|"authentication outcome"| Trustlet Attacker -->|"4. Trustlet-to-trustlet
via shared Instance GUID"| Trustlet Substrate -->|"5. Substrate compromise
malwarelets, BootHole-class"| SK Substrate --> Trustlet

The Hyperseed fuzzer had a prior life. Daniel King and Shawn Denbow first presented it at OffensiveCon 2019 as a hypercall fuzzer [@amar-bh2020]. The retargeting at the secure-call interface is the same tool, pointed at a different parser. The two-weeks-five-bugs result is therefore not "Microsoft wrote bad code" but "a well-built fuzzer aimed at a complex parser will find bugs in ~2 weeks." That is the empirical bar for an unverified TCB.

Key idea: The trustlet model is hypervisor-strong against the VTL0 kernel; it is not stronger than the substrate it sits on. Five attack classes -- secure-call interface bugs, designed-out denial-of-service, the agent RPC residual, trustlet-to-trustlet via shared Instance GUIDs, and substrate compromise -- bound what the model can guarantee. None of them invalidates trustlets; all of them are reasons to deploy trustlets alongside other controls rather than as a sole defence.

The trustlet model has a finite, audited 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?

9. Open Problems

Three things you might expect Microsoft to have published by 2026 -- 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 -- are still partial or missing. 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. Eleven years later, 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 [@quarkslab-debug-ium]; 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 [@ms-everything-old]. The post is unambiguous that a CVE wave is foreseeable as researchers turn their attention to the host-enclave seam. As of the publication of this article 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 [@msdocs-vbs-enclaves].

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 [@foreshadow-attack-eu]. There is no VBS-specific transient-execution mitigation; platform-wide mitigations (Kernel Virtual Address Shadow, Retpoline, Indirect Branch Restricted Speculation) are the only defence. 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 virtualisation to attach to a trustlet under controlled conditions [@quarkslab-debug-ium]; 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" [@msdocs-ium]. The asymmetry favours offence: 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 [@kb5067036] [@msdocs-admin-protection]. 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 standardises 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.

Two answers, both incomplete. The defensive answer: an enumerated trustlet list is an attacker's targeting list, and Microsoft prefers not to publish targeting lists for components whose exact attack surface is still under active study. The historical answer: the 2015 list was a side-effect of Ionescu reverse-engineering Windows 10 RTM. There has been no comparable public reverse-engineering push for any post-2015 Windows release at the same level of completeness, and Microsoft has not chosen to fill the gap with first-party documentation. Empirical enumeration via `NtQuerySystemInformation(SystemIsolatedUserModeInformation)` works on a live system, but doing it on every Windows 11 servicing build is a research programme, not a citation.

These are questions a researcher with a year of grant time could move the field on. The next section is the question a practitioner has today.

10. Practitioner Guide

What changes in a real workflow once you know what a trustlet is? Four short answers.

Windows administrator

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

Note: GUI: Run msinfo32 and check Virtualization-based security Services Running. You should see at least "Credential Guard" and ideally "Hypervisor enforced Code Integrity." PowerShell: Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard. The properties SecurityServicesRunning and VirtualizationBasedSecurityStatus are the load-bearing ones; values of 1 and 2 respectively indicate Credential Guard is running with VBS in full enforcement [@msdocs-credential-guard].

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" [@msdocs-ium] -- the same APIs many EDR products rely on for behavioural 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 virtualisation [@quarkslab-debug-ium]. The empirical enumeration path is NtQuerySystemInformation with class SystemIsolatedUserModeInformation; the structure returned includes a count of running trustlets and their identifying metadata.The driver-side pattern Microsoft documents for "is this process a trustlet?" is IsSecureProcess, an internal Win32K predicate the IUM page names as the canonical check. Tools that need to behave differently against trustlets (memory scanners, integrity checkers, EDR sensors) should call the supported equivalent rather than parsing process attributes by hand [@msdocs-ium].

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 [@msdocs-vbs-enclaves].

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 [@ms-everything-old].

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 [@msdocs-vbs-enclaves-dev-guide].

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 [@vbs-enclave-tooling].

1. Confirm OS support: Windows 11 Build 26100.2314+ or Windows Server 2025+ [@msdocs-vbs-enclaves]. 2. Install Visual Studio 2022 17.9+ and Windows SDK 10.0.22621.3233+. 3. Acquire a Trusted Signing account; configure `signtool.exe` for it. 4. Define `__enclave_config` as `IMAGE_ENCLAVE_CONFIG`; set family/image/SVN fields. 5. Use `veiid.exe` to bind import IDs. 6. Sign the enclave DLL with `signtool.exe` and the Trusted Signing certificate. 7. Test with `IMAGE_ENCLAVE_POLICY_DEBUGGABLE` set; remove it before production. 8. Range-validate every host-supplied pointer; copy before check.

Defender

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

Note: The trustlet protects memory-resident NTLM hashes and Kerberos TGTs from a VTL0 kernel attacker. It does not protect: - Supplied credentials at the logon prompt (keyloggers, screen-scrapers, hardware shimming). - The agent RPC channel (Pass-the-Challenge-class relay against lsass.exe is reachable from VTL0) [@lyak-pass-the-challenge]. - Protocols that require a usable secret in plaintext: CredSSP, NTLMv1, MS-CHAPv2, Digest. These are unsupported with the trustlet-protected token by design [@msdocs-credential-guard]. - Liveness: a VTL0 kernel attacker can stop talking to VTL1 and prevent the trustlet from being available. Denial of service is out of the VBS threat model [@amar-bh2020]. The summary: trustlets shrink the credential-theft attack surface, they do not eliminate it.

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

11. Frequently asked questions

No. Protected Process Light (PPL) and trustlets sit in the same lineage but differ at the architectural level. A PPL is enforced by the NT kernel, which is also the attacker's likely foothold; itm4n's 2021 PPLdump showed the result over eight years of LSASS-as-PPL deployment [@itm4n-runasppl]. A trustlet is enforced by the Hyper-V hypervisor and the Secure Kernel, both running in a different Virtual Trust Level from the NT kernel; a VTL0 kernel write primitive does not touch the trustlet's pages [@quarkslab-debug-ium]. The signing-level lattice is similar (both rely on Signature Level 12); the enforcement architecture is not. Not directly. Inbox trustlets require the Microsoft IUM EKU (`1.3.6.1.4.1.311.10.3.37`), which Microsoft does not grant to third parties [@ionescu-bh2015]. Since Windows 11 24H2, the third-party-shippable equivalent is a VBS Enclave: a DLL signed with a Trusted Signing certificate, loaded into an enclave region of a host process via `CreateEnclave` and `CallEnclave`. The architectural threat model is identical (the host is the attacker, the enclave is the defender); the API surface and the enclave-versus-process model differ. VBS Enclaves require Windows 11 Build 26100.2314 or later, Windows SDK 10.0.22621.3233 or later, Visual Studio 2022 17.9 or later, and a Trusted Signing account [@msdocs-vbs-enclaves]. No. It means that the *memory-resident* NTLM hash or Kerberos TGT cannot be read out of `LsaIso.exe` by a VTL0 kernel attacker. It does not mean credentials are unstealable. Section 10 enumerates the four classes of residual exposure -- typed-in credentials, the agent-side RPC relay (Pass-the-Challenge) [@lyak-pass-the-challenge], plaintext-secret protocols (CredSSP / NTLMv1 / MS-CHAPv2 / Digest are unsupported with the trustlet-protected token), and liveness (denial of service against VTL1 is out of the VBS threat model) -- with citations [@msdocs-credential-guard] [@amar-bh2020]. For that trustlet, yes; for the model, by design. The Secure Kernel plus trustlets are the VBS TCB. Amar and King's 2020 work demonstrated practical VTL0-to-VTL1 vulnerabilities (CVE-2020-0917, CVE-2020-0918) [@amar-bh2020] [@nvd-cve-2020-0917] [@nvd-cve-2020-0918]; Microsoft hardened in response, moving the Secure Kernel pool to segment heap, reducing four W+X regions to +X only, and introducing `SkpgContext` HyperGuard for VTL1 [@amar-bh2020]. The surface remains finite and audited; the trustlet model is hypervisor-strong against the VTL0 kernel and not stronger than the substrate it sits on. Not on ESS-capable systems. The Microsoft Learn page is clear that *"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"* [@msdocs-ess]. The biometric *template* is encrypted with VBS-only keys and lives in VBS-isolated memory. The TPM still has a role -- it holds the per-user Hello *private keys* that authenticate against the local credential provider -- but the biometric template itself does not live in the TPM [@msdocs-tpm]. No. The Microsoft Learn page describes the new model: an authorised user triggers a Windows Hello-backed prompt; Windows then *"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"* [@msdocs-admin-protection]. The in-session prompt is still there; the elevated token's *origin* is what changed (from a split-token impersonation of the same account to a transient system-generated admin account). The October 2025 preview shipped in KB5067036 and was then reverted in the same update note pending a future rollout [@kb5067036]. As of 10 May 2026 the feature is not generally available.

<StudyGuide slug="vbs-trustlets-what-actually-runs-in-the-secure-kernel" keyTerms={[ { term: "Trustlet", definition: "A user-mode process running in VTL1 user mode, scheduled by the Secure Kernel, isolated from VTL0 by per-VTL SLAT permissions. Defined by passing five load-time gates." }, { term: "Virtual Trust Level (VTL)", definition: "A hypervisor-managed privilege axis added on top of x86 rings. Currently two VTLs are implemented out of an architecturally supported sixteen." }, { term: "Isolated User Mode (IUM)", definition: "Ring 3 of VTL1. The user-mode environment trustlets run in. Restricted to about 48 of NT's ~480 syscalls." }, { term: "Secure Kernel", definition: "The kernel that runs in VTL1 ring 0. Schedules trustlets, parses .tpolicy sections, enforces SkCapabilities rules on secure-call invocations." }, { term: "IUM EKU", definition: "The Enhanced Key Usage OID 1.3.6.1.4.1.311.10.3.37. Required alongside the Windows System Component Verification EKU for a binary to be loaded as a trustlet at Signature Level 12." }, { term: "Trustlet Instance GUID", definition: "A runtime identifier the Secure Kernel uses to scope per-instance secrets. Set via IumSetTrustletInstance; shared between cooperating trustlets (e.g., vmsp.exe and the vTPM provisioning trustlet) so they can read each other's storage blobs under SkCapabilities control." }, { term: "Malwarelet", definition: "Ionescu's term for an attacker-controlled trustlet, enabled by a Test Signing or Secure Boot compromise rather than by a trustlet-internal bug." }, { term: "ALPC", definition: "Asynchronous Local Procedure Call: Windows IPC primitive used by VTL0 agent processes to communicate with their VTL1 trustlet counterparts." } ]} questions={[ { q: "Name the five gates a Windows binary must pass at load time to become a trustlet.", a: "(1) PsAttributeSecureProcess process attribute with a 64-bit Trustlet ID. (2) Two EKUs at Signature Level 12: Windows System Component Verification (1.3.6.1.4.1.311.10.3.6) and IUM (1.3.6.1.4.1.311.10.3.37). (3) A .tpolicy PE section exporting s_IumPolicyMetadata with matching Trustlet ID. (4) A Trustlet Instance GUID bound via IumSetTrustletInstance. (5) The stripped-down LdrpIsSecureProcess loader path." }, { q: "Why does a SYSTEM-privilege NT-kernel write primitive on Windows 11 25H2 fail to read LsaIso.exe memory?", a: "Because the NT kernel runs in VTL0, LsaIso.exe runs in VTL1, and the Hyper-V hypervisor configures per-VTL SLAT entries that refuse VTL0 read access to VTL1-only pages. The attacker's kernel write primitive can edit NT kernel structures but cannot change the hypervisor-managed SLAT entries." }, { q: "What does Pass-the-Challenge demonstrate about the limits of Credential Guard?", a: "That while the NTLM hash itself never leaves VTL1, the agent process (lsass.exe in VTL0) can be asked to ask the trustlet to compute an authentication response for an attacker-supplied challenge. The resulting response is reachable by the VTL0 attacker and is sufficient for many relay attacks. The hash is protected; the authentication outcomes it produces are not." }, { q: "What is the practical floor of the trustlet attack surface that Amar and King exposed at Black Hat USA 2020?", a: "The secure-call interface (IumInvokeSecureService) parses VTL0-controlled inputs in VTL1. Hyperseed retargeted at it found five VTL0->VTL1 bugs in two weeks, including CVE-2020-0917 (OOB read in the secure-call surface) and CVE-2020-0918 (SkmmUnmapMdl design flaw). Microsoft responded with segment-heap migration, W+X reduction, and SkpgContext (Secure Kernel HyperGuard)." }, { q: "What is the third-party equivalent of an inbox trustlet on Windows 11 24H2 and later?", a: "A VBS Enclave: a DLL signed with a Trusted Signing certificate and loaded into an enclave region of a host process via CreateEnclave / CallEnclave. Requires Windows 11 Build 26100.2314 or later, Windows SDK 10.0.22621.3233 or later, and Visual Studio 2022 17.9 or later." } ]} />

When SYSTEM Isn't Enough: The Windows Secure Kernel and the End of Total Kernel Trust

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

**The Windows Secure Kernel (securekernel.exe) is a minimal kernel running in a hardware-isolated environment (VTL1) above the main NT kernel, enforced by the Hyper-V hypervisor.** It protects credentials, code integrity, and application secrets even when an attacker has full control of the standard kernel. Born from the failure of software-only defenses like PatchGuard, it represents the biggest architectural shift in Windows security since the original NT reference monitor. It is not invulnerable -- rollback attacks and side-channel vulnerabilities remain open problems -- but it fundamentally changed what "kernel compromise" means on Windows.

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.

Welcome to the world of the Windows Secure Kernel.

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 [@mimikatz-github].

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 reach across this boundary [@ms-vbs].

If kernel mode gives you everything, what could possibly be above kernel mode? The answer requires a 30-year journey through Windows security.

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 core component of the Windows NT security architecture that mediates all access to securable objects (files, registry keys, processes) by checking Access Control Lists (ACLs) against the caller's security token. The SRM runs in kernel mode and enforces discretionary access control for every system operation.

The NT kernel drew a hard line between Ring 3 (user mode) and Ring 0 (kernel mode) [@custer-inside-nt]. 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.Dave Cutler previously designed VMS at Digital Equipment Corporation (DEC). Many NT design principles -- including the SRM, the object manager, and the layered architecture -- trace directly back to VMS. The letters "WNT" are famously one character ahead of "VMS" in the alphabet.

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 [@hoglund-rootkits]. 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 [@sysinternals-story]. Process Explorer, Filemon, and Regmon became essential diagnostic instruments. But visibility is not protection. Defenders could see the problem; they could not stop it.

Key idea: The NT kernel drew one hard line -- user mode versus kernel mode. When attackers crossed that line, there was nothing left to protect. Every security mechanism, every credential, every policy lived in the same flat address space. Microsoft needed to draw a new line.

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.

A software-only kernel integrity monitor introduced in 2005 for 64-bit Windows. PatchGuard periodically checks critical kernel structures (SSDT, IDT, GDT, processor MSRs) for unauthorized modifications and forces a Blue Screen of Death (CRITICAL_STRUCTURE_CORRUPTION) if tampering is detected.

PatchGuard arrived in Windows XP x64 and Windows Server 2003 SP1 in 2005 [@wp-patchguard]. 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.PatchGuard's internal implementation uses extensive obfuscation: randomized check intervals, encrypted context blocks, and self-protecting code that resists static analysis. Microsoft never published its internal design, treating security through obscurity as a deliberate delaying tactic against attackers.

Mandatory kernel-mode code signing followed with Windows Vista x64 in 2007, requiring all kernel drivers to carry a valid Authenticode signature [@ms-kmcs]. Data Execution Prevention (DEP) marked memory pages as non-executable [@ms-dep]. Address Space Layout Randomization (ASLR) randomized the memory layout of loaded modules [@ms-mitigations]. Supervisor Mode Execution Prevention (SMEP) blocked kernel code from executing user-mode memory pages [@ms-mitigations].

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

An attack technique where adversaries install a legitimately signed but vulnerable third-party driver, then exploit the driver's vulnerability to gain arbitrary kernel-mode code execution. Because the driver carries a valid signature, it bypasses kernel-mode code signing enforcement.

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 [@infinityhook-github]. 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 [@ms-vuln-drivers].

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

Benjamin Delpy released Mimikatz in 2011, and the security world was never the same. What began as a proof-of-concept for extracting plaintext passwords from LSASS memory became the single most-used credential theft tool in real-world attacks. Red teams used it. Nation-state actors used it. Ransomware gangs used it. The tool's existence -- more than any theoretical argument -- forced Microsoft to confront the fact that LSASS credentials in a flat kernel address space were indefensible. Credential Guard was Mimikatz's direct response [@mimikatz-github]. PatchGuard was a guard who could be knocked out by the very prisoners it watched. A defense sharing its privilege level with the attacker can always, given sufficient motivation, be subverted.

Key idea: No software-only defense can protect against an attacker at the same privilege level. This is not a fixable bug -- it is a structural limitation. PatchGuard delays attacks; it cannot prevent them. Microsoft needed something that kernel-mode code could not even reach.

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 [@ms-secure-boot]. 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 [@ms-trusted-boot].

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 [@ms-alureon]. 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.

Note: In 2023, ESET researchers confirmed BlackLotus -- the first publicly known UEFI bootkit that bypassed Secure Boot on fully updated Windows systems. It exploited CVE-2022-21894, using a legitimately signed but vulnerable Windows boot manager to load malicious code before the OS [@blacklotus-eset]. The attack demonstrated that even boot-time trust chains can be undermined via BYOVD-style techniques applied to the boot stack itself.

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 [@x86-virtualization]. 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.

A hardware-enforced execution environment created by the Hyper-V hypervisor using Second Level Address Translation (SLAT). VTL0 is the Normal World where the standard NT kernel, drivers, and applications run. VTL1 is the Secure World where securekernel.exe and security-critical trustlets execute. VTL1 memory is physically inaccessible to all VTL0 code, including the NT kernel. A hardware feature (Intel Extended Page Tables / AMD Nested Page Tables) that provides a second layer of virtual-to-physical address translation managed by the hypervisor. SLAT enables the hypervisor to control which physical memory pages each VTL can access, making VTL1 memory invisible to VTL0 without any software-level enforcement that could be bypassed.

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

flowchart TB subgraph VTL1["VTL1 -- Secure World"] SK["securekernel.exe\n(Secure Kernel)"] IUM["Isolated User Mode"] LSAISO["lsaiso.exe\n(Credential Guard)"] ENCLAVE["VBS Enclaves"] IUM --- LSAISO IUM --- ENCLAVE end subgraph VTL0["VTL0 -- Normal World"] NT["ntoskrnl.exe\n(NT Kernel)"] DRIVERS["Kernel Drivers"] LSASS["lsass.exe\n(LSASS broker)"] APPS["User Applications"] end subgraph HV["Hyper-V Hypervisor"] SLAT["SLAT Enforcement\n(Intel EPT / AMD NPT)"] end HV -->|"enforces memory isolation"| VTL1 HV -->|"enforces memory isolation"| VTL0 VTL0 -.->|"Secure Service Calls\n(controlled boundary)"| VTL1

Here is how it works:

At boot, the Hyper-V hypervisor initializes and creates both VTLs.
The standard NT kernel (ntoskrnl.exe), all drivers, and user-mode applications run in VTL0.
securekernel.exe loads in VTL1 kernel mode. It is a minimal, purpose-built kernel that handles only security-critical functions [@ionescu-bh2015].
The hypervisor uses SLAT to make VTL1 memory physically inaccessible to VTL0. No amount of Ring 0 code in VTL0 can read or write VTL1 pages.
Communication between VTL0 and VTL1 occurs only via Secure Service Calls (SSCs) -- controlled hypercalls that cross the VTL boundary under strict validation [@ms-vbs].

A process running in VTL1 Isolated User Mode (IUM), protected from all VTL0 access by hypervisor-enforced memory isolation. The canonical example is lsaiso.exe, the Credential Guard trustlet that holds NTLM hashes and Kerberos tickets in VTL1 where even a fully compromised NT kernel cannot reach them.

securekernel.exe is deliberately minimal. While ntoskrnl.exe is a large general-purpose kernel, securekernel.exe is a much smaller, purpose-built VTL1 kernel whose exact size varies by Windows build. A smaller codebase means a smaller attack surface -- every line of code in VTL1 is a potential entry point for attackers, so Microsoft keeps it as small as possible.

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 [@ionescu-bh2015]. 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 [@wojtczuk-bh2016].

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
Access VTL1 memory or modify Secure Kernel data structures
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.

Credential Guard

When Credential Guard is enabled, NTLM password hashes and Kerberos Ticket-Granting Tickets (TGTs) are stored exclusively in lsaiso.exe -- a trustlet running in VTL1 [@ms-credential-guard]. The VTL0 lsass.exe process acts as a broker: authentication requests from VTL0 are forwarded to lsaiso.exe via secure RPC over the VTL boundary. lsaiso.exe performs cryptographic operations (challenge signing, ticket generation) within VTL1 and returns only the result -- never the raw secret.

sequenceDiagram participant App as Application (VTL0) participant LSASS as lsass.exe (VTL0) participant HV as Hypervisor participant LSAISO as lsaiso.exe (VTL1) App->>LSASS: Authentication request LSASS->>HV: Secure Service Call HV->>LSAISO: Forward to VTL1 LSAISO->>LSAISO: Sign challenge with stored credential LSAISO->>HV: Return signed response (NOT the raw secret) HV->>LSASS: Forward to VTL0 LSASS->>App: Authentication result Note over LSASS: Even SYSTEM access here cannot read VTL1 memory

Even a Mimikatz-wielding attacker with SYSTEM access in VTL0 gets nothing -- the raw credentials never exist in VTL0 memory. Credential Guard is enabled by default on domain-joined, non-DC Windows 11 22H2+ systems that meet VBS hardware requirements [@ms-credential-guard].

HVCI / Memory Integrity

A VBS feature (also called "Memory Integrity") that enforces kernel-mode code integrity from VTL1. HVCI ensures only signed code executes in the kernel and enforces W^X (Write XOR Execute) policy on all kernel memory pages via SLAT. No kernel memory page can be both writable and executable simultaneously. A memory protection policy enforcing that a page can be either writable or executable, but never both simultaneously. HVCI enforces W^X across all kernel memory via SLAT page permissions controlled from VTL1, preventing attackers from injecting and executing arbitrary code in the kernel.

HVCI moves code integrity enforcement from VTL0 into VTL1 [@ms-hvci]. Before any kernel-mode driver loads, its signature is verified by VTL1 code integrity services. HVCI enforces W^X on kernel memory pages using SLAT: page table modifications that would create a writable-and-executable page are trapped by the hypervisor and denied. Even if an attacker achieves kernel execution in VTL0, they cannot load unsigned drivers or make arbitrary kernel memory executable.On newer CPUs, Intel Mode-Based Execution Control (MBEC, Kaby Lake / 7th Gen+) and AMD Guest Mode Execute Trap (GMET, Zen 2+) provide hardware-accelerated W^X enforcement. Older CPUs rely on software emulation ("Restricted User Mode"), which increases overhead.

flowchart TD A["Driver load request\n(VTL0)"] --> B["Signature check\n(VTL1 code integrity)"] B -->|"Valid signature"| C["Set page permissions:\nExecutable + Read-Only"] B -->|"Invalid signature"| D["BLOCKED\nDriver cannot load"] E["Attacker tries to\nmake page W+X"] --> F{"SLAT check\n(Hypervisor)"} F -->|"Violation: W+X"| G["DENIED\nPage remains Read-Only"] F -->|"Valid: W XOR X"| H["Allowed"]

VBS Enclaves

An isolated memory region backed by VTL1 that allows third-party applications to protect secrets from even admin-level OS compromise. The host application in VTL0 communicates with the enclave via the CallEnclave API. Enclave memory is invisible to all VTL0 code, including the NT kernel. Available since Windows 11 24H2.

Starting with Windows 11 24H2, third-party developers can create their own VTL1-protected enclaves -- isolated memory regions for protecting application-level secrets like encryption keys and authentication tokens [@pulapaka-vbs-enclaves]. Unlike Intel SGX, VBS Enclaves require no specialized hardware beyond a VBS-capable CPU [@ms-vbs-enclaves]. Developers define enclave interfaces using EDL (Enclave Description Language) files and build with the VBS Enclave Tooling SDK [@vbs-enclave-tooling].

The development model works like this: you create an enclave DLL, sign it with a Trusted Signing certificate, and load it via the host application. The enclave runs in VTL1 user mode with access to a limited API surface -- no general Windows API access. All inputs from the VTL0 host must be validated and copied into VTL1 before use. Microsoft's developer guide covers the details [@ms-vbs-enclaves-dev], and the VBS Enclave Tooling package provides Rust crate support and Visual Studio 2022+ integration [@vbs-enclave-tooling].

System Guard Runtime Attestation

System Guard extends the trust chain from boot into runtime [@ms-system-guard]. A trustlet running in VTL1 periodically measures the integrity of critical system components -- boot state, kernel integrity, driver signatures -- and signs these measurements using a hardware-backed TPM key. Because the measurement code runs in VTL1, it is protected from tampering by compromised VTL0 code [@ms-system-guard-hw]. Remote attestation services (such as Microsoft Defender for Endpoint) can verify these signed reports to confirm device health -- enabling zero-trust conditional access decisions.

Secured-core PCs

Secured-core PCs integrate hardware, firmware, and VBS into a single security platform requirement [@ms-secured-core]. Certified hardware must include a 64-bit CPU with SLAT, IOMMU for DMA protection, TPM 2.0, UEFI with Secure Boot, SMM protection, DRTM support, and VBS/HVCI enabled and firmware-locked. Major OEMs -- Dell, HP, Lenovo, Microsoft Surface -- ship Secured-core PCs for enterprise and government customers.

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.

Decision Guide

Scenario	Recommended Approach
Protect domain credentials from Pass-the-Hash/Ticket	Enable Credential Guard
Prevent unsigned kernel driver loading	Enable HVCI / Memory Integrity
Protect application-level secrets from admin attacks	Develop a VBS Enclave
Verify device integrity for zero-trust	Enable System Guard Runtime Attestation
Maximum baseline security for new hardware	Require Secured-core PC certification

The Secure Kernel now protects credentials, code integrity, application secrets, and device health. It is deployed across many millions of Windows 11 and Windows Server machines via VBS-by-default. But is it unbreakable?

How Others Solve This Problem: Competing Approaches

Windows is not alone in this challenge. Intel, AMD, and ARM each built their own answer to the same question: how do you protect secrets from a compromised OS? Each made different trade-offs.

Intel SGX

Intel Software Guard Extensions provided hardware enclaves at the CPU level without requiring a hypervisor [@wp-sgx]. Application code and data inside an SGX enclave were encrypted in memory and isolated from the OS, hypervisor, and other applications. The idea was compelling: trust nothing but the CPU itself.

Then side-channel attacks proved the CPU itself was not trustworthy. The Foreshadow attack (2018) exploited L1 Terminal Fault to extract data directly from SGX enclaves via CPU cache side channels [@foreshadow]. Intel deprecated SGX across 11th Gen client CPUs, including Tiger Lake mobile and Rocket Lake desktop, and continued that direction with 12th Gen Alder Lake [@wp-sgx].

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 [@amd-sev]. Even the hypervisor cannot read or remap guest memory without the guest's consent. This is a fundamentally different trust model from VBS: SEV-SNP distrusts the hypervisor, while VBS trusts it. SEV-SNP protects VMs in multi-tenant cloud environments (like Azure Confidential VMs) but does not provide intra-OS isolation within a single machine the way VBS does. The two are complementary, not competing.

Intel TDX

Intel Trust Domain Extensions create hardware-isolated Trust Domains for VMs, excluding the hypervisor from the trusted computing base [@intel-tdx]. The TDX Module runs in a special CPU mode called Secure Arbitration Mode (SEAM) and mediates all interactions between the hypervisor and Trust Domains -- the hypervisor can schedule TD VMs but cannot read their memory or registers. Like SEV-SNP, TDX targets cloud confidential computing rather than intra-OS protection. It complements VBS rather than replacing it.

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) [@arm-trustzone]. 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 has a smaller attack surface (no hypervisor in the path) but is less flexible: 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.ARM TrustZone predates VBS by over a decade. The concept of hardware-enforced dual execution worlds was well established in the mobile/embedded world long before Microsoft applied the idea to desktop Windows. The insight was not the dual-world concept itself, but using the x86 hypervisor to implement it.

Linux

No production equivalent of VBS exists in mainline Linux. Linux relies on Mandatory Access Control (SELinux/AppArmor), container isolation (namespaces/cgroups), and VM-level isolation via SEV-SNP or TDX for cloud workloads. Google's pKVM (Protected KVM) in Android and ChromeOS is the closest parallel -- it uses the hypervisor to isolate a secure VM from the host kernel, similar in spirit to VTL1. Research projects have proposed similar intra-OS isolation for desktop Linux, but none has reached mainline. Linux's security philosophy favors defense-in-depth via many smaller mechanisms rather than a single architectural boundary.

Cross-Platform Comparison

Dimension	Windows VBS	Intel SGX	AMD SEV-SNP	Intel TDX	ARM TrustZone
Isolation granularity	OS-level (VTL split)	Process-level enclaves	VM-level	VM-level	2 worlds
Trusts the hypervisor?	Yes	N/A (no hypervisor)	No	No	N/A
Memory encryption	No (isolation only)	Yes	Yes (full VM)	Yes (full VM)	Varies
Primary use case	Desktop/server OS	Legacy high-assurance	Cloud confidential VMs	Cloud confidential VMs	Mobile/IoT
Status (2025)	Active, expanding	Deprecated on consumer	GA on major clouds	Rolling out	Widely deployed
Known weakness	Rollback, side-channels	Foreshadow, deprecated	Physical attacks	Early deployment	Firmware attacks

Every platform bets on a different trust anchor. VBS trusts the hypervisor. SEV-SNP trusts only the CPU and its encryption keys. SGX trusted the CPU itself -- until side-channel attacks proved that wrong. 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.

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 [@amar-bh2020]. 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 [@amar-publications]. 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 revealed a subtle limitation of Credential Guard [@lyak-pass-the-challenge]. Credential Guard prevents credential extraction -- but it 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 sign challenges on demand.

Note: Credential Guard perfectly isolates secrets in VTL1, but the VTL0 broker (lsass.exe) necessarily provides an interface for using those secrets. Pass-the-Challenge exploits that interface -- not to extract secrets, but to relay them. This is a fundamental design tension: the more useful the isolation boundary, the more attack surface the boundary's API exposes.

Side-Channel Attacks

Spectre and Meltdown demonstrated that speculative execution creates information leakage channels across any software-enforced boundary [@spectre-paper]. VTL0 and VTL1 share the same physical CPU, including caches, branch predictors, and TLBs. Microsoft has deployed microcode updates and software mitigations (IBRS, STIBP, retpolines) [@ms-spectre-advisory], but these reduce the risk rather than eliminating it. Complete elimination requires fundamentally different CPU designs that do not share microarchitectural state across trust boundaries.

The Formal Verification Gap

The seL4 microkernel is formally verified -- mathematically proven correct for approximately 8,700 lines of C code [@sel4-whitepaper]. This means its isolation guarantees are not empirical ("we tested it and found no bugs") but mathematical ("we proved it cannot have certain classes of bugs"). Hyper-V is orders of magnitude larger and more complex. Formally verifying it with current techniques is infeasible. The gap between "extensively tested" and "mathematically proven" is significant: Hyper-V's isolation is empirically strong, not provably correct. A single hypervisor bug could allow VTL escape.

Microsoft's Own Boundary

Microsoft explicitly states in its Security Servicing Criteria that an administrator with physical access is not a security boundary [@ms-servicing-criteria]. 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 [@ms-vbs].

This boundary declaration has practical consequences: it is why CVE-2024-21302 (Windows Downdate) required an opt-in fix rather than an automatic security update -- the attack requires admin privileges.

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 [@leviev-downdate]. The system continues to report itself as "fully patched" while running code with known, exploitable vulnerabilities [@cve-2024-21302]. The attack requires administrator privileges -- which, as we noted, Microsoft does not consider a security boundary.

sequenceDiagram participant Attacker as Attacker (Admin in VTL0) participant WU as Windows Update participant FS as File System participant Boot as Next Boot Attacker->>WU: Hijack update process WU->>FS: Replace securekernel.exe with old version WU->>FS: Replace ci.dll with old version Note over FS: System still reports "fully patched" FS->>Boot: Boot with vulnerable binaries Boot->>Boot: VBS runs with known vulnerabilities Note over Boot: All previously patched bugs are re-exposed

Microsoft does not consider admin-to-kernel a security boundary, which is why CVE-2024-21302 required an "opt-in" fix rather than an automatic security update. Organizations must explicitly deploy KB5042562 to enable rollback protection.

Microsoft responded with KB5042562, publishing a SkuSiPolicy.p7b revocation policy to block loading of outdated VBS-related binaries [@ms-rollback-guidance]. 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 [@leviev-downdate-update]. 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 [@leviev-downdate-update].

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 [@akamai-vbs-weaponization]. The very isolation that protects legitimate secrets can also protect malicious code.

Note: The same VTL1 isolation that makes VBS enclaves secure for legitimate applications makes them invisible to security tools. An attacker who can load a legitimately signed but vulnerable enclave DLL gains a hiding place that no VTL0 security product can inspect. Microsoft is actively hardening the enclave trust boundary [@ms-vbs-enclave-hardening], but the fundamental tension between isolation and visibility persists.

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 [@ms-rollback-guidance]. 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 [@jagt-thesis]. 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) [@ms-vbs-enclave-hardening], 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 [@sel4-whitepaper]. 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 [@spectre-paper]. Some academic designs propose physically separate execution units for different trust levels, but these are years from production.

Note: The theoretically perfect system would combine: a formally verified hypervisor, hardware with no shared microarchitectural state between trust levels, a complete binary revocation mechanism preventing all rollback attacks, and zero performance overhead. Each requirement is individually infeasible today. The Secure Kernel is the best available approximation.

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.

gantt title Windows Kernel Security Evolution dateFormat YYYY axisFormat %Y section Gen 0 NT Kernel (flat trust) :1993, 2005 section Gen 1 PatchGuard (KPP) :2005, 2012 KMCS (driver signing) :2007, 2012 DEP :2004, 2012 ASLR :2007, 2012 SMEP :2011, 2015 section Gen 2 UEFI Secure Boot :2012, 2015 Measured Boot + TPM :2012, 2015 section Gen 3 VBS + Secure Kernel :2015, 2026 Credential Guard :2015, 2026 HVCI / Memory Integrity :2015, 2026 System Guard Attestation :2018, 2026 Secured-core PCs :2019, 2026 section Gen 3.5 VBS Enclaves :2024, 2026

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.

Theory is valuable; practice pays the bills. Here is how to enable, verify, and troubleshoot VBS on your systems.

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 [@ms-vbs]. For optimal HVCI performance, Intel Kaby Lake (7th Gen) or newer (for MBEC) or AMD Zen 2 or newer (for GMET) is recommended [@ms-hvci].

Enabling VBS

VBS can be enabled through:

Group Policy: Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security
Intune/MDM: Use the DeviceGuard CSP or endpoint security policies
Registry: Set HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\EnableVirtualizationBasedSecurity to 1

HVCI/Memory Integrity can be enabled separately via Windows Security > Device Security > Core Isolation > Memory Integrity.

Verifying VBS Status

{` // Simulates Get-CimInstance -ClassName Win32_DeviceGuard // -Namespace root/Microsoft/Windows/DeviceGuard

const vbsStatus = { VirtualizationBasedSecurityStatus: 2, // 0=Not enabled, 1=Enabled but not running, 2=Running RequiredSecurityProperties: [1, 2], // 1=Hypervisor support, 2=Secure Boot AvailableSecurityProperties: [1, 2, 3, 5, 6], // What hardware supports SecurityServicesConfigured: [1, 2], // 1=CredentialGuard, 2=HVCI SecurityServicesRunning: [1, 2], // Which services are active };

const statusNames = { 0: "Not enabled", 1: "Enabled (not running)", 2: "Running" }; const serviceNames = { 1: "Credential Guard", 2: "HVCI / Memory Integrity", 3: "System Guard" };

console.log("VBS Status:", statusNames[vbsStatus.VirtualizationBasedSecurityStatus]); console.log("\nConfigured Security Services:"); vbsStatus.SecurityServicesConfigured.forEach(s => console.log(" -", serviceNames[s] || "Unknown (" + s + ")") ); console.log("\nRunning Security Services:"); vbsStatus.SecurityServicesRunning.forEach(s => console.log(" -", serviceNames[s] || "Unknown (" + s + ")") ); console.log("\nTo check on your system, run in PowerShell:"); console.log("Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root/Microsoft/Windows/DeviceGuard"); `}

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

**Driver compatibility:** Some older drivers violate W^X policy and fail to load with HVCI enabled. Check the Windows Event Log (CodeIntegrity events) for blocked drivers. Microsoft's Hardware Lab Kit (HLK) provides HVCI compatibility testing.

Performance impact: VBS/HVCI adds roughly 5-10% overhead in CPU-bound workloads, especially gaming benchmarks [@vbs-perf]. On modern CPUs with MBEC/GMET, the overhead is lower. For gaming workloads, you may see reduced frame rates in CPU-bound scenarios.

Credential Guard and NLA: Network Level Authentication can fail if Credential Guard is enabled but the domain controller does not support the required Kerberos extensions. Ensure domain controllers are running Windows Server 2016 or later.

Cannot enable VBS: Verify that virtualization is enabled in BIOS/UEFI settings, Secure Boot is on, and TPM 2.0 is present and enabled. Some older systems lack SLAT support.

Note: 1. Open msinfo32.exe and confirm "Virtualization-based security: Running" 2. Check that "Credential Guard" and "Hypervisor enforced Code Integrity" appear under running services 3. Run Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root/Microsoft/Windows/DeviceGuard in PowerShell for detailed status 4. Verify Secure Boot is enabled and TPM 2.0 is present

The Windows Secure Kernel is the most important Windows security feature most people have never heard of. It does not make the headlines that zero-days do. But it quietly changed the fundamental question of Windows security -- from "can we keep attackers out of the kernel?" to "what can we protect even after they get in?" The secrets behind the VTL1 wall remain safe. At least until the next chapter of the arms race.

VBS and HVCI add roughly 5-10% overhead in CPU-bound workloads, with gaming seeing the most noticeable impact [@vbs-perf]. For typical business usage (email, documents, web browsing), the impact is negligible. Modern CPUs with Intel MBEC (Kaby Lake / 7th Gen+) or AMD GMET (Zen 2+) significantly reduce this overhead through hardware-accelerated W^X enforcement. No. securekernel.exe coexists with ntoskrnl.exe. The NT kernel handles all general OS operations -- process management, file systems, networking, device drivers. The Secure Kernel handles only security-critical functions: credential isolation, code integrity enforcement, enclave management. They run in parallel in separate VTLs. No. VBS protects specific assets (credentials, code integrity, application secrets) from a compromised kernel. The NT kernel itself can still be exploited -- an attacker can still gain SYSTEM access, install rootkits in VTL0, and control the standard OS environment. What they cannot do is access VTL1-protected secrets or load unsigned kernel drivers (with HVCI enabled). No. VBS uses the Hyper-V *hypervisor*, not traditional VMs. You can run VBS without creating any virtual machines. The hypervisor runs as a thin layer beneath both VTLs to enforce memory isolation. If you also use Hyper-V VMs, VBS coexists with them. No. Credential Guard protects stored credentials (NTLM hashes, Kerberos TGTs) from extraction, but it does not eliminate the need for strong authentication. It does not protect against phishing, password reuse, or credential relay attacks (as demonstrated by Pass-the-Challenge [@lyak-pass-the-challenge]). Credential Guard is one layer in a defense-in-depth strategy. Not without rebooting. And with Secure Boot and a UEFI lock, VBS cannot be easily disabled even across reboots. However, the Windows Downdate attack demonstrated that VBS *components* can be silently downgraded to vulnerable versions without disabling VBS itself [@leviev-downdate]. Deploying KB5042562 rollback protection mitigates this risk. No. VBS creates isolated execution environments within a single OS instance, not separate VMs. VTL0 and VTL1 share the same OS, the same desktop, the same processes (with the exception of trustlets in VTL1). The isolation is at the memory level via SLAT, not at the OS level. It is more like having a secure safe inside your house than having two separate houses.