# AppLocker vs App Control for Business: Two Locks on the Same Door, and Why Windows Still Ships Both in 2026
> Windows 11 24H2 ships two parallel application-control systems. One is operational hygiene; the other is the security boundary. The line between them is a single sentence in MSRC servicing criteria.
*Published: 2026-06-01*
*Canonical: https://paragmali.com/blog/applocker-vs-app-control-for-business-two-locks-on-the-same-*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
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](/blog/windows-security-boundaries-the-document-that-decides-what-g/) 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]:
1. **Executable** -- `.exe`, `.com`
2. **DLL** -- `.dll`, `.ocx` (off by default; opt-in for performance reasons)
3. **Script** -- `.ps1`, `.vbs`, `.js`, `.bat`, `.cmd`
4. **Windows Installer** -- `.msi`, `.msp`, `.mst`
5. **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**:
1. **Publisher** -- the [Authenticode](/blog/authenticode-and-catalog-files-the-crypto-foundation-under-w/) 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.
2. **Path** -- with environment-variable and wildcard support (`%ProgramFiles%\Contoso\*.exe`).
3. **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.
**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](/blog/mimikatz-and-the-credential-theft-decade-the-windows-securit/), 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](/blog/windows-kernel-code-integrity-2006-2026/), 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] |
**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](/blog/the-windows-secure-kernel/) is on, the kernel CI evaluator itself runs in VTL1 inside **[HVCI](/blog/wdac--hvci-code-integrity-at-every-layer-in-windows/)** (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 allow*list* 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](/blog/living-off-the-land-on-windows-the-lolbin-catalog-and-the-st/) 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.
**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
> **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 `` 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.
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](/blog/attack-surface-reduction-rules-the-quiet-layer-that-stopped-/)* 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.