Parag Mali - tag: code-signing

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

Authenticode and Catalog Files: The Crypto Foundation Under WDAC

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

Every Windows trust decision -- UAC, SmartScreen, App Control for Business (WDAC), and kernel-mode driver loading -- bottoms out on the same PKCS#7 / CMS `SignedData` envelope that Microsoft shipped with Internet Explorer 3 in August 1996. This article dissects that envelope byte by byte: the `WIN_CERTIFICATE` record inside the PE certificate table, the `SpcIndirectDataContent` attribute that signs a hash rather than a file (which is what makes catalog signing and per-page hashing possible), the RFC 3161 timestamp tokens that keep 2010 signatures verifying in 2026, and the `Microsoft Code Verification Root` kernel chain. We follow the named incidents that drove every post-2010 retrenchment -- Stuxnet, Flame, CVE-2013-3900, ShadowHammer, the 2022 Vulnerable Driver Blocklist, the 2026 Bitwarden CLI npm hijack -- and finish at the WDAC rule levels (`Publisher`, `FilePublisher`, `WHQL`) that finally surface those primitives to administrators as policy.

1. The verified-publisher question

On 17 June 2010, Sergey Ulasen and his colleagues at VirusBlokAda in Minsk began circulating a sample of a worm that would, a month later, be named Stuxnet [@wiki-stuxnet][@stuxnet-dossier]. Two of its kernel-mode components, mrxcls.sys and mrxnet.sys, were signed -- properly, by Authenticode-conformant certificates issued to Realtek Semiconductor Corp. and shortly afterwards by JMicron Technology Corp. [@stuxnet-dossier][@archive-stuxnet-dossier-details]. The Windows kernel loaded them because the certificate chains validated. The chains validated because, cryptographically, nothing was wrong.

That sentence is the lens for everything in this article. Microsoft's code-identity system did its job exactly as designed, and a piece of state-grade sabotage walked through it. The next forty minutes of reading reconstruct what the kernel checks before loading a driver, why those checks could not have caught Stuxnet, and what Microsoft layered on top during the next fourteen years so that the next stolen Realtek private key has less reach.

Where Authenticode shows up

Most Windows users meet Authenticode without realising it. The User Account Control dialog that says "Verified publisher: Microsoft Windows" instead of "Publisher: Unknown" is the user-visible end of a long cryptographic chain that bottoms out in a PKCS#7 / CMS SignedData envelope wrapped inside a WIN_CERTIFICATE record at the end of the PE file [@mslearn-authenticode-driver][@mslearn-pe-format]. The same plumbing is queried by SmartScreen, by App Control for Business (the 2024 rename of Windows Defender Application Control) [@mslearn-appcontrol-root], by ci.dll at kernel-driver load [@mslearn-kmcs-policy], and by Windows Update during servicing. They all read the same bytes in the certificate table; the verdicts differ only in which fields they consult and which policy they overlay.

flowchart TD SD["PKCS#7 / CMS SignedData
(inside WIN_CERTIFICATE)"] UAC["UAC
'Verified publisher'"] SS["SmartScreen
reputation lookup"] WDAC["App Control for Business (WDAC)
rule evaluation"] KMCS["ci.dll / KMCS
kernel-driver load"] SD --> UAC SD --> SS SD --> WDAC SD --> KMCS

Key idea: Every Windows trust statement -- UAC, SmartScreen, App Control for Business, kernel-mode driver loading -- is a query against the same small set of structures inside the PE certificate table. Once you can read those structures, you can predict every later trust decision the OS makes.

What you will be able to do by the end of this article

By the end of section 7 you should be able to decode every line of signtool verify /v /pa /all output and explain, in one paragraph, why Stuxnet still loaded under a fully patched Windows 7 kernel. By the end of section 11 you should be able to run certutil -CatDB, New-CIPolicyRule -FilePath ... -Level FilePublisher, and certutil -hashfile and explain what every byte of their output corresponds to in the on-disk structure.

Stuxnet's kernel components loaded because the chain validated. The chain validated because, cryptographically, nothing was wrong. To understand why that sentence is true -- and what Microsoft has done in the fourteen years since to keep the next stolen Realtek certificate from getting as far -- we have to start in August 1996.

2. 1996: PKCS#7, ActiveX, and the original sin of downloadable code

Counterintuitively, Authenticode was not invented to sign Windows binaries. It was invented to sign downloadable web payloads.

On 7 August 1996, Microsoft and VeriSign jointly announced what their press release called "the first technology for secure downloading of software over the Internet" [@press-pass-1996]. The release introduces Authenticode as a feature of Internet Explorer 3 beta 2, names Hank Vigil ("general manager of the electronic commerce group at Microsoft") and Stratton Sclavos ("president and CEO" of VeriSign), and explicitly anchors the design in open standards: "Authenticode and VeriSign's Digital ID service support Internet standards, including the X.509 certificate format and PKCS #7 signature blocks" [@press-pass-1996]. Six days later, on 13 August 1996, Internet Explorer 3 itself shipped as RTM for Microsoft Windows [@wiki-ie3].

The original motivating problem was ActiveX. An ActiveX control was a downloadable COM binary that the browser would load in-process; without a signature, the browser had no idea who built it. The April 1996 W3C submission that preceded Authenticode is described in the press release as a "code-signing proposal supported by more than 40 companies" [@press-pass-1996]The 40+ company W3C signatory list is the institutional fact that made third-party CA participation possible from day one and seeded the modern multi-vendor code-signing economy. None of the architectural decisions that followed -- catalog signing, RFC 3161 timestamping, EV certificates -- would have been viable inside a single-vendor PKI.. Anchoring the design in X.509 and PKCS#7 instead of inventing a Microsoft-only signature format is the choice that made everything afterwards possible.

PKCS#7 was already there

By 1996, the envelope part of the design was solved. RSA Laboratories had published PKCS #7 v1.5 in November 1993 as part of the Public-Key Cryptography Standards series [@rfc-2315]; in March 1998 the IETF republished it verbatim as RFC 2315, "Cryptographic Message Syntax Version 1.5," authored by Burt Kaliski [@rfc-2315]. The same envelope evolved further: the IETF rebranded it as Cryptographic Message Syntax (CMS) and shipped progressively richer versions through RFCs 2630 (1999), 3369 (2002), 3852 (2004), and 5652 (2009) [@rfc-5652]. Modern Authenticode parsers consume the CMS dialect, but the on-disk envelope structure has barely moved in thirty years.

The ASN.1 envelope -- originally PKCS#7 v1.5 (Kaliski, 1993; republished as RFC 2315 in 1998), now generalised as CMS in RFC 5652 -- that carries the signature, signed and unsigned attributes, and the chain of X.509 certificates inside the Authenticode certificate-table entry [@rfc-5652].

Authenticode is, in one sentence, "PKCS#7 SignedData carrying a Microsoft-defined content type that hashes the PE file in a specific repeatable way" [@authenticode-pe-docx]. The asymmetric signature inside that envelope is RSA, the public-key system Rivest, Shamir, and Adleman published in 1978 [@rsa-1978], built on the Diffie-Hellman digital-signature concept introduced in 1976 [@diffie-hellman-1976]. None of that primitive cryptography has changed since. Everything that has changed sits around the envelope: the algorithms it carries, the catalog store that lets Microsoft sign tens of thousands of files at once, the timestamp tokens that pin a signing moment in time.

flowchart LR DH["Diffie-Hellman (1976)
digital-signature concept"] --> RSA["RSA (1978)"] RSA --> P7["PKCS#7 v1.5
(RSA Labs, 1993)"] P7 --> R2315["RFC 2315 (1998)"] R2315 --> R2630["RFC 2630 (1999)"] R2630 --> R3369["RFC 3369 (2002)"] R3369 --> R3852["RFC 3852 (2004)"] R3852 --> R5652["RFC 5652 / CMS
(2009)"] P7 --> AC["Authenticode
(IE3, August 1996)"] AC --> WC["WIN_CERTIFICATE
in modern PE"]

From one click to four trust decisions

The original UX of Authenticode in IE 3 was a modal trust prompt. The user saw a dialog ("Do you want to install and run [name] signed and distributed by [publisher]?") and clicked Yes or No. The signature was checked once, and that was the entire trust decision. By 2026, the same SignedData envelope feeds at least four entirely different trust subsystems -- UAC, SmartScreen, App Control for Business, kernel-mode code integrity -- and most of the time the user clicks nothing at all.

That layering is what the rest of this article is about. Thirty years on, the on-disk bytes have barely changed. The certificate table at the end of every signed Windows binary still carries a PKCS#7 SignedData envelope, and at the head of that envelope is the same content type -- SpcIndirectDataContent -- Microsoft defined in 1996. What has changed is everything around it: the algorithms inside the envelope, the catalog store, the timestamp tokens, the WDAC policy layer on top. Let's open the envelope and look.

3. Anatomy on disk: WIN_CERTIFICATE, PKCS#7 SignedData, SpcIndirectDataContent

Where does the signature actually live in a signed .exe? Most engineers can guess "the end of the file." Fewer can name the data directory entry, fewer still the wrapper structure, and almost nobody volunteers the exact ASN.1 content type. Four nesting levels matter. Walk them in order and the whole rest of the architecture starts making sense.

Level 1: the PE certificate table

The PE optional header carries a DataDirectory[16] array. Entry index 4, IMAGE_DIRECTORY_ENTRY_SECURITY, points at the certificate table -- an offset and size into the file [@mslearn-pe-format]. Unlike every other data directory entry, the certificate table is the only one whose offset is a file offset, not a relative virtual address; the certificate table is never mapped into memory at load time.

Inside that offset+size region is a sequence of WIN_CERTIFICATE records, each laid out as:

typedef struct _WIN_CERTIFICATE {
    DWORD       dwLength;           // total length of this record, including header
    WORD        wRevision;           // WIN_CERT_REVISION_2_0
    WORD        wCertificateType;    // WIN_CERT_TYPE_PKCS_SIGNED_DATA
    BYTE        bCertificate[ANYSIZE_ARRAY];  // the DER-encoded blob
} WIN_CERTIFICATE;

For Authenticode-signed Windows binaries, wCertificateType == WIN_CERT_TYPE_PKCS_SIGNED_DATA (constant value 0x0002), and bCertificate[] is a DER-encoded CMS / PKCS#7 SignedData blob [@authenticode-pe-docx]. Multiple WIN_CERTIFICATE records are legal; this is how a single binary can carry both a SHA-1 (legacy) and a SHA-256 (modern) signature, or a dual-signed binary carrying both a primary and a nested secondary embedded signature (via the unsignedAttrs nested-signature mechanism).

The PE certificate-table record (`dwLength`, `wRevision`, `wCertificateType`, `bCertificate[]`) that wraps a single attribute certificate inside a PE. For Authenticode signatures, `wCertificateType` is `WIN_CERT_TYPE_PKCS_SIGNED_DATA` and `bCertificate` holds a DER-encoded CMS / PKCS#7 SignedData blob [@authenticode-pe-docx][@mslearn-pe-format].

Level 2: the CMS SignedData envelope

Decoding bCertificate produces an ASN.1 SEQUENCE describing a CMS ContentInfo whose content type is signedData (OID 1.2.840.113549.1.7.2). Inside that is the SignedData structure proper [@rfc-5652]:

version -- an integer, typically 1 or 3.
digestAlgorithms -- the set of hash algorithms used by any signer (commonly sha256).
encapContentInfo -- the content the signers are signing over. This is the field that matters.
certificates -- the X.509 chain certificates needed to validate the signers.
crls -- optional, almost never populated inline.
signerInfos -- one or more SignerInfo structures, each with the actual signature bytes plus signed and unsigned attributes.

Each SignerInfo carries the signing certificate identifier, a set of signedAttrs (whose digest is what gets signed), an encryptedDigest (the actual signature bytes), and a set of unsignedAttrs. The single most important unsigned attribute, in practice, is the RFC 3161 TimeStampToken -- the counter-signature that pegs the signing event to a moment in time. We will come back to that in section 5.

Level 3: SpcIndirectDataContent

The encapContentInfo.eContentType for Authenticode is 1.3.6.1.4.1.311.2.1.4 -- the OID Microsoft registered for SpcIndirectDataContent. Inside, the eContent is a Microsoft-specific ASN.1 structure [@authenticode-pe-docx]:

SpcIndirectDataContent ::= SEQUENCE {
    data        SpcAttributeTypeAndOptionalValue,
    messageDigest DigestInfo
}

SpcAttributeTypeAndOptionalValue ::= SEQUENCE {
    type   OBJECT IDENTIFIER,   -- 1.3.6.1.4.1.311.2.1.15 for PE images
    value  [0] EXPLICIT ANY DEFINED BY type OPTIONAL
}

DigestInfo ::= SEQUENCE {
    digestAlgorithm AlgorithmIdentifier,
    digest          OCTET STRING
}

For a PE binary, data.type is 1.3.6.1.4.1.311.2.1.15 (SPC_PE_IMAGE_DATAOBJ) and data.value carries a SpcPeImageData structure describing what kind of image this is (32-bit, 64-bit, importable, executable). The messageDigest.digest is the Authenticode hash of the PE file [@authenticode-pe-docx]. That hash is not SHA-256 over the file bytes.

Microsoft's `eContentType` registered under OID `1.3.6.1.4.1.311.2.1.4`. Its `messageDigest` field holds the Authenticode hash of the signed artefact, and its `data` field describes what kind of artefact it is (PE image, MSI, script). The fact that this structure signs *a hash* rather than a file is what makes catalog signing possible [@authenticode-pe-docx].

Level 4: the Authenticode hash and its four exclusions

The Authenticode hash is computed over the PE file with four specific byte ranges excluded [@authenticode-pe-docx]:

Excluded region	Why excluded	Spec reference
`OptionalHeader.CheckSum` (4 bytes)	The OS recomputes the optional-header checksum when servicing; signing over it would make every signature invalidate at first patch.	`Authenticode_PE.docx` §3.1 [@authenticode-pe-docx]
`DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY]` (8 bytes)	The pointer to the certificate table itself moves when a signature is added; signing over the pointer is a chicken-and-egg loop.	`Authenticode_PE.docx` §3.1 [@authenticode-pe-docx]
The certificate-table bytes themselves	Same chicken-and-egg loop -- the signature cannot sign itself.	`Authenticode_PE.docx` §3.1 [@authenticode-pe-docx]
File-alignment padding after each section	Padding can be different on different builds for harmless reasons (alignment, build-tool quirks); signing over it would punish those harmless differences.	`Authenticode_PE.docx` §3.1 [@authenticode-pe-docx]

The PE digest computed over the file with four regions excluded: the optional-header `CheckSum` field, the `IMAGE_DIRECTORY_ENTRY_SECURITY` data-directory entry, the certificate-table bytes themselves, and the file-alignment padding after each section. Because the excluded regions include the certificate-table area, the same hash remains valid after the signature is appended [@authenticode-pe-docx].

The exclusion of the certificate-table bytes is the design move that makes the whole architecture work. The Authenticode hash is computed first, signed, and then the signature is appended into the very region the hash excluded. After appending, the hash is still valid; verifying simply recomputes the hash with the same four regions excluded and compares.ASN.1 DER's tag-length-value shape means that, given enough patience, you can decode every level of the certificate table with nothing but a hex dump. This accessibility is also why parser bugs are particularly damaging: a verifier that re-encodes or normalises before hashing can be tricked into hashing different bytes than the bytes that get loaded -- the structural failure mode at the bottom of CVE-2013-3900 [@nvd-cve-2013-3900].

A separate, smaller hash per 4 KiB page

Authenticode supports an optional signed attribute, SpcPeImagePageHashes2, with OID 1.3.6.1.4.1.311.2.3.2 (SHA-256). It carries a sequence of (RVA, hash) pairs, one hash per 4 KiB page of the PE image [@authenticode-pe-docx]. The older 1.3.6.1.4.1.311.2.3.1 SHA-1 variant is effectively deprecated. Under Hypervisor-Protected Code Integrity (HVCI), the page hashes are validated at demand-fault time: when the OS faults in a page from disk, HVCI hashes the page and compares it to the signed page-hash entry before mapping the page as executable. Whole-file integrity checking at load is not the same as runtime integrity checking at fault; page hashes are what closes that gap.ARM64 Windows configurations have used 4 KiB native pages on the systems that ship Authenticode page-hash enforcement to date. The page-hash attribute encodes RVAs into the on-disk image, so any future move to 16 KiB or 64 KiB page granularity would require a corresponding spec revision.

An optional signed attribute (OID `1.3.6.1.4.1.311.2.3.2` for SHA-256) carrying a sequence of `(RVA, SHA-256)` pairs, one per 4 KiB page of the PE image. The hashes are checked at demand-fault time by HVCI / Code Integrity, not just at load time [@authenticode-pe-docx].

The whole nest, in one picture

flowchart TD PE["PE file on disk"] OH["Optional header"] DD["DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY] (entry 4)"] WC["WIN_CERTIFICATE record
(dwLength, wRevision, wCertificateType, bCertificate[])"] SD["PKCS#7 / CMS SignedData"] Certs["certificates: X.509 chain"] SI["SignerInfo"] Sa["signedAttrs"] SIDC["encapContentInfo: SpcIndirectDataContent"] SPI["data: SpcPeImageData (SPC_PE_IMAGE_DATAOBJ)"] MD["messageDigest: Authenticode hash"] PH["SpcPeImagePageHashes2 (optional)"] ED["encryptedDigest: signature bytes"] Ua["unsignedAttrs"] TST["RFC 3161 TimeStampToken
(OID 1.2.840.113549.1.9.16.2.14)"] PE --> OH OH --> DD DD --> WC WC --> SD SD --> Certs SD --> SI SI --> Sa Sa --> SIDC SIDC --> SPI SIDC --> MD SIDC --> PH SI --> ED SI --> Ua Ua --> TST

Try it yourself

Decode the four nesting levels of an Authenticode signature. Requires: pip install pefile asn1crypto

const catalogSignedInboxFile = { Path: "C:\\Windows\\System32\\ntoskrnl.exe", // PowerShell: (Get-AuthenticodeSignature ntoskrnl.exe).SignatureType -> Catalog SignatureType: "Catalog", Status: "Valid", CatalogFile: "C:\\Windows\\System32\\CatRoot\\{F750E6C3-...}\\Microsoft-Windows-Client-Drivers-Package~~31bf3856ad364e35~~amd64~~10.0.x.y.cat", SignerCertificate: { Subject: "CN=Microsoft Windows Production PCA 2011, ..." } };

console.log("Embedded signature:", embeddedSignedBinary.SignatureType, embeddedSignedBinary.CatalogFile); console.log("Catalog signature: ", catalogSignedInboxFile.SignatureType, catalogSignedInboxFile.CatalogFile); `}

Once you can sign a hash instead of a file, and once you can pin a signing event to a moment in time that outlives the certificate, the rest of the architecture stops being a sequence of crypto choices and starts being a sequence of policy choices: which roots do we trust for ring 0, which file-publisher tuples does this enterprise authorise, which drivers does Microsoft deny by hash? To see those policy choices in operation, watch a single WinVerifyTrust call end to end.

6. A modern WinVerifyTrust call, end to end

A user double-clicks a Microsoft-signed .exe on Windows 11 24H2. HVCI is on, Smart App Control is on, an enterprise App Control policy is loaded. The shell calls ShellExecute. Before the OS hands control to the new process, the kernel's code-integrity stack (ci.dll) and user-mode WinVerifyTrust between them answer the question "is this binary trusted?" in roughly the following seven stages.

Stage 1: read the certificate table

ci.dll reads the optional header, finds DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY], walks the certificate-table region, and enumerates the WIN_CERTIFICATE records. Multiple records may be present (e.g. a SHA-1 record for compatibility with Windows 7 verifiers, and a SHA-256 record for modern ones); the verifier picks the strongest record whose algorithm is allowed by current policy [@authenticode-pe-docx][@mslearn-pe-format].

Stage 2: decode the SignedData

For each candidate record with wCertificateType == WIN_CERT_TYPE_PKCS_SIGNED_DATA, the verifier DER-decodes bCertificate into a CMS ContentInfo, then into a SignedData structure [@rfc-5652]. The verifier reads signerInfos, picks the signer (usually one), and extracts the signed and unsigned attributes.

Stage 3: verify the content type

The verifier confirms encapContentInfo.eContentType == 1.3.6.1.4.1.311.2.1.4 (SpcIndirectDataContent), then decodes the inner structure and confirms data.type == 1.3.6.1.4.1.311.2.1.15 (SPC_PE_IMAGE_DATAOBJ) [@authenticode-pe-docx]. The inner messageDigest is the Authenticode hash this signature claims to cover; the digestAlgorithm says how it was computed.

Stage 4: recompute the Authenticode hash

The verifier re-reads the PE file bytes, applies the four exclusions (CheckSum, the SECURITY data-directory entry, the certificate-table bytes, and section-padding), hashes the remaining bytes with the claimed algorithm, and compares to SpcIndirectDataContent.messageDigest [@authenticode-pe-docx]. If they differ, the signature is rejected.

Stage 5: validate page hashes under HVCI

If SpcPeImagePageHashes2 is attached and the running policy includes HVCI, the page-hash table is preserved across the verification call and consulted later by the secure kernel at demand-fault time [@authenticode-pe-docx]. The full-file Authenticode hash check is necessary but not sufficient for runtime integrity; pages on disk can be tampered after load by a kernel-level attacker who bypasses file-system protections. Page hashes are what closes that gap by re-checking each page at the moment it is mapped executable.

Stage 6: build the chain

The verifier collects the certificates SET from the SignedData, plus any AIA-fetched certificates needed to complete the chain, and tries to terminate the path at a trusted root. For kernel-mode loads, the legacy anchor is the Microsoft Code Verification Root; for portal-signed drivers, the chain may instead terminate at one of the Microsoft Root Authority anchors. The KMCS policy page describes the Windows 10 1607+ kernel-mode anchors verbatim: "Microsoft Root Authority 2010, Microsoft Root Certificate Authority, Microsoft Root Authority" with Secure Boot on [@mslearn-kmcs-policy]. For user-mode loads, the chain may terminate at any root in the system Trusted Root store; the enterprise's App Control policy narrows the trust further by referencing specific anchors at the RootCertificate / PcaCertificate rule level [@mslearn-select-types-of-rules].

The CryptoAPI function (`wintrust.dll!WinVerifyTrust`) that orchestrates the Authenticode verification pipeline: certificate-table read, SignedData decode, content-type check, Authenticode-hash recomputation, optional page-hash association, chain build, catalog fallback for unsigned PEs, and timestamp validation. It returns a success or specific error code; the caller (UAC, SmartScreen, `ci.dll`, WDAC) interprets the result against its own policy. The Windows kernel-mode component that enforces the Kernel-Mode Code Signing policy on driver loads (Vista x64 and later [@wiki-kernel-patch-protection][@mslearn-kmcs-policy]) and, under HVCI, evaluates page hashes at fault time. `ci.dll` is the kernel-side caller of `WinVerifyTrust` semantics for driver loads. The historical kernel-mode trust anchor whose name appears in Microsoft's KMCS documentation and whose intermediate cross-signed third-party code-signing CAs for pre-July-2015 drivers [@mslearn-kmcs-policy]. Microsoft Learn does not publish a single canonical page with the root's SHA-1 / SHA-256 thumbprint, validity dates, or issuance year; in practice the thumbprint is read by running `certutil -store` on a recent Windows system.

The Microsoft Code Verification Root metadata absence is real: although the root is named in the KMCS policy document [@mslearn-kmcs-policy], no Microsoft Learn URL publishes its thumbprint or validity dates on a stable page. Practitioners should reference the root by name in policy and treat the actual thumbprint as something to be enumerated via certutil -store on the running system rather than copy-pasted from a published document.

Stage 7: catalog fallback for unsigned PEs

If the PE has no embedded signature, the verifier computes the Authenticode hash and queries CryptSvc: is this hash a member of any installed catalog under %SystemRoot%\System32\CatRoot\? If yes, the verifier uses the catalog's signer as the effective signer for the PE [@mslearn-catalog-files][@mslearn-authenticode-driver]. Cross-system files installed by Windows Update (most drivers, most inbox executables) take this path.

Stage 8: validate the RFC 3161 timestamp

If the unsigned attributes carry a TimeStampToken (OID 1.2.840.113549.1.9.16.2.14), the verifier decodes it, validates the TSA's chain, extracts genTime, and confirms the signing certificate was valid at genTime [@rfc-3161]. This is how a 2010 signature still verifies in 2026: not because the 2010 certificate is still valid, but because a TSA attested at signing time that the signature existed when the certificate was valid.

Stage 9: WDAC policy evaluation

With cryptographic verdicts in hand, the App Control policy engine evaluates the file against the active policy: does any allow rule match, does any deny rule match, including the default-on Vulnerable Driver Blocklist supplemental deny [@mslearn-recommended-driver-block-rules]? The matching rule -- by Hash, FileName, Publisher, FilePublisher, WHQL, WHQLPublisher, WHQLFilePublisher, LeafCertificate, PcaCertificate, or RootCertificate level [@mslearn-select-types-of-rules] -- decides the final outcome. Audit-mode hits produce event ID 3076; enforcement-mode blocks produce event ID 3077 [@mslearn-event-id-explanations].

Stage 10: legacy parser hardening, if opted in

A hardened environment will also have EnableCertPaddingCheck=1 set [@nvd-cve-2013-3900], enabling the strict parser that rejects the CVE-2013-3900 appended-data form. CISA added the CVE to its Known Exploited Vulnerabilities catalogue on 10 January 2022 with a federal due date of 10 July 2022 [@nvd-cve-2013-3900]; environments subject to federal compliance regimes treat this as mandatory.For practitioners: the registry key needs to be set in both HKLM\Software\Microsoft\Cryptography\Wintrust\Config and the matching Wow6432Node path, because the 32-bit and 64-bit WinVerifyTrust code paths read separate copies. Setting only one and rebooting is one of the more common configuration mistakes in hardened-baseline rollouts.

flowchart TD Start["ShellExecute / driver load"] CT["Read PE certificate table"] Decode["Decode WIN_CERTIFICATE -> CMS SignedData"] OID{"eContentType =
SpcIndirectDataContent?"} Hash["Recompute Authenticode hash"] HashOK{"Hash matches
messageDigest?"} Chain["Build certificate chain"] Cat["Catalog fallback?
(if PE unsigned)"] TS["Validate RFC 3161 token"] PHash["Associate SpcPeImagePageHashes2
(HVCI fault-time check)"] Pol["WDAC policy evaluation"] EPC["EnableCertPaddingCheck
strict parser (if opt-in)"] Done["LOAD or DENY"] Start --> CT --> Decode --> OID OID -->|yes| Hash OID -->|no| Done Hash --> HashOK HashOK -->|yes| Chain HashOK -->|no| Done Chain --> Cat --> TS --> PHash --> EPC --> Pol --> Done

Note: There is no separate certificate table per trust subsystem. UAC, SmartScreen, ci.dll, WDAC, and the catalog-fallback path all read the same bytes inside the same WIN_CERTIFICATE record. What differs is which fields each consumer cares about and what policy each consumer overlays on top. Once you read the on-disk structures, every later trust decision is predictable.

`WinVerifyTrust` does not execute the binary. It does not appraise behaviour or reputation -- that is SmartScreen's job, downstream. It does not verify runtime page integrity -- HVCI does, in the secure kernel, at demand-fault time. It does not enforce the App Control policy -- the policy engine does, downstream. It does not check OCSP unless the caller opts in; chain-revocation behaviour is governed by `WinVerifyTrust` flags supplied by the caller. The function answers only the narrow cryptographic question: does the SignedData blob parse, does the recomputed hash match, does the chain build, and (if a token is attached) did the signing event happen inside the signing certificate's validity window?

By the seventh stage of this pipeline, the answer to "is this binary trusted?" is no longer a yes-or-no statement about cryptography. It is a composite of cryptographic verdicts (signature integrity, hash match, chain build, timestamp validity, page hashes) and policy verdicts (allowed by WDAC, not on the blocklist). Authenticode supplies the inputs to a policy; WDAC writes the policy. Let us look at the policy language.

7. WDAC rule levels: Authenticode as policy input, not policy itself

App Control for Business (WDAC) is where the Authenticode primitives finally surface to administrators as policy. The SignerInfo, the subject CN of the leaf certificate, the file's OriginalFileName and ProductVersion from the version resource, the page-hash table, even the choice of catalog signer -- all of them become inputs to a small rule language.

Rule levels: what Authenticode field each level consults

The verbatim rule-level catalogue from Microsoft Learn is [@mslearn-select-types-of-rules]:

Rule level	Authenticode field(s) consulted	Example use case
`Hash`	Authenticode hash of the file	Pinning a single binary by exact bytes; brittle across patches.
`FileName`	`OriginalFileName` from the PE version resource	Convenience for inbox files; not cryptographic.
`FilePath`	Filesystem path	UNC or absolute path; not cryptographic. Use sparingly.
`SignedVersion`	Publisher + `OriginalFileName` + version range	Allow a publisher's binary at a given version or higher.
`Publisher`	Issuing CA + leaf-cert subject CN	Allow anything signed by a given vendor under a given CA.
`FilePublisher`	Publisher + `OriginalFileName` + minimum `FileVersion`	Allow a specific binary from a specific vendor at min version.
`WHQL`	The Windows Hardware Quality Labs EKU	Allow any WHQL-signed driver.
`WHQLPublisher`	WHQL EKU + leaf-cert subject CN	Allow WHQL drivers from a specific OEM.
`WHQLFilePublisher`	WHQL EKU + `OriginalFileName` + min `FileVersion`	The strictest driver rule.
`LeafCertificate`	Leaf cert subject + issuer	Pin to a specific signing cert.
`PcaCertificate`	The PCA (intermediate) cert	Useful for "anything Microsoft-signed" without enumerating leaves.
`RootCertificate`	The root anchor	Broadest; usually too coarse.

Policy options

App Control policies are XML documents with a <Rules> section that toggles broad behavioural options [@mslearn-select-types-of-rules]:

0 Enabled:UMCI -- "App Control policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts" [@mslearn-select-types-of-rules].
2 Required:WHQL -- "By default, kernel drivers that aren't Windows Hardware Quality Labs (WHQL) signed are allowed to run. Enabling this rule requires that every driver is WHQL signed and removes legacy driver support" [@mslearn-select-types-of-rules].
8 Required:EV Signers -- documented but, per the same Microsoft Learn page, "This option isn't currently supported."The Required:EV Signers option is in every published rule-options table but never makes it past parsing today. The EV requirement is enforced contractually via the Hardware Developer Center submission gate, not via the rule option. Treat it as documentation of intent rather than runtime enforcement.

The Vulnerable Driver Blocklist is shipped as a supplemental deny policy that overlays the user's primary policy. From Windows 11 22H2 onward it is default-on and automatically enforced under HVCI, Smart App Control, or S Mode [@mslearn-recommended-driver-block-rules]. Updates arrive quarterly. The blocklist is deliberately conservative: Microsoft's own documentation acknowledges "It's often necessary for us to hold back some blocks to avoid breaking existing functionality while we work with our partners who are engaging their users to update to patched versions" [@mslearn-recommended-driver-block-rules].

The post-2024 rename of Windows Defender Application Control [@mslearn-appcontrol-root]; a code-integrity policy language that consumes Authenticode primitives (chain, leaf-cert subject, `OriginalFileName`, version, WHQL EKU, page-hash table, embedded-vs-catalog provenance) as inputs to administrator-authored allow and deny rules. A WDAC rule level that allows or denies a binary if it is signed by a given Publisher (issuing CA + leaf-cert subject CN) **and** the PE's `OriginalFileName` matches **and** the PE's `FileVersion` is at or above a minimum. The tightest commonly used rule level; brittle across self-updating applications whose binaries change without warning [@mslearn-select-types-of-rules][@mslearn-use-code-signing].

A worked example

Generating a FilePublisher rule for a Microsoft-signed binary on PowerShell:

New-CIPolicyRule -FilePath "C:\Path\To\App.exe" -Level FilePublisher

produces a <FileRule> whose XML carries the issuing CA, the leaf-cert subject CN, the OriginalFileName from the version resource, and a MinimumFileVersion attribute. Every one of those fields is a direct read of the Authenticode SignerInfo and the PE version resource; nothing in the rule generation step talks to Microsoft. The administrator owns the rule.

Note: Microsoft's own guidance is verbatim: "Be aware of self-updating apps, as their app binaries may change without your knowledge" [@mslearn-use-code-signing]. FilePublisher rules pin a minimum version; if a self-updating app rolls out a build with a different OriginalFileName casing, or with ProductVersion changes that some packagers reuse as FileVersion, the rule silently stops matching. For self-updating apps, prefer Publisher (CA + subject CN only) and accept the looser blast radius.

Operational tip: audit-mode hits write event ID 3076 to the Microsoft-Windows-CodeIntegrity/Operational channel, enforcement-mode blocks write event ID 3077 [@mslearn-event-id-explanations]. Stage every policy in audit mode for at least one full patch cycle before flipping to enforcement; the 3076 stream is your inventory of what the rules would have denied.

WDAC's vocabulary makes one structural choice explicit that the article has been implicit about until now: trust is administrator-authored, not vendor-authored. The cryptographic identity is supplied by the same Authenticode primitives we just dissected; the policy is whatever the organisation writes. Before we look at the limits of what this stack can prove, one quick detour into how other operating systems have approached the same problem.

8. Catalog-vs-embedded across operating systems

Windows is unusual in two specific ways: it stores the catalog on the endpoint, and it refreshes the catalog through the OS update channel. No other mainstream OS does both.

System	Signature carrier	Catalog model?	Transparency log?	Counter-signing for longevity
Windows (Authenticode)	PKCS#7 / CMS SignedData inside `WIN_CERTIFICATE`	Yes -- `.cat` files in `CatRoot`, refreshed by Windows Update [@mslearn-catalog-files]	No	Yes -- RFC 3161 token as unsigned attribute [@rfc-3161]
macOS	Apple-issued code signature + Notarization ticket; ticket stapled to artefact or fetched online [@apple-notarization]	No -- Notarization ticket attests, but there is no on-disk "list of hashes" structure	No	Stapled ticket effectively gives a signing-time guarantee; no third-party TSA
Linux IMA / EVM	Extended-attribute signatures on individual files [@linux-ima-wiki]	No -- per-file `security.ima` xattr	No	Out of scope; appraised against locally trusted keyring
Android	APK Signature Scheme v3 (block inside the APK) [@android-apk-v3]	No	No (signatures live inside the APK)	Proof-of-rotation chain inside the v3 block lets a publisher rotate keys without re-signing
sigstore (OCI artefacts)	Detached signature in OCI registry; short-lived Fulcio cert [@sigstore-overview]	Closest analogue -- detached signature can cover blobs [@cosign-blobs]	Yes -- Rekor [@rekor-github]	TSA-style entries possible via Rekor

The closest design analogue to the Windows catalog model is sigstore. Both decouple the signature from the artefact, and both let a single signing event cover many files. The difference is where the detached signature lives. Windows puts the .cat on the endpoint and refreshes the catalog through the OS update channel; sigstore stores the detached signature in an OCI registry and writes an attestation to a Rekor transparency log. That difference is also what gives Windows the offline-stale-catalog problem (a disconnected endpoint cannot freshness-check CatRoot) and gives sigstore the offline-no-Rekor problem (a disconnected verifier cannot consult the log).Readers who want the broader cross-platform identity comparison should consult the earlier App Identity in Windows article in this series, which compares Apple's package identity, Android's app IDs, and Linux's lack of a unified equivalent in more depth. The present article only summarises the signature-carrier side of the comparison.

Whether Microsoft puts the catalog on the endpoint or in an OCI registry is a deployment choice. The limit of what any signature -- catalog, embedded, sigstore-anchored, Apple-notarised -- can prove is a deeper, more uncomfortable claim. We turn to that next.

9. What signatures cannot prove

Stuxnet did not break Authenticode. It walked through it. The same is true of Flame, of ShadowHammer, and of the Bitwarden CLI npm hijack. Every named incident on the modern Windows code-signing timeline is an instance of the same structural lower bound: signatures prove who, not what. The Windows code-identity stack has spent fourteen years adding layers that narrow the consequences of that bound. None of them eliminate it.

Four limits are worth naming explicitly.

L1. Provenance is not safety

By Rice's theorem corollary, no decision procedure can determine arbitrary non-trivial semantic properties of a program. A signing system can therefore certify only "this binary came from a key-holder," never "this binary is benign." Stuxnet 2010 [@stuxnet-dossier], Flame 2012 [@stevens-counter-cryptanalysis][@ms-advisory-2718704], Operation ShadowHammer 2019 [@securelist-shadowhammer], and the Bitwarden CLI npm hijack of 22 April 2026 [@bitwarden-statement][@stepsecurity-bitwarden][@hackernews-bitwarden] are four independent instances of the same gap, across four entirely different attack surfaces (stolen kernel-driver key; forged sub-CA via MD5 collision; compromised ASUS Live Update certificate; compromised npm OIDC trusted-publishing). The empirical scale is large: Kim, Kwon, and Dumitraș measured millions of certificates and hundreds of thousands of signed-but-malicious PE samples in the Windows code-signing PKI in their CCS 2017 paper [@dumitras-ccs-2017].

The mathematics of Rice's theorem is succinct. Let $P$ be any non-trivial semantic property of programs (e.g. is malicious). For any algorithm $A$ that on input program $p$ outputs $A(p) \in {\text{yes}, \text{no}}$ claiming whether $p$ has property $P$, there exists a program $q$ where $A(q)$ is wrong. A signature scheme is not such an algorithm $A$ in the first place: it computes $\text{Sig}_{\text{sk}}(\text{hash}(p))$. The signature output has no semantic content about $p$'s behaviour; it asserts only that the holder of $\text{sk}$ touched $\text{hash}(p)$.

L2. CA cardinality and the weakest-link property

The trust graph for kernel-mode loads is narrow: a small number of Microsoft roots [@mslearn-kmcs-policy]. The trust graph for user-mode loads is the union of every root in the system Trusted Root store -- a much larger set. Any one root, if compromised, degrades the entire user-mode code-identity trust graph; any one sub-CA, if forged, opens the kernel-mode path for the lifetime of the certificate. The Sotirov / Stevens / Appelbaum / Lenstra / Molnar / Osvik / de Weger rogue-CA work from December 2008 [@hashclash-rogue-ca] demonstrated this dynamic for the web PKI; the same family of attack was then mounted in Flame in 2012 against the Microsoft Enforced Licensing Intermediate PCA [@ms-advisory-2718704]. The CSBR's EV-on-hardware requirements [@cabf-cs-documents] reduce stolen-key risk at the leaf level, but a forged sub-CA bypasses the leaf entirely.

L3. Catalog-store freshness on disconnected endpoints

A disconnected endpoint cannot freshness-check its CatRoot. The catalog database is whatever Windows Update last delivered -- which means freshly issued catalogs covering newly shipped inbox files cannot be trusted on machines that have been offline. The Vulnerable Driver Blocklist faces the same problem in reverse: a freshly blocked driver does not become un-trusted on a disconnected endpoint until the supplemental policy lands. Microsoft acknowledges this in the VDB documentation: "It's often necessary for us to hold back some blocks to avoid breaking existing functionality" [@mslearn-recommended-driver-block-rules]. The publication lag is deliberate, not accidental, and there is no in-band way for an endpoint to ask "is my VDB current?"

L4. TSA centralisation and antedating

RFC 3161 has no transparency log. A compromised TSA can issue countersignatures with arbitrary genTime undetectably, until and unless the TSA's root is revoked. Sigstore Rekor [@rekor-github] is the canonical answer to this problem in the OSS world; nothing equivalent ships in the Authenticode stack. The consequence is asymmetric: a compromised TSA can antedate a signature backwards, making a freshly signed but recently malicious binary appear to have been signed before the malicious campaign began -- which on most verifiers means it will still verify even after the actual signing certificate is revoked.

flowchart TD L1["L1: Provenance != safety
(Rice's theorem corollary)"] L2["L2: CA cardinality
(weakest-link property)"] L3["L3: CatRoot freshness
(offline endpoints stale)"] L4["L4: TSA centralisation
(no transparency log)"] Floor["What is actually being proved:
a key-holder touched hash(p) at genTime"] L1 --> Floor L2 --> Floor L3 --> Floor L4 --> Floor A valid signature proves only who signed the binary, never what the binary does.

Key idea: Authenticode is the floor of Windows trust, not the ceiling. Every later layer -- Kernel-Mode Code Signing, App Control for Business, the Vulnerable Driver Blocklist, HVCI page-hash enforcement -- exists because the floor cannot, by construction, do more.

Stuxnet 2010, Flame 2012, ShadowHammer 2019, and Bitwarden CLI 2026 are four instances of the same lower bound, fourteen years apart, across four entirely different surfaces: a stolen private key for a kernel driver; a forged Microsoft sub-CA via cryptographic collision; a compromised ASUSTeK signing certificate used to sign a malicious updater; a compromised npm OIDC trusted-publishing pipeline used to publish a malicious CLI release. In each case the signature was valid. In each case the binary was malicious. The layers we add -- cross-signing deprecation, EV-on-hardware, the VDB, WDAC -- do not close the gap. They reduce the blast radius of the inevitable next incident.

Once you see provenance and safety as separate questions, every open problem in the code-signing stack lines up in one direction: how do you reduce the blast radius of the inevitable next valid-but-malicious signature?

10. Open problems

Five problems are concrete enough to call out as ongoing work.

O1. Post-quantum Authenticode. Microsoft has not yet published a SpcIndirectDataContent variant that references the ML-DSA (FIPS 204 [@fips-204]) or SLH-DSA (FIPS 205 [@fips-205]) OIDs. The CA/B Forum CSBR has not named a post-quantum algorithm for code-signing certificates; the current CSBR v3.8 [@cabf-cs-documents] still rests on RSA and ECDSA. NIST's PQC programme has set a 2035 deadline to deprecate quantum-vulnerable algorithms [@nist-pqc]. The CMS extensibility precedents are there: RFC 8554 profiles stateful LMS [@rfc-8554], RFC 8419 profiles EdDSA in CMS [@rfc-8419], and there is no architectural reason the same approach cannot profile ML-DSA. A hybrid-signed binary that carries both an RSA and an ML-DSA SignerInfo inside the same SignedData is technically possible today, and Microsoft will likely have to ship it before catastrophic loss of confidence in RSA can happen.FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) were both finalised on 13 August 2024 [@fips-204][@fips-205]. The standards are stable; what is missing is the Authenticode-side OID registration and the Hardware Developer Center portal-signing pipeline that would emit a PQ counter-signature. The CSBR side and the Microsoft side both have to move; neither has publicly committed to a date.

O2. Per-page integrity for non-PE artefacts. Page hashes inside SpcPeImagePageHashes2 [@authenticode-pe-docx] are PE-specific. PowerShell scripts, MSIX packages, Appx packages, and the .cat files themselves rely on whole-file Authenticode hashing; if an attacker can corrupt a single byte after load, the OS does not currently re-hash. HVCI gives PE binaries a runtime check; the script and package side does not yet have an equivalent.

O3. Transparency logs for Authenticode countersignatures. RFC 3161 TSAs do not publish their issued tokens. A backdated countersignature from a compromised TSA is currently undetectable beyond CA revocation. Sigstore Rekor [@rekor-github] demonstrates that a transparency log integrates with a signing pipeline at low overhead; there is no equivalent for the Microsoft-signed-driver world or for third-party Authenticode signers.

O4. Revocation propagation latency. The gap between "the CA revokes" and "every endpoint refuses to verify" is empirically days to weeks. CRLs are downloaded on a cadence (with EnableCertPaddingCheck aside, OCSP is not even applied to Authenticode by default). The VDB's quarterly cadence [@mslearn-recommended-driver-block-rules] is faster than CRL-only and slower than the rate at which attackers can stand up an attack with a freshly stolen certificate. Some of this is unavoidable -- you cannot push a revocation faster than an offline endpoint can reach Windows Update -- but a structurally better answer is one of the open questions.

O5. Post-CrowdStrike (July 2024) kernel-driver-loading discipline. Microsoft's Windows Resiliency Initiative was announced in the wake of the 19 July 2024 CrowdStrike Falcon Sensor outage; a fully-specified replacement for today's third-party kernel-driver model has not yet shipped. A successful answer would push parts of today's Authenticode + KMCS + WDAC story toward sandboxed user-mode driver frameworks, with the kernel restricted to a much narrower interface. The Authenticode primitives this article has dissected will still be the substrate; what gets layered on top is the open architectural question.

Note: This article is about the crypto foundation under WDAC: the bytes on disk, the envelope structures, the chain of trust. It does not cover the runtime enforcement layer -- how Code Integrity, HVCI, and the secure kernel use these primitives at process- and driver-load time, how page hashes are checked at fault time, how the Vulnerable Driver Blocklist is loaded as a supplemental policy. That story is the subject of the next post in this series.

The next decade of Windows code-signing is going to be dominated by post-quantum migration and by whatever the Windows Resiliency Initiative converges to. Both will be evolution, not revolution: they will sit on top of the certificate-table, catalog-store, and timestamp-token primitives that have been load-bearing since 1996. To finish, the day-to-day commands that interrogate every byte we have discussed.

11. Practical guide: signtool, certutil, New-CIPolicyRule

If you have read this far, you should be able to run the following commands on a Windows host and explain every field of their output. Microsoft's signtool, certutil, and the ConfigCI PowerShell module are the canonical tools [@mslearn-crypto-tools].

Verify a signed binary end to end

signtool verify /v /pa /all "C:\Path\To\binary.exe"

The output prints, in order: the SHA-256 of the file's Authenticode hash, the leaf certificate's subject and issuer, every intermediate up to the trusted root, the RFC 3161 timestamp's genTime, and the policy used to validate. /pa opts into the "default authenticode" policy (instead of the deprecated MicrosoftRoot policy); /all walks every signature on the file rather than just the strongest.

Compute and look up an Authenticode hash

certutil -hashfile "C:\Path\To\driver.sys" SHA256
certutil -CatDB "C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}" /v /search <hash>

The -hashfile command emits the file SHA-256, which is not the Authenticode hash (the file SHA-256 includes the certificate-table bytes; the Authenticode hash excludes them). The Authenticode hash is what is stored inside each catalog's CatalogList. Get-AuthenticodeSignature is the easier PowerShell route to the Authenticode hash directly.

Walk the catalog store

Get-ChildItem "C:\Windows\System32\CatRoot" -Recurse | Select-Object FullName

The GUID-named subfolder is the CryptSvc policy database identifier; the .cat files inside are individually-signed SignedData blobs whose encapContentInfo is a CatalogList [@mslearn-catalog-files]. CatRoot2 holds staging copies and the catalog database index.

Generate a WDAC rule

New-CIPolicyRule -FilePath "C:\Path\To\App.exe" -Level FilePublisher

This produces an XML <FileRule> element with the issuer, subject CN, original file name, and minimum file version. Pipe the result into New-CIPolicy to build a policy XML; convert to binary with ConvertFrom-CIPolicy and deploy via Group Policy or Intune.

Decide between embedded and catalog signing

For an internal line-of-business app shipped as a single MSI, embedded signing is the default and the cleanest choice. For a multi-binary package where some files are third-party and unsignable, the Package Inspector workflow [@mslearn-deploy-catalog-files] builds a .cat covering the post-installation file set without modifying any binary:

PackageInspector.exe Start C:\
... install your app ...
PackageInspector.exe Stop C:\ -Name MyApp.cat -ResultsFile C:\Temp\MyApp_inspection.txt

Confirm a kernel-mode chain

signtool verify /v /pa /kp "C:\Windows\System32\drivers\example.sys"

The /kp policy uses the kernel-mode driver policy: the chain must terminate at a kernel-mode-trusted root (the Microsoft Code Verification Root family of anchors, or a portal-signed-driver Microsoft Root Authority anchor). certutil -store -enterprise root enumerates the local kernel-mode roots; the legacy Microsoft Code Verification Root is named on the KMCS policy page [@mslearn-kmcs-policy] but its thumbprint is not published on a stable Microsoft Learn URL -- you read it via certutil -store on the running system.

Make an informed `EnableCertPaddingCheck` decision

The strict-parser registry value lives in two places. Set both:

reg add "HKLM\Software\Microsoft\Cryptography\Wintrust\Config" /v EnableCertPaddingCheck /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" /v EnableCertPaddingCheck /t REG_DWORD /d 1 /f

CISA added CVE-2013-3900 to the Known Exploited Vulnerabilities catalogue on 10 January 2022 [@nvd-cve-2013-3900]; treat this as effectively mandatory in any hardened-baseline build.

Annotated `signtool verify` output

Verifying: notepad.exe
Hash of file (sha256): 6B9B7E...   <-- Authenticode hash, the same one
                                       inside SpcIndirectDataContent.messageDigest
Signing Certificate Chain:
  Issued to: Microsoft Root Certificate Authority 2010   <-- root anchor
    Issued by: Microsoft Root Certificate Authority 2010
  Issued to: Microsoft Windows Production PCA 2011        <-- intermediate / PCA
    Issued by: Microsoft Root Certificate Authority 2010
  Issued to: Microsoft Windows                             <-- leaf / signer
    Issued by: Microsoft Windows Production PCA 2011
The signature is timestamped: Thu Jul ...                 <-- RFC 3161 genTime
Timestamp Verified by:
  Issued to: Microsoft Time-Stamp PCA 2010                <-- TSA chain
  Issued to: Microsoft Time-Stamp Service
File is signed and the signature was verified.

{` // Cross-platform pedagogy: this snippet shows the flow of a catalog lookup. // On Windows, "certutil -CatDB /v /search " returns the // covering catalog file. Off Windows, we mock the output so the flow is visible.

interface CatalogLookupResult { hash: string; catalogFile: string | null; signerSubject: string | null; }

function lookupCatalog(authenticodeHash: string): CatalogLookupResult { // Real implementation would shell out to: // certutil -CatDB /v /search // Parse the output for "Hash: Catalog: ". const known: Record<string, CatalogLookupResult> = { "6B9B7E...": { hash: "6B9B7E...", catalogFile: "C:\\Windows\\System32\\CatRoot\\{F750E6C3-...}\\Package_for_KB12345.cat", signerSubject: "CN=Microsoft Windows Production PCA 2011" } }; return known[authenticodeHash] || { hash: authenticodeHash, catalogFile: null, signerSubject: null }; }

const r = lookupCatalog("6B9B7E..."); console.log(r.catalogFile ? "Catalog-signed by " + r.signerSubject : "Not catalog-covered"); `}

Note: The most common practitioner mistake is signtool sign /n <name> without /tr <tsa-url> /td sha256. A signature produced this way silently loses validity the moment the end-entity certificate expires -- which can be years later, when the signer has long since lost access to whatever signing key produced it. The fix is to always include /tr and a strong /td. RFC 3161 [@rfc-3161] is the entire reason long-lived signatures still verify; opting out of it is opting out of the longevity guarantee.

SmartScreen Application Reputation is not gated on Authenticode validity. It is gated on certificate *class* (EV vs. OV) and on aggregate *download volume* and reporting. An internally signed enterprise LOB app has neither: it is signed with an OV certificate, and its download volume is at most a few hundred enterprise users. The fix has two paths. The cheap one is to ride your enterprise WDAC policy rather than fight SmartScreen -- App Control rules allow the binary unconditionally inside your organisation. The expensive one is to buy an EV certificate, push the binary through a small early-access user pool, and let SmartScreen accumulate the reputation signal. Both work. Fighting SmartScreen with a louder OV signature does not.

These seven commands cover the full surface of what Authenticode, catalog signing, and WDAC let a Windows engineer actually inspect. Everything else in this article is context for what those command outputs mean.

12. Frequently asked questions

Authenticode is a specific PKCS#7 / CMS profile for signing Windows portable executables, catalog files, and a small set of related artefacts. It is defined by Microsoft's `Authenticode_PE.docx` specification [@authenticode-pe-docx] and is characterised by a PE-specific Authenticode hash (with four exclusions), the `SpcIndirectDataContent` content type at OID `1.3.6.1.4.1.311.2.1.4`, and the `WIN_CERTIFICATE` certificate-table wrapper. Other code-signing schemes -- JAR signing for Java, APK Signature Scheme v3 for Android [@android-apk-v3], sigstore/cosign for OCI artefacts [@sigstore-overview], Apple Notarization for macOS [@apple-notarization] -- are not Authenticode-compatible. They solve similar problems with different envelopes. Not if the signature was RFC 3161 timestamped at signing time. The `TimeStampToken` in the unsigned attributes pegs the signing event to a `genTime` from a Trusted Time-Stamping Authority [@rfc-3161]; later verifiers compare `genTime` to the signing certificate's validity window and honour the signature so long as `genTime` was inside that window. The signature *will* stop working on hash-only WDAC rules (which do not consult certificate expiry at all) and on the rare verifiers that enforce chain time at validation. Signing without `/tr` is the way to produce a signature that silently loses validity at end-entity-cert expiry; that is the single most common Authenticode mistake at signing time. Only by enabling Test Signing mode (which puts a watermark on the desktop and refuses to coexist with Secure Boot), or by booting with Driver Signature Enforcement disabled (which is a one-boot bypass), or by using a vulnerable signed driver to load your unsigned code (the entire point of the Vulnerable Driver Blocklist [@mslearn-recommended-driver-block-rules]). Production loading of an unsigned driver on a normally configured Windows 11 system is not supported. Cross-signing for new end-entity certs has been closed since the 29 July 2015 issuance cutoff [@mslearn-kmcs-policy]; cross-certificates expired by July 2021 [@mslearn-deprecation-spc-crc]. See the §11 Spoiler *"Why your internally-signed LOB app trips SmartScreen"* for the detailed explanation of why SmartScreen Application Reputation weights certificate class (EV vs. OV) and download volume rather than Authenticode validity, and for the two production fixes (ride your enterprise App Control policy, or buy an EV certificate and let reputation accumulate). The one-line summary: Authenticode and SmartScreen are different decision systems that happen to read the same `SignerInfo` -- making your signature *louder* in Authenticode does not buy you reputation in SmartScreen. The `Microsoft Code Verification Root` is the historical kernel-mode trust anchor whose intermediate cross-signed third-party kernel code-signing CAs for pre-July-2015 drivers [@mslearn-kmcs-policy]. It is named in the KMCS policy document; its thumbprint is not published on a stable Microsoft Learn URL, so practitioners read it via `certutil -store` on the running system. The `Microsoft Code Signing PCA` family of intermediates (and its newer cousins like `Microsoft Windows Production PCA 2011`) are user-mode signing chains used for Microsoft-internal binaries and most WHQL catalogs. Both feed into `WinVerifyTrust`; they differ in which downstream consumer treats them as authoritative -- the kernel for the former, user-mode trust decisions for the latter. No. The Authenticode hash excludes four PE regions: the optional-header `CheckSum` (4 bytes), the `IMAGE_DIRECTORY_ENTRY_SECURITY` data-directory entry (8 bytes), the certificate-table bytes themselves, and the file-alignment padding after each section [@authenticode-pe-docx]. So `(Get-AuthenticodeSignature notepad.exe).Hash` returns a different value than `certutil -hashfile notepad.exe SHA256`. The Authenticode hash is what is stored inside `SpcIndirectDataContent.messageDigest` and what is matched against catalog `memberHash` entries; the file SHA-256 is useful for forensic identification but does not appear anywhere in the signature flow. They differ in precision and in which Authenticode fields they consult [@mslearn-select-types-of-rules]. `Publisher` allows anything signed by a given issuing CA + leaf-cert subject CN; broadest but loosest. `FilePublisher` adds `OriginalFileName` + `MinimumFileVersion` constraints; tightens to a specific binary at a min version. `WHQLFilePublisher` further requires the WHQL EKU; the strictest commonly used rule level. Self-updating apps invalidate `FilePublisher` rules silently when their `OriginalFileName` or `FileVersion` change without warning [@mslearn-use-code-signing]; most enterprises start at `Publisher` and tighten only for high-risk binaries. No. NVD's verbatim Microsoft language: *"Microsoft does not plan to enforce the stricter verification behavior as a default functionality on supported releases of Microsoft Windows. This behavior remains available as an opt-in feature via reg key setting, and is available on supported editions of Windows released since December 10, 2013"* [@nvd-cve-2013-3900]. CISA added the CVE to the Known Exploited Vulnerabilities catalogue on 10 January 2022 with a federal due date of 10 July 2022. Hardened environments should set `EnableCertPaddingCheck=1` in both the native and `Wow6432Node` registry paths.

13. Closing reflection

In August 1996 the Authenticode trust decision was a single yes/no answer to a single question: did this PKCS#7 SignedData blob, attached to this downloadable ActiveX control, validate against a CA in the user's browser? Thirty years later, the trust decision is a chained question composing every primitive in this article: a WIN_CERTIFICATE record points to a SignedData envelope; the envelope's SpcIndirectDataContent carries an Authenticode hash and optional page hashes; an unsigned attribute carries an RFC 3161 timestamp; the catalog store may carry a parallel signature for the same hash; the certificate chain terminates at one of a small set of Microsoft anchors for kernel-mode loads; an administrator's App Control policy decides whether the verdict survives the rule evaluation; the Vulnerable Driver Blocklist denies a small curated list outright.

The cryptography has not moved. The certificate table is still where the bytes live. PKCS#7 SignedData is still the envelope. RSA is still the signature algorithm. What has changed -- and what is going to keep changing through the post-quantum migration and whatever the Windows Resiliency Initiative converges to -- is the layering of policy on top.

Authenticode is not the ceiling. It is the floor. Everything else is built on top, and the next time a Realtek certificate is stolen, those layers are what decides whether the next Stuxnet still loads.

"Who Is This Code?" -- The Quiet 33-Year Reinvention of App Identity in Windows

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

Windows NT 3.1 (1993) could prove which **user** typed at the keyboard but had no answer to **which code was running**. Over the next thirty-three years, eight successive primitives -- Authenticode, Kernel-Mode Code Signing, Protected Process Light, AppContainer with the Package SID, App Control for Business, Mark of the Web with SmartScreen, the Vulnerable Driver Block List, and Pluton-rooted attestation -- accreted into a single layered code-identity stack. Each was forced into existence by a specific, named failure of the one before it. This is that story, told as one system.

Two identities, one operating system

On July 27, 1993 -- the day Windows NT 3.1 shipped -- the new operating system could prove with cryptographic precision who Alice was, which group she belonged to, which file she was allowed to open, and at what level of privilege she was running. It could prove exactly nothing about the program she had just double-clicked.

Thirty-three years later, "Alice" has barely changed. The code she runs has acquired a publisher signature stamped onto its Portable Executable file, a kernel-loader gate that refuses to load unsigned drivers, a signer level in a runtime lattice that decides whether one process can read another's memory, a Package SID derived from a Crockford-Base32 hash of the manifest publisher [@ms-package-identity], a publisher-rule entry in a centrally managed App Control policy [@ms-appcontrol], a Mark-of-the-Web alternate data stream from the browser that downloaded it [@ms-fscc-motw], a SmartScreen reputation score [@learn-smartscreen], a possible entry on a Microsoft-curated denylist that overrides its own valid signature [@msft-driver-blocklist], and -- on a Pluton-equipped 2026 laptop -- a hardware-attested measurement of the boot chain that loaded it [@learn-pluton]. Every one of those identities was forced into existence by a specific failure of the one before. This is that story.

A modern symptom makes the asymmetry concrete. In April 2026, attackers seized the publishing pipeline for the @bitwarden/cli npm package -- a credential they had no business holding -- and shipped a backdoored release for ninety-three minutes before maintainers caught it [@bitwarden-statement]. Code identity, as it existed at every layer of every operating system that consumed that package, said the artifact was authentic. The signature was valid. The publisher's account was real. The package metadata was correct. Every check passed. And the binary was hostile. That gap, between "who shipped it" and "is it safe to run," is the same gap NT 3.1 first stepped over in 1993 and that Windows has been trying to close ever since.

The Bitwarden case sits in a long company. Stuxnet's stolen Realtek and JMicron driver-signing keys (2010) [@symantec-stuxnet], Flame's MD5 collision against Microsoft's own intermediate CAs (2012) [@ms-2718704], the ASUS ShadowHammer pipeline compromise (operation 2018, disclosed 2019) [@securelist-shadowhammer], every "Bring Your Own Vulnerable Driver" rootkit since 2018 -- they all have the same shape. A valid Windows-anchored signature, on code the publisher did not intend to ship, on a machine that loaded it without complaint.

Key idea: Every Windows code-identity primitive introduced since 1996 was forced into existence by a specific failure of the layer before it. The article's spine is that cascade.

The pieces in 2026 are not a feature checklist. They are a layered system, each layer answering a question its predecessor structurally could not. If you read the Microsoft Learn pages one at a time you see eight unrelated products. If you read them in the order their failures forced them into existence, you see one operating system slowly learning to name the code it runs.

timeline title Windows code identity, 1993 to 2026 1993 : NT 3.1 ships : user-only principal 1996 : Authenticode : publisher signature on PE 2002 : Trustworthy Computing memo : SDL forcing function 2006 : Vista x64 KMCS : refusal of unsigned kernel code 2010 : Stuxnet : stolen Realtek + JMicron keys 2012 : AppContainer : per-app SID 2012 : Flame : MD5 collision against MS CA 2013 : Windows 8.1 PPL : signer level as runtime ACL 2015 : Device Guard / WDAC : publisher policy 2019 : ASUS ShadowHammer disclosed : compromised pipeline (2018 operation) 2020 : Pluton announced : in-die security processor 2022 : Driver Block List default-on : signed != trusted 2024 : CrowdStrike outage : placement is identity 2025 : MVI 3.0 user-mode preview : kernel/user split

Timeline sources, in row order (Mermaid syntax does not permit inline tokens inside the timeline block; each event is independently cited in the surrounding prose as well): 1993 NT 3.1 [@custer-inside-nt]; 1996 Authenticode [@ms-news-1996-authenticode]; 2002 Trustworthy Computing memo [@cnet-gates-memo] [@theregister-tcm]; 2006 Vista x64 KMCS [@ms-kmcs]; 2010 Stuxnet [@symantec-stuxnet]; 2012 AppContainer [@ms-package-identity]; 2012 Flame MD5 collision [@ms-2718704] [@msrc-2718704]; 2013 Windows 8.1 PPL [@ionescu-ppl] [@ms-protected-processes]; 2015 Device Guard / WDAC [@ms-appcontrol]; 2019 ASUS ShadowHammer disclosed (operation 2018) [@securelist-shadowhammer]; 2020 Pluton announced [@learn-pluton]; 2022 Driver Block List default-on [@msft-driver-blocklist]; 2024 CrowdStrike outage [@ms-crowdstrike-blog] [@msft-crowdstrike-best-practices]; 2025 MVI 3.0 user-mode preview [@weston-2024] [@weston-2025].

If user identity was easy, why did code identity take thirty-three years -- and where exactly did each generation break?

Why code had no name

Helen Custer's 1992 Inside Windows NT opens its security chapter on a single principle: the user is the principal [@custer-inside-nt]. Every action the kernel arbitrates is attributable to a user account. The token that the kernel manufactures at logon carries a Security Identifier (SID) for the user, SIDs for each group the user belongs to, a privilege bitmap, and a set of impersonation flags. Every Discretionary Access Control List on every securable object is evaluated against that token [@ms-sids]. The kernel never asks what binary is running. It asks who is running it.

A variable-length value that uniquely identifies a security principal in Windows. Users, groups, computer accounts, and (later) packages and capabilities all receive SIDs. Until Windows 8, every SID encoded a *user* or *group*; AppContainer and Package SIDs (the `S-1-15-2-...` form) extended SIDs to name code instead.

For 1993's threat model, the user-as-principal model was defensible. NT 3.1 lived on multi-user workstations in a trusted local-area network. The attacker the designers worried about was a malicious insider, a contractor with the wrong group membership, an admin who exceeded his authority. Code arrived on floppies and CDs from coworkers and shrink-wrapped vendors; nobody downloaded executables off the public internet, because for most of the world there was no public internet to download them from.Integrity levels (Low, Medium, High, System) were added later, in Vista (2006), and they are still attributes of the token, not of the binary on disk. A Low-integrity Internet Explorer process and a Low-integrity Notepad receive the same write restrictions because their tokens carry the same Mandatory Integrity Control label, regardless of which binary loaded.

Then came Internet Explorer 3.0 in August 1996 and ActiveX. Microsoft repositioned OLE/COM as a cross-internet component model and committed to letting any compliant ActiveX control execute inside the browser [@ms-news-1996-authenticode]. The decision was not casually made; it was the strategic foundation of Microsoft's bet on the web. But its consequence at the security layer was immediate and devastating.

If Alice double-clicks a control on a web page, the operating system's question is "who is running this?" The answer is "Alice." She is allowed to run anything she wants. The control does whatever it likes -- with her token, her files, her privileges, her network access. The user-as-principal model has no second axis to invoke.

There was no theoretical fix at this layer. Alice did genuinely request the download. She did genuinely double-click. NT had no other principal to consult. The model was complete, internally consistent, and exactly wrong for the new threat surface.

What was missing was a cryptographic, network-portable identity for the code itself, attached to the binary in a way nobody downstream could forge. If the kernel cannot see the code, who can put a name on it -- and how do we attach that name to a running PE?

The first naive attempt: Authenticode (1996)

On August 7, 1996, Microsoft and VeriSign jointly announced the first cryptographic answer Windows had ever offered to "who is this code?" The press release ran twenty-two paragraphs and named every design choice that the next thirty years of Windows code identity would inherit: an X.509 certificate issued by an external commercial Certificate Authority, a PKCS#7 SignedData blob attached directly to the binary, and verification at download or install time by Internet Explorer 3.0 [@ms-news-1996-authenticode].

A cryptographic format for binding a publisher's identity and a tamper-evident hash to a Portable Executable. The signature is stored in the PE Attribute Certificate Table as a PKCS#7 SignedData structure containing an X.509 certificate chain and a hash that excludes the checksum field, the certificate-table directory entry, and the certificate table itself. Authenticode names the *publisher*, not the code; this is the founding constraint the rest of the article is forced to work around. The new Microsoft Authenticode technology uniquely identifies the publisher of a piece of software and provides assurance to end users that it has not been tampered with or modified. -- Microsoft press release, August 7, 1996 [@ms-news-1996-authenticode]

That sentence is the founding promise of Windows code identity. Read it once and the rest of the article becomes inevitable. Authenticode promises two things. It identifies the publisher. It detects tampering. It does not promise that the publisher is trustworthy, that the publisher's key is uncompromised, or that the bytes it covers are safe to execute. Three decades of failure modes follow from exactly that scoping.

The mechanism is precise enough to demand a diagram. SignTool computes a hash that deliberately skips three regions of the PE: the checksum field (which the loader recomputes), the certificate-table directory entry, and the certificate table itself. The signature does not have to sign the bytes of its own embedding [@ms-pe-format].

It then forms a PKCS#7 SignedData structure [@rfc-2315] containing the hash, an algorithm identifier, the X.509 chain, and an optional RFC 3161 timestamp. That blob is appended to the certificate table. At verify time, WinVerifyTrust recomputes the hash, walks the chain to a trusted root, and (if a timestamp is present) honours signatures that were valid as of the timestamped time even if the issuer has since revoked the certificate [@ms-cryptotools].

sequenceDiagram participant Dev as Developer participant Sign as SignTool participant PE as PE binary participant Win as WinVerifyTrust participant CA as CA / chain store Dev->>Sign: signtool sign /a app.exe Sign->>PE: hash bytes (skip checksum + cert table) Sign->>PE: build PKCS#7 SignedData Sign->>PE: append RFC 3161 timestamp Sign->>PE: write into Attribute Cert Table Note over Win: at install / download time Win->>PE: re-hash same byte ranges Win->>PE: extract PKCS#7 SignedData Win->>CA: verify X.509 chain to trusted root CA-->>Win: chain ok Win-->>Win: trust verdict (advisory pre-Vista)

Three structural failure modes shipped on day one and still ship in 2026.

Userland was advisory. A signed .exe ran. An unsigned .exe also ran. Internet Explorer would prompt the user with a publisher name, but the prompt was a UI feature, not a kernel gate. The signature was a credential offered for inspection, never a wall the loader refused to cross. Closing this gap took ten years for kernel code (Authenticode 1996 [@ms-news-1996-authenticode] -> KMCS, Vista 2006 [@ms-kmcs]) and nineteen years for managed user-mode policy (Authenticode 1996 [@ms-news-1996-authenticode] -> Device Guard, 2015 [@ms-appcontrol]). Unmanaged consumer Windows in 2026 still permits arbitrary unsigned .exe to run if the user clicks through SmartScreen.

The signed hash did not cover the whole file. This is CVE-2013-3900, disclosed by Microsoft on December 10, 2013 in security bulletin MS13-098 [@ms13-098]. The Authenticode hash skips the certificate-table region by design, and the verifier in WinVerifyTrust did not constrain the size of the unsigned PKCS#7 blob. An attacker could append arbitrary unauthenticated bytes inside the WIN_CERTIFICATE structure of an already-signed PE without invalidating the signature.

The fix was a registry value, EnableCertPaddingCheck=1, that turned on strict verification. Microsoft chose not to enable it by default. Twelve years later, the National Vulnerability Database still records the same scoping note: "Microsoft does not plan to enforce the stricter verification behavior as a default functionality on supported releases of Microsoft Windows" [@nvd-cve-2013-3900]. CISA added CVE-2013-3900 to its Known Exploited Vulnerabilities catalog on January 10, 2022 -- eight years after disclosure, because attackers were still abusing the unfixed default [@nvd-cve-2013-3900].

Note: CVE-2013-3900 is still default-off in 2026. On any Windows endpoint where strict signature verification matters, set HKLM\Software\Microsoft\Cryptography\Wintrust\Config\EnableCertPaddingCheck=1 (and the WOW6432Node mirror on 64-bit). Microsoft documents the change as opt-in by design [@msrc-cve-2013-3900].

Timestamped signatures survive revocation. The trust evaluator in WinVerifyTrust is told to trust signatures as of the timestamped instant, not as of now. Removing this property would invalidate large catalogs of legitimate, archived signed software whose signing certificates have since expired [@ms-cryptotools]. The same property is what let the Stuxnet drivers load on every Windows machine that received them, because Microsoft revoked the Realtek and JMicron certificates after Stuxnet had already shipped.The architectural choice here is genuinely hard. Synchronous global revocation would break offline software install. Asynchronous revocation, the alternative Microsoft chose, lets pre-revocation signatures continue to verify forever. There is no third option inside the Authenticode design.

Pull these three threads together and the first aha falls out. Authenticode names the publisher, not the code. A signed binary is a credential, not a verdict. The signature proves the bytes came from a holder of the publisher's private key. It does not prove the publisher is trustworthy, that the publisher's key has not been stolen, or that the bytes are safe to execute. Every failure mode of the next twenty-five years lives in that gap.

Six years of failure modes had to accumulate before Microsoft executive priorities caught up. On January 15, 2002, Bill Gates sent the "Trustworthy Computing" memo company-wide, declaring security a higher priority than features and freezing engineering work for security review across its Windows product line (with SDL processes later extended company-wide) [@cnet-gates-memo] [@theregister-tcm]. The memo did not specify a code-identity mechanism. It is in this story because every later code-identity primitive -- the Security Development Lifecycle's mandatory SignTool integration, the XP SP2 hardening pass that produced MOTW, and the Vista work that produced KMCS -- shipped under the executive cover the memo provided [@windows-internals-7e].

If unsigned code still runs in userland, what makes us think the same primitive will work for a kernel driver -- where the wrong binary owns the operating system?

The first refusal: KMCS, EV, and the WHQL pipeline (Vista, 2006)

Vista x64 shipped in November 2006 as the first Windows release that refuses to load unsigned kernel code [@ms-kmcs]. The refusal was uncompromising. The kernel loader and the Plug-and-Play manager call into WinVerifyTrust for every driver image; if the chain does not terminate at one of a small set of Microsoft-trusted roots, MmLoadSystemImage returns STATUS_INVALID_IMAGE_HASH and the driver does not load.

The Vista-era policy that requires every kernel-mode driver to carry an Authenticode signature chained to a Microsoft-trusted root. From Windows 10 1607 onward (the August 2016 Anniversary Update), only drivers signed by Microsoft via the Hardware Developer Center are accepted on Secure-Boot systems; end-entity cross-signed certificates issued before July 29, 2015 are grandfathered for legacy devices [@ms-kmcs].

The mechanism is a load-time gate. In 2026, Microsoft offers three signing tiers that all terminate at a Microsoft cross-signed cert: HLK-tested (the full Windows Hardware Lab Kit run, eligible for retail Windows Update distribution), attestation-signed (lighter-weight, EV cert plus Microsoft attestation key, no hardware testing), and preproduction (developer signing for pre-release Windows builds) [@learn-driver-signing-offerings] [@ms-attestation-signing]. Driver .cat catalog files extend Authenticode coverage from a single PE to an entire driver package, including INF files and supporting executables [@learn-embedded-sig].

EV certificates -- Extended Validation, with mandatory hardware-security-module key storage and audited issuance -- became the practical floor for kernel signing. The reason was not pedagogical. A Domain Validated Authenticode cert from a commodity CA in that era could be obtained cheaply, often with little more than a working email address. EV raised the cost and binding strength of the publisher claim by an order of magnitude.

Then, on June 17, 2010, Sergey Ulasen of the Belarusian anti-virus vendor VirusBlokAda flagged a strange piece of malware on a customer machine in Iran. It had been signed [@wikipedia-stuxnet].

The Stuxnet dropper carried two kernel drivers, mrxnet.sys and mrxcls.sys, signed with legitimate Authenticode certificates issued to Realtek Semiconductor and JMicron Technology -- two Taiwanese hardware vendors. Investigators concluded the private keys had been physically exfiltrated from the publishers' Taiwanese offices. VeriSign revoked the Realtek certificate on July 16, 2010 (and the JMicron certificate shortly afterward); Microsoft issued advisories and pushed Windows CTL updates to propagate the revocation [@symantec-stuxnet]. While the certs were valid, Vista x64 KMCS happily loaded both drivers on every system it touched.

Note: KMCS verifies who signed, never whether the signed code is safe. Every kernel-mode-identity failure between 2010 and 2026 reduces to that single sentence.

The Stuxnet certificates were not anomalies. The same failure shape -- valid Microsoft-rooted signature, on code the publisher did not intend to ship, on a healthy KMCS-enforcing kernel -- replays at predictable intervals.

The Flame espionage toolkit produced a *forged* Microsoft-rooted certificate by exploiting an MD5 chosen-prefix collision against Microsoft's Terminal Services Licensing Service, which still issued MD5-hash code-signing certificates years after MD5's brokenness was known. Microsoft Security Advisory 2718704 revoked three of its own intermediate CAs and emergency-deployed a new Untrusted Certificate Store mechanism through Windows Update [@ms-2718704] [@msrc-2718704]. The episode forced Microsoft to deprecate MD5 in code signing and led directly to the curation infrastructure the Driver Block List uses today.

ASUS ShadowHammer in 2018, disclosed by Kaspersky in 2019, added a third variant. The attackers did not steal an HSM-bound key. They compromised ASUS's signing pipeline and got their backdoor signed by ASUS's production signing key in the normal course of a normal release, distributed through ASUS Live Update [@securelist-shadowhammer]. Kaspersky's analysis recorded "trojanized updaters were signed with legitimate certificates (eg: 'ASUSTeK Computer Inc.')" and that "over 57,000 Kaspersky users have downloaded and installed the backdoored version of ASUS Live Update." The trust root, the chain, the cert -- all valid. The bytes -- attacker-controlled.

KMCS verified that a driver was signed, not that it was safe. Signing alone was not enough. But what was?

The second refusal: identity as a runtime attribute (PPL, 2013)

Until October 17, 2013, code identity gated whether code could load. Windows 8.1 quietly shipped a structural shift: code identity now also gated what one running process could do to another [@ionescu-ppl]. Alex Ionescu, then CrowdStrike's founding Chief Architect and previously a co-author of Windows Internals, was the first person to publish a detailed external map of the new mechanism. The lineage runs back to Vista's 2006 Protected Process model, originally introduced as a DRM container for protected media playback; PPL is the security-grade descendant of that primitive, repurposed seven years later as a general-purpose process-protection mechanism [@windows-internals-7e].

A protection attribute attached to running processes that mediates inter-process access checks above and beyond the user-token DACL. PPL processes carry a *signer level* (in increasing order, roughly: `Authenticode`, `CodeGen`, `Antimalware`, `Lsa`, `Windows`, `WinTcb`, `WinSystem`). A process can open `PROCESS_VM_READ`, `PROCESS_VM_WRITE`, or `CREATE_THREAD` rights against another protected process only if its own signer level is greater than or equal to the target's [@ionescu-ppl] [@ms-protected-processes].

The mechanism lives in the kernel's EPROCESS object. When process A opens process B, the kernel calls into RtlTestProtectedAccess (and downstream PsTestProtectedProcessIncompatibility) before any DACL evaluation [@scrt-ppl-bypass]. If A's signer level is below B's, sensitive access masks are silently stripped from the returned handle. The classic effect: an attacker running with a SYSTEM token, holding SeDebugPrivilege, calling OpenProcess on LSASS, gets back a handle without PROCESS_VM_READ. Mimikatz can no longer dump the LSASS process memory.

The signer level itself is set by an Enhanced Key Usage extension on the Authenticode certificate Microsoft issues to the binary's publisher. Antimalware vendors receive a certificate carrying the Antimalware EKU; only Microsoft-internal binaries carry WinTcb [@itm4n-runasppl]. Identity, in this model, is an EKU OID baked into a Microsoft-issued Authenticode cert, attached to the binary, evaluated by the kernel at every cross-process access check.

flowchart TD A[WinSystem] B[WinTcb] C[Windows] D[Lsa] E[Antimalware] F[CodeGen] G[Authenticode] A --> B --> C --> D --> E --> F --> G H["Caller (signer level X)"] -- "OpenProcess(target T, signer Y)" --> I{"X >= Y ?"} I -- yes --> J["full access mask"] I -- no --> K["VM_READ / VM_WRITE / CREATE_THREAD stripped"]

LSASS-as-PPL is the canonical demonstration of the mechanism in practice. Setting HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL=1 causes the next boot's LSASS to start with PsProtectedSignerLsa. From that moment, no process below the Lsa signer level can read LSASS memory, regardless of the user account. Mimikatz still runs as code; its OpenProcess(LSASS, PROCESS_VM_READ) call returns a handle with the read right stripped, and its memory dump fails with STATUS_ACCESS_DENIED before it ever sees a credential blob [@itm4n-runasppl].The RunAsPPL=1 setting is mirrored into a UEFI variable on Secure Boot systems precisely so that an attacker with HKLM\SYSTEM registry write but no firmware-level access cannot disable LSA Protection by editing the registry and rebooting. The UEFI mirror is checked before the registry value is read [@itm4n-runasppl].

ELAM -- Early Launch Antimalware -- is the same idea applied to boot. An ELAM driver, signed with a Microsoft-issued antimalware certificate, runs before any third-party boot driver and gets to vote on which subsequent drivers are allowed to load [@learn-elam]. Signer level enters the boot chain at the earliest moment third-party code can enter the boot chain.

Key idea: PPL's invention is conceptual, not just mechanical. Code identity becomes a runtime ACL between two running processes, not merely a load-time gate. App Control, HVCI, and the Driver Block List all operate on this same conceptual frame: identity continuously evaluated, in context, while code is executing.

PPL was, and is, the right idea. It is also incomplete in two ways that drove every subsequent layer.

The first gap is BYOVD -- Bring Your Own Vulnerable Driver. A signed-but-vulnerable driver such as RTCore64.sys (shipped with MSI Afterburner), Capcom.sys (shipped with the Street Fighter V anti-cheat), or gdrv.sys (shipped with Gigabyte motherboard utilities) gives any local administrator arbitrary kernel read/write through an IOCTL. Because these drivers are validly KMCS-signed, they load. From kernel mode, the attacker simply zeroes the Protection byte in the target process's EPROCESS structure, and PPL evaporates. The signing chain is sound. The signer level is correctly evaluated. The mechanism that decides which kernel code is allowed to exist -- not just to be signed -- is what fails.

Note: PPL is bypassed not by attacking PPL itself but by editing EPROCESS.Protection from kernel mode. That is exactly why the Driver Block List had to exist as a separate layer above KMCS [@msft-driver-blocklist].

The second gap is the user-mode side. PPLdump and PPLfault demonstrated that confused-deputy DLL loads inside higher-PPL services could be turned into an arbitrary memory read of LSASS. Microsoft eventually patched PPLdump in Windows 10 21H2 build 19044.1826, but the failure class remains structural: trusting a higher-signer process to safely load DLLs from publisher-controlled paths is a foot-gun every time a new such service ships [@ppldump-github] [@scrt-ppl-bypass].

If signer level is the principal for OS-internal processes, what is the principal for the next layer up -- the application?

The application becomes a principal: AppContainer and the Package SID

Two processes, same user, same machine. One can read the user's SSH private keys. The other cannot. Same token. Same DACLs on the file. Different verdict. That is the AppContainer promise [@ms-appcontainer-isolation], and to keep it the operating system needs a cryptographic identity for the application itself -- something derived from the application, not from the user, that ACLs can name.

Windows 8 shipped AppContainer in 2012. Internally it was called LowBox, the name surviving in the legacy documentation [@ms-appcontainer-legacy]. Windows 10 generalised the model into MSIX, the modern app-package format [@ms-msix].

AppContainer is a per-process sandbox that augments the user-token security check with an *AppContainer SID* (`S-1-15-2-...`) derived from the package identity of the running application. ACLs and capability claims (such as `internetClient` or `picturesLibrary`) are evaluated against this SID, not against the user. Two processes running as the same user can therefore receive different access verdicts because their AppContainer SIDs differ.

The cryptographic move is in how the SID is built.

Every MSIX/APPX package is identified by a five-element tuple: `(Name, Version, Architecture, ResourceId, Publisher)` [@ms-package-identity]. The `Publisher` field is the X.509 subject Distinguished Name of the certificate that signed the package. A 13-character `PublisherId` is derived deterministically from the Publisher DN by Crockford-Base32 encoding the first 64 bits of a SHA-256 hash (per community reverse-engineering; Microsoft's public documentation does not confirm the specific algorithm). The *Package Family Name* is then `_`; the *AppContainer SID* is computed deterministically from the full identity tuple and slotted into the `S-1-15-2-...` namespace.

The derivation is dense enough to deserve a worked example. Microsoft Corporation plus the Microsoft.WindowsCalculator package name yields Microsoft.WindowsCalculator_8wekyb3d8bbwe -- the suffix is the Crockford-Base32 PublisherId of Microsoft Corporation's subject DN [@ms-package-identity]. Every MSIX package whose Publisher DN matches will share that suffix; every package whose Publisher DN differs will have a different suffix; an attacker who does not hold the publisher's signing key cannot make a package masquerade as belonging to that publisher's family.

{async function publisherIdOf(publisherDN) { const data = new TextEncoder().encode(publisherDN); const digest = await crypto.subtle.digest('SHA-256', data); const first8 = new Uint8Array(digest.slice(0, 8)); // Crockford Base32 alphabet (no I, L, O, U) const alpha = '0123456789abcdefghjkmnpqrstvwxyz'; let bits = 0n; for (const b of first8) bits = (bits << 8n) | BigInt(b); let out = ''; for (let i = 0; i < 13; i++) { out = alpha[Number(bits & 31n)] + out; bits >>= 5n; } return out; } const dn = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US'; publisherIdOf(dn).then(pid => console.log('PFN suffix candidate:', pid)); console.log('Real PFN: Microsoft.WindowsCalculator_8wekyb3d8bbwe'); console.log('Note: the real algorithm is documented in package-identity-overview; this snippet demonstrates the structure, not the exact hash.');}

Capabilities sit at the same layer. When an MSIX manifest declares <Capability Name="internetClient" />, the package is tagged at install time with a capability SID of the form S-1-15-3-1, and the Windows Filtering Platform evaluates outbound TCP connections against that SID, not against the user's [@p0-appcontainer]. Mandatory Integrity Control labels (Low/Medium/High) compose with the AppContainer SID rather than replacing it [@learn-mic]. A broker process running outside the AppContainer is the only path back to user-scoped resources, and the broker keys its trust decisions on the calling Package SID.

Windows Hello's biometric authentication broker is itself an MSIX-style protected service whose AppContainer-flavoured identity is the Package SID derived from its Microsoft-signed manifest. Other processes that want to ask Hello to verify a face or a fingerprint must talk to the broker, and the broker decides whether to honour the request based partly on the caller's package identity. The reason this matters is the same as the LSASS reason: the secret material the broker holds (the user's TPM-bound private key) needs a principal that an attacker holding a SYSTEM token cannot impersonate. User-SID equality is not enough. Package-SID equality is.

The 8wekyb3d8bbwe suffix you see on Calculator, Edge, the Microsoft Store, and most other in-box apps is Microsoft Corporation's PublisherId. Once you know what it is, you start seeing it everywhere -- it is the cryptographic fingerprint of "Microsoft signed this package" [@ms-package-identity].

The aha is the same shape as the PPL aha but at the layer above. Two binaries running as the same user can be authorised differently because the Package SID is derived from the manifest publisher and the package cannot forge it. AppContainer is not a sandbox you opt into. It is a SID you have. Capability ACLs name that SID. The firewall keys on it. The MIC label composes with it. The broker checks it.

The limits are also visible. AppContainer is opt-in for Win32 desktop apps that have not been packaged. Forshaw's 2021 Project Zero analysis of the AppContainer firewall identified loopback-exemption and namespace-isolation holes that Microsoft classified as WontFix [@p0-appcontainer]. Per-app sandbox identity solves the Modern-app problem; it does not solve the legacy Win32 problem. For that, the operating system needs a policy plane that names code in publisher vocabulary instead of path vocabulary.

What does an enterprise admin do when the application refuses to be packaged at all?

The policy plane: AppLocker, App Control, and the publisher rule

Path-based whitelisting failed for the same reason path-based ACLs failed. Anything writeable can be planted. AppLocker, shipped in Windows 7 in 2009, still stays in the box for compatibility, but Microsoft's own documentation recommends App Control for Business -- the rebranded Windows Defender Application Control -- for new deployments [@ms-applocker] [@ms-appcontrol]. The change is not cosmetic. It is the difference between filename-as-identity and Authenticode-publisher-as-identity.

A Code Integrity policy mechanism that expresses allow and deny rules in Authenticode-publisher vocabulary. Policies are authored in XML, compiled to a binary `siPolicy.p7b`, and enforced by the Code Integrity engine at every PE load. With HVCI active, enforcement happens inside the Hyper-V-protected secure kernel, immune to a compromised NT kernel [@ms-appcontrol].

The certificate-and-publisher rule levels run from strictest to broadest as Hash > FileName > FilePath > FilePublisher > SignedVersion > LeafCertificate > Publisher > PcaCertificate, with a parallel WHQL-only family for kernel drivers ordered WHQLFilePublisher > WHQLPublisher > WHQL [@ms-appcontrol]. Hash is the strictest (this exact byte string); PcaCertificate is the broadest signer-based level (anything signed under that intermediate CA). Microsoft documents RootCertificate as not supported, and FilePath -- available for user-mode binaries from Windows 10 1903 onward -- is path-based and so inherits the failure modes the publisher-rule model was designed to escape.

The LeafCertificate > Publisher adjacency is the subtle one. LeafCertificate pins to one specific signing certificate, so a renewal under a new leaf cert no longer matches. Publisher matches any certificate with the same PCA + leaf-CN combination, including future renewals. LeafCertificate is the stricter of the two [@ms-appcontrol].

The practical sweet spot is FilePublisher. It binds an allow rule to the tuple (certificate authority + leaf publisher CN + original filename + minimum version). That tuple survives recompiles: a benign update from the same publisher under the same name, signed by the same key, with a higher version still passes. It does not survive tampering. Change the original filename in the resource section, change the publisher, change the leaf certificate, and the rule no longer matches.

Policy primitive	Era	Rule basis	Kernel coverage	Default state
Software Restriction Policies (SRP)	XP, 2001	path / hash / certificate	none	unmanaged
AppLocker	Windows 7 Enterprise, 2009	path / publisher / hash	none	off
WDAC (Device Guard)	Windows 10, 2015	publisher / file attributes / hash	full (with HVCI)	off
App Control for Business	renamed 2023	publisher / file attributes / hash	full (with HVCI)	off; on by default in S Mode and on Windows 11 SE

The Code Integrity engine evaluates an App Control policy on every PE load -- user mode and kernel mode alike. With HVCI active, the policy lives behind the Hyper-V security boundary; even an NT-kernel-level attacker with arbitrary memory write cannot edit it without breaking out of the virtualization layer [@ms-appcontrol]. Deny rules always win; an explicit deny can never be undone by any number of allows on the same binary.

Note: Author every App Control policy in audit mode for at least one full reference-image cycle before promoting to enforce. Audit mode logs every load that would have been blocked, into the Microsoft-Windows-CodeIntegrity/Operational event channel, without breaking anything. The pre-deployment failure rate of strict policies on real fleets is high enough that audit mode is not optional [@ms-appcontrol].

App Control inherits the same structural ceiling Authenticode put in place. Allow Signer = Microsoft Windows admits the entire LOLBins inventory -- regsvr32, mshta, installutil, rundll32, every signed-by-Microsoft binary an attacker can call to execute arbitrary content. Allow Signer = ASUSTeK would have admitted ShadowHammer (operation 2018, disclosed 2019), every byte of which carried a valid ASUS production signature [@securelist-shadowhammer]. The publisher-rule model is the right primitive for managed endpoints, and the LOLBins / supply-chain-attack failure modes are the structural ceiling on what the primitive can prove.

PKI-rooted publisher policy still trusts the publisher's key custody. When the key is stolen or the binary is signed but malicious, what does the operating system fall back on?

Reputation as identity: Mark of the Web and SmartScreen

A novel binary, signed by a freshly issued EV cert, has zero history. PKI says yes. Reputation says: I have never seen this before -- run it past the user.

An NTFS alternate data stream named `Zone.Identifier` written by browsers, mail clients, and other downloaders to record the trust zone of a downloaded file. The stream contains an INI-style `[ZoneTransfer]` block with `ZoneId=3` for files from the public internet, plus optional `ReferrerUrl=` and `HostUrl=` fields. The protocol is documented in the MS-FSCC reference [@ms-fscc-motw]. SmartScreen, Office Protected View, and the Attachment Execution Service all read MOTW to gate behaviour on origin.

MOTW is not an Authenticode replacement. It is a parallel, origin-based identity: the binary's provenance, encoded as data the file system carries with it, separate from any signature. Origin is the input to SmartScreen. SmartScreen submits a hash of the binary together with publisher metadata to a Microsoft-hosted reputation service; if the service has not seen the binary before, or has not seen enough downloads to be confident, the user gets the familiar "Windows protected your PC" prompt that requires an explicit More info / Run anyway click [@learn-smartscreen].

The pipeline is parallel to Authenticode and App Control, not a successor. PKI says "this signature chains to a real publisher." Reputation says "this hash has been observed N times in the last 30 days, with prevalence trending up; the publisher account is six years old; M of the downloads were from machines later flagged for malware." None of those signals are derivable from a signature.The Defender machine-learning pipeline that powers SmartScreen reputation is the deeper version of the same idea -- already covered in The Defender's Dilemma sibling article, which traces the twenty-year arc from Defender's 0.5/6 AV-TEST score to its 100% MITRE detection rate. The reputation primitive sits on top of that ML pipeline.

The bypass surface is now well-known. Container formats (ISO, IMG, VHD, 7z) historically did not propagate MOTW to files extracted from them, because their on-disk representation does not preserve alternate data streams. Phishing campaigns adapted: send the attacker's .exe inside an .iso, the user mounts the .iso, double-clicks the .exe, and SmartScreen sees a binary with no MOTW and offers no warning.

Microsoft's response combined fixes -- VHD and ISO MOTW propagation shipped in the December 2022 cumulative update for Windows 11 22H2, MOTW-aware extraction in OneDrive and the new Windows Archive APIs -- with two attack-surface-reduction rules that gate execution on prevalence and trust independently of MOTW [@learn-asr-reference]. The most useful is rule 01443614-cd74-433a-b99e-2ecdc07bfc25, "Block executable files from running unless they meet a prevalence, age, or trusted list criterion."

Office is the most consequential consumer of MOTW. A Word, Excel, or PowerPoint file carrying a ZoneId=3 Mark of the Web opens in Protected View: read-only, in a sandboxed renderer, with macros and active content disabled, until the user clicks "Enable Editing" on the message bar [@learn-protected-view].

The 2022 wave of HTML-smuggling and ISO-borne malware that bypassed SmartScreen still tripped over Protected View at the document layer, and the post-2022 macro-blocked-by-default change extended the same MOTW-gated logic from container files to embedded VBA. Origin is now an input to two parallel pipelines: SmartScreen's reputation check on the executable, and Office's read-only-until-confirmed gate on the document.

The full ASR rule GUIDs are in the Defender for Endpoint reference. Memorise none of them; pin the page.

A useful way to read the layered system at this point: Authenticode answered "who shipped it?" KMCS answered "is the kernel allowed to load it?" PPL answered "is this running process allowed to touch that one?" AppContainer answered "what application is this?" App Control answered "does the enterprise honour this publisher?" MOTW and SmartScreen answer the question PKI cannot: "have we seen this before, and from where?" When PKI identity is necessary but not sufficient, reputation closes the gap -- statistically, never absolutely.

PKI says yes; reputation says unknown. What does the operating system do when Microsoft itself says no to a signature it just minted?

The breakthrough: signed is not trusted (Driver Block List, 2022)

December 8, 2021. Microsoft launches the Vulnerable and Malicious Driver Reporting Center [@msft-driver-reporting]. The blog post enumerates the failure shape that drove it: drivers that "map arbitrary kernel, physical, or device memory to user mode," drivers that "provide access to storage that bypass Windows access control," drivers whose IOCTLs let a local admin become an arbitrary kernel writer. Every one of those drivers was signed. Every one of those signatures was valid. Every one of those binaries was loadable on a default Windows install.

By the Windows 11 22H2 update in September 2022, the Vulnerable Driver Block List was enabled by default [@msft-driver-blocklist]. The mechanism is a Microsoft-curated SiPolicy.p7b (the same WDAC binary policy format), distributed through Windows Update and Defender intelligence updates, enforced by the Code Integrity engine -- with HVCI when present -- at every driver load. The published rules deny drivers by publisher, original filename, and hash. Critically, the publisher's signature is still valid. The Block List is an explicit Microsoft veto layered on top of a working PKI verdict.

The blocklist included in this article ... usually contains a more complete set of known vulnerable drivers than the version in the OS and delivered by Windows Update. -- Microsoft Learn, *Microsoft recommended driver block rules* [@msft-driver-blocklist]

That sentence, in Microsoft's own documentation, is the breakthrough. Microsoft is openly admitting that the version of the list shipped with the operating system trails the curated reference list. Curation is now a continuous, asynchronous activity, distinct from signing. The list ships on a quarterly cadence. New BYOVD drivers ship faster than that. The LOLDrivers community catalogue tracks hundreds of vulnerable drivers, many of which are not (yet) on Microsoft's list [@loldrivers].

The Block List has a write-time companion. ASR rule 56a863a9-875e-4185-98a7-b882c64b5ce5, "Block abuse of exploited vulnerable signed drivers," prevents writing a known-vulnerable driver to disk in the first place [@learn-asr-reference]. The defence is layered: the Block List denies load; the ASR rule denies install; together they form a curtain across the BYOVD attack class. Together they do not close the BYOVD class -- the catalogue is a list, the threat is a set, and the gap is structural.

Key idea: A signature attests who. A reputation score attests unfamiliar versus seen-good. A block list attests Microsoft has revoked trust at runtime, even though the signature still verifies. These are three distinct identity layers, and 2022 is the year all three were finally co-deployed by default on the same operating system.

Note: "Curated identity at runtime" is the conceptual breakthrough. "Quarterly cadence" is its operational ceiling. The Driver Block List is a list, the BYOVD threat is a set, and the gap between them is the open problem the next layer (Pluton + attestation + faster curation pipelines) is being asked to close.

The Driver Block List is the operational expression of a 25-year admission. After 1996's "the new Microsoft Authenticode technology uniquely identifies the publisher," after Vista's "we will refuse unsigned kernel drivers," after Windows 8.1's "signer level mediates inter-process access," after Windows 10's "App Control names policy in publisher vocabulary," Microsoft's December 2021 blog post said something different. It said: a signature is a publisher claim; trust is a different claim; we, Microsoft, will curate the second claim continuously, even when we ourselves issued the first one. Identity has become curated, not just verified.

If even Microsoft can no longer trust a valid signature, where does trust ultimately have to live?

The 2026 stack and the hardware future

The eight primitives from the previous sections do not run in isolation. They compose. A modern Windows boot -- on a Pluton-equipped 2026 laptop running Windows 11 24H2 with HVCI on, App Control in enforce mode, Smart App Control on, and Microsoft Defender as the active anti-malware -- evaluates code identity continuously, top to bottom, from firmware through user mode.

flowchart LR A["UEFI Secure Boot
firmware-rooted PKI"] --> B["Pluton / TPM
measured boot, PCRs"] B --> C["KMCS
chain-to-Microsoft"] C --> D["Driver Block List
Microsoft curated veto"] D --> E["ELAM
signer-level boot gate"] E --> F["User-mode Authenticode
publisher attribution"] F --> G["PPL signer-level
runtime ACL"] G --> H["AppContainer + Package SID
per-app principal"] H --> I["App Control for Business
publisher policy"] I --> J["MOTW + SmartScreen
origin + reputation"] J --> K["Pluton attestation
device-identity claim"]

The hardware root has shifted in five years. Pluton, announced on November 17, 2020 by Microsoft together with AMD, Intel, and Qualcomm, is a security processor integrated into the CPU die rather than a discrete TPM chip on the motherboard bus [@ms-pluton-blog]. AMD Ryzen 6000-series and later (including Ryzen AI), Intel Core Series 3, Core Ultra Series 3, and Core Ultra 200V, and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series ship Pluton as the on-die TPM. Pluton's firmware is updated through Windows Update -- not through OEM-controlled SPI flash patches -- and Microsoft started delivering Rust-based Pluton firmware on 2024 AMD and Intel systems, with broader rollout ongoing [@learn-pluton].

The architectural significance is twofold. The trust root is no longer a chip with its bus exposed to a trace-and-sniff attacker. The firmware update path is now a Microsoft-controlled channel rather than thirty different OEM-controlled channels. The same hardware root is what BitLocker depends on when it seals the Volume Master Key to a measured boot chain via TPM PCRs [@ms-bitlocker]. On Pluton, those PCR measurements live in-die rather than on a bus-exposed chip, and the sibling article BitLocker on Windows traces what that buys and what it does not.

Apple Gatekeeper plus Notarization is a single-CA model. All Mac binaries that pass Gatekeeper are notarized by Apple, scanning happens server-side, and Apple's own notary signature is the trust root [@apple-gatekeeper]. Linux IMA-Appraisal expresses code identity as a per-host keyring of cryptographic measurements; the kernel evaluates a load against a policy stored in the same keyring [@linux-ima]. Android APK Signature Scheme v3 binds the APK to a per-app signing key with an explicit proof-of-rotation chain that lets a publisher rotate keys without breaking the app's identity [@apksigning-v3]. Windows is the only one of the four that accepts third-party CAs in user mode while reserving Microsoft roots for the kernel. The cost of pluralism is exactly the long tail of failure modes this article enumerates; the benefit is the freedom every Windows ISV has used since 1996 to ship without asking Microsoft's permission.

Then came July 19, 2024.

CrowdStrike's Falcon kernel driver loaded a malformed Channel File 291 update that triggered an out-of-bounds memory read inside csagent.sys and raised an invalid page fault [@msft-crowdstrike-best-practices], bug-checking roughly 8.5 million Windows endpoints simultaneously [@ms-crowdstrike-blog]. The driver was correctly Microsoft-signed through the Hardware Developer Center attestation pipeline. Every code-identity layer in the stack -- KMCS, the cross-cert, the EV cert, the attestation key, even the Block List -- said yes. The thing that went wrong was not identity. It was that an identity-blessed driver, running in kernel mode, can fail in ways that take entire continents offline.

Note: The CrowdStrike outage proves that a correctly-signed, attested kernel driver is still a planet-scale liability if its placement is wrong. Identity is not the only dimension. Where in the privilege hierarchy a binary runs is itself a dimension that signing cannot capture.

Microsoft's reaction was structural. On September 12, 2024, David Weston published the recap of the September 10 WESES summit Microsoft had hosted with its endpoint-security partners, committing to provide "additional security capabilities outside of kernel mode" so that EDR vendors could run their detection logic in user mode [@weston-2024].

On June 26, 2025, the Windows Resiliency Initiative announced a private preview of the new endpoint security platform, scheduled for July 2025 delivery to selected MVI partners: Bitdefender, CrowdStrike, ESET, and SentinelOne [@weston-2025]. CrowdStrike's representative was Alex Ionescu, now its Chief Technology Innovation Officer -- the same Alex Ionescu whose 2013 Breakpoint talk publicly mapped PPL signer levels. The arc had closed in twelve years.

MVI 3.0 -- the Microsoft Virus Initiative, version three -- adds Safe Deployment Practices as a contractual condition: staged rollouts, deployment rings, monitoring. The same playbook Microsoft itself follows for Windows updates after the 2024 outage [@msft-crowdstrike-best-practices].

The conceptual move is the same one PPL made in 2013, projected one layer higher. Then: identity becomes a runtime ACL between processes. Now: identity-bound placement (kernel mode versus user mode) becomes a trust dimension co-equal with identity-bound signing. The question is no longer "is this driver signed and on the allow list?" The question is "should code with this identity be running in this context at all?"

If even attested, signed, blessed kernel code can fail catastrophically, what could code identity in principle ever prove -- and what is provably out of reach?

Theoretical bounds and open problems

Two papers from the 1980s bound everything that followed.

Fred Cohen's 1984 paper at IFIP-Sec, republished in Computers & Security in 1987, proved that perfect virus detection is undecidable: there is no algorithm that, given an arbitrary program, can decide whether it is a virus [@cohen-1986]. Reputation systems are necessarily heuristic. The "first 1,000 downloads" gap -- the window where SmartScreen has not yet seen enough of a new binary to be confident -- is structural, not a tuning problem. You cannot close it by waiting harder.

Ken Thompson's 1984 ACM Turing Award lecture, "Reflections on Trusting Trust," made a different point about a different layer [@thompson-trusting-trust]. Thompson exhibited a compiler that, when used to build itself, inserted a backdoor into a target program; when used to build the compiler, propagated the backdoor invisibly to the next-generation binary. Signing what the compiler emitted never proved the compiler was unmodified. SLSA Level 3+ provenance, reproducible builds, hermetic build environments [@slsa-spec] push the bound back one level. They do not eliminate it.

A third bound is Authenticode-specific. Asynchronous revocation, the property that lets pre-revocation timestamped signatures continue to verify forever, is the reason Stuxnet's drivers loaded after Realtek's certificate was revoked, and the reason every other stolen-key compromise has a window of cryptographic legitimacy [@symantec-stuxnet]. Synchronous global revocation would invalidate large catalogs of legitimate, archived, signed software whose signing certs have since expired. There is no fix inside the design.

Pulled together, these bounds explain the persistent gap. Stolen-but-not-yet-revoked publisher keys are the same failure mode replayed three times in sixteen years: Stuxnet (2010, Realtek and JMicron), ASUS ShadowHammer (operation 2018, disclosed 2019, ASUSTeK production key), Bitwarden CLI (2026, npm publishing credential). The Pluton firmware-update pipeline is the most credible architectural response yet -- a Microsoft-controlled key-rotation channel that does not depend on OEM-side custody -- but it does not eliminate the class. It compresses the response window.

The other open problem is identity for non-PE artifacts. The Authenticode hash and the WDAC publisher rule were designed for Portable Executable files; everything else gets uneven coverage. PowerShell .ps1 scripts can be signed and gated through Constrained Language Mode, which the runtime enters automatically when an AppLocker or App Control policy is in force [@learn-clm]. .NET assemblies have strong-name signatures, separate from Authenticode and explicitly not a security boundary; Microsoft's own documentation warns "do not rely on strong names for security" [@learn-strong-name].

JIT-compiled code -- the most common shape of "code" in 2026 -- is signed only insofar as the JIT host is signed. The JIT itself produces unsigned bytes. Container images, WSL guests, AI model files, and (now) agent prompts all live outside the Authenticode universe entirely. Each is its own substrate, with its own emerging signing scheme, and the unification has not happened.

$$\text{trust}_{2026}(\text{binary}) = \text{publisher}(\text{binary}) \land \text{provenance}(\text{build}) \land \text{placement}(\text{runtime}) \land \text{reputation}(\text{telemetry}) \land \neg \text{revoked}(\text{Microsoft})$$

That conjunction is the 2026 verdict. None of its terms are sufficient on their own. Each was forced into existence by a failure of the term before. The arc from "who launched this thread?" in 1993 to that conjunction in 2026 is what thirty-three years of forced moves produced.

What does the layered system look like in practice on a 2026 endpoint -- and what should an admin actually do?

Practical guide

Six concrete recommendations for a 2026 Windows fleet, each tied to a primary Microsoft Learn or MSRC source.

Note: On Windows 11 22H2 and later it is enabled by default. On Windows 10, Server, and downlevel Windows 11 builds, enable it explicitly through Settings > Privacy & security > Windows Security > Device security > Core isolation > Microsoft Vulnerable Driver Blocklist. HVCI must be on for full enforcement [@msft-driver-blocklist].

Note: The published Microsoft baseline policies (Default Windows, Allow Microsoft, the Windows S Mode policy) are the right starting points. Run any custom policy in audit mode for a full reference-image cycle, mine the Microsoft-Windows-CodeIntegrity/Operational event log for blocked loads, then promote to enforce. Pair with HVCI so the policy lives behind the secure-kernel boundary [@ms-appcontrol]. Deploy through Microsoft Intune (or your MDM of choice), Configuration Manager, or Group Policy -- App Control policy distribution is a first-class managed-endpoint scenario rather than a per-machine hand edit [@learn-appcontrol-deployment].

Note: On Secure Boot systems the value is mirrored into a UEFI variable, so registry-only attackers cannot turn it off. Verify with Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name RunAsPPL and the corresponding RunAsPPLBoot UEFI variable [@itm4n-runasppl].

Note: SmartScreen alone is bypassed by container-format MOTW stripping. Pair it with ASR rule 01443614-cd74-433a-b99e-2ecdc07bfc25, which gates execution on prevalence, age, or a trusted list, independently of MOTW [@learn-smartscreen] [@learn-asr-reference].

Note: The Package SID is a free identity for any internal app you ship as MSIX. ACL sensitive resources to it, declare capabilities explicitly in the manifest, and let the AppContainer SID enforce the ACL at the kernel boundary [@ms-package-identity] [@ms-msix].

Note: Treat your code-signing key like a credential, not a build artifact. Rotate the EV cert, revoke the old one, notify customers, and -- if the binary already shipped -- request the offending hash on the Driver Block List or the ASR rule [@msft-driver-reporting]. The Bitwarden CLI 2026 incident took 93 minutes from release to containment, with rollback continuing for several hours afterward [@bitwarden-statement]; have the playbook ready before you need it.

```js function loadDecision({ signed, signerLevel, motwed, onBlockList, allowedByAppControl, smartScreenVerdict }) { if (onBlockList) return 'BLOCK -- Microsoft veto, signature ignored'; if (signed === false && allowedByAppControl === false) return 'BLOCK -- unsigned, App Control denies'; if (signerLevel === 'WinTcb' || signerLevel === 'WinSystem') return 'LOAD -- protected process'; if (allowedByAppControl === false) return 'BLOCK -- App Control deny'; if (motwed && smartScreenVerdict === 'unknown') return 'WARN -- SmartScreen, user gate'; if (motwed && smartScreenVerdict === 'malicious') return 'BLOCK -- SmartScreen'; return 'LOAD'; } console.log(loadDecision({ signed: true, signerLevel: 'Authenticode', motwed: true, onBlockList: false, allowedByAppControl: true, smartScreenVerdict: 'good', })); ``` The decision tree is the practical mental model. Every branch of it is the consequence of one of the failures this article tracks. No. A signature attests *publisher identity* and *binary integrity*. It does not attest safety. Microsoft trust is a separate, runtime claim expressed through the Driver Block List, App Control policies, and Defender reputation -- evaluated continuously, even on signatures Microsoft itself once minted [@msft-driver-blocklist]. Extended Validation Authenticode signing vets organisational identity through an audited issuance process and mandates that the private key live in a hardware security module; the publisher's signature is the trust root. Attestation signing is Microsoft's lighter-weight pipeline for kernel drivers: the publisher submits an EV-signed binary to the Hardware Developer Center, Microsoft re-signs with its own attestation key, and the result is delivered back. Attestation-signed drivers are not WHQL tested and are not distributed via retail Windows Update [@learn-driver-signing-offerings] [@ms-attestation-signing]. MOTW plus low prevalence. SmartScreen sees a binary it has not observed enough times in the global telemetry to be confident, on a file marked as having been downloaded from the internet. Sign the binary with an EV certificate, accumulate downloads on a stable hash, and the warning fades. Internal binaries can have MOTW stripped at deployment time if your distribution channel is itself trusted [@learn-smartscreen]. No. AppLocker is the Windows 7-era policy mechanism with rules in path/publisher/hash form, no kernel coverage, and no virtualization-based protection of the policy itself. App Control for Business -- formerly Windows Defender Application Control -- is the publisher-rule Code Integrity policy mechanism with HVCI enforcement at the kernel boundary. Microsoft recommends App Control for new deployments and keeps AppLocker for compatibility [@ms-applocker] [@ms-appcontrol]. LSASS is running as a Protected Process Light at the `Lsa` signer level. Signer-level gating sits *above* the token DACL check. Even a SYSTEM-token caller with `SeDebugPrivilege` gets a process handle with `PROCESS_VM_READ` and `PROCESS_VM_WRITE` stripped, because PPL strips access masks before the DACL evaluation. Disable LSA Protection (`RunAsPPL=0`) on a test machine and the same call succeeds [@itm4n-runasppl] [@scrt-ppl-bypass]. Only if the publisher's signing-key custody and build pipeline are themselves uncompromised. Stuxnet (stolen Realtek and JMicron keys, 2010), ASUS ShadowHammer (compromised production signing pipeline, operation 2018 / disclosed 2019), and the Bitwarden CLI npm incident (2026) all produced cryptographically valid signatures on attacker-controlled bytes [@symantec-stuxnet] [@securelist-shadowhammer] [@bitwarden-statement]. SLSA-level build provenance and Pluton-rooted attestation are the architectural responses; neither is yet universally deployed [@slsa-spec] [@learn-pluton].

Where this is going

Pluton-rooted device attestation, MVI 3.0's user-mode security platform, SLSA build provenance, and the post-CrowdStrike push to make placement a first-class identity attribute are all in motion in 2026 [@weston-2025] [@slsa-spec]. The follow-on articles -- Driver Block List in production, App Control with HVCI on real fleets, Secure Boot internals, the Pluton firmware-update channel -- are the operational complement to the conceptual story this article has told.

The arc that began with Windows NT 3.1 having no answer to "who is this code?" now has eight overlapping answers, each insufficient on its own. Identity in 2026 is a multi-layered claim about a binary's publisher, its build provenance, its runtime placement, and its reputation, evaluated continuously while the code is running. The arc from 1993's "who launched this thread?" to 2026's "is this signed binary, in this placement, with this build provenance, on Microsoft's curated honour list, today, on this hardware-attested device?" is the answer thirty-three years of forced moves produced -- and the question the next thirty-three years will keep asking, because none of the bounds Cohen and Thompson proved have moved.