AppLocker vs App Control for Business

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 [537]: 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) [566] 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 [537]. 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.

Microsoft's own App Control and AppLocker Overview page makes the line explicit. AppLocker [537], 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" [537]. The MSRC servicing criteria are not marketing copy. They are the rule that decides whether a defect in a Windows feature gets a CVE [301]. AppLocker bypasses do not get CVEs. App Control bypasses, with the right configuration, do.

The rest of this chapter 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.

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.

Pre-history: Why an OS needs Application Control at all

The 1999-2001 macro-virus and worm era (ILOVEYOU [567], Code Red [568], Nimda [569]) made it unsurvivable for Windows to trust any binary the user had Execute permission on. The default behavior 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 [570].

SRP supported five rule conditions [571]: 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 honored at CreateProcess. The model was right: a per-machine GPO-administered policy evaluated against a defined file taxonomy.

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 narrow: it applied only to Windows Installer (.msi) packages and keyed off the source zone Windows Installer computed at install time, so it never covered the .exe and script payloads that mattered most.

SRP is genealogy, not subject matter, for the rest of this chapter. 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?

AppLocker Architecture

October 22, 2009. AppLocker ships in Windows 7 Enterprise / Ultimate and in Windows Server 2008 R2 [572] [573]. What did Microsoft actually build, exactly as Microsoft Learn documents it?

Five rule collections [574]:

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 [575]. Hold that thought; it returns in the side-by-side comparison.

Three rule conditions:

1. Publisher: the Authenticode subject name, product name, file name, and minimum file version. The load-bearing usability win over SRP: a single Publisher rule for "binaries signed by Microsoft Corporation with product Office, version 16.0 or higher" survives every patch the vendor ships.
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.

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 [575]; we will return to that in the why-both-still-ship section.

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 [562]: 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 honors the verdict the service returns.

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

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?

AppLocker's structural limit

A single PowerShell line. sc.exe stop AppIDSvc from a LocalSystem context: the canonical first-step bypass cataloged in UltimateAppLockerByPassList [564] and reproduced in Oddvar Moe's December 2017 case study [577] [578]. 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 [537]: "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 [301] 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 previous 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 [562]: "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 [564] catalogs 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 [577] 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 [576] 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 chapter'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:

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.

The generational pivot

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 [566]. 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 [566]. Post-Pass-the-Hash, post-APT, the working assumption was that the adversary reaches administrator quickly, and that any control whose enforcement could be turned off by an administrator was therefore not, in itself, a defense against the modern adversary. AppLocker could not be retrofitted to defend against that model because its evaluator lives in user mode by design. The fix was structural: build a peer mechanism in the kernel Code Integrity component.

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

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

The naming convention this chapter uses: lead with "App Control for Business (still widely called WDAC)" on first mention, then use App Control except when quoting third-party sources or search terms. The community search term "WDAC" stays in the title and tags because much practitioner content still uses it.

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?

The mechanism in detail

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 [279]. The integration builds on documented kernel API surfaces: PsSetLoadImageNotifyRoutine [583] registers an image-load callback, and PsLookupProcessByProcessId [584] resolves the loading PID to an EPROCESS so the load can be attributed to the right process; the full internal enforcement path inside ci.dll is not public, and the documented load-image notification callbacks are a related surface rather than the blocking enforcement path itself. 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 [585]. 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 [586].
• The file's ISG reputation: covered in the ISG section [587].

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

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 organization'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 organization 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 replace the policy without the corresponding private key. This is the only configuration whose policy integrity survives an admin-equivalent attacker: which, as later sections show, is not the same as containing everything such an attacker can do.

App Control policies are signed by the deploying organization'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 organization's signing key.

HVCI integration. When Virtualization-Based Security is on, the kernel CI evaluator itself runs in VTL1 inside HVCI (memory integrity, in Windows 11 Settings) [279] [579]. 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.

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) [589], and KB5036892 for Windows 10 21H2 and 22H2 (OS Builds 19044.4291 and 19045.4291) [590]. Microsoft's Deploy multiple App Control for Business policies page is explicit on the version scope [591]: "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.

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.

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 [587]:

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 [587]

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" [587]. The classifier sits underneath the policy's explicit rules; it does not override them.

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 honor the verdict at subsequent image loads without a fresh cloud call. The cloud reputation model itself is processed every 24 hours [587]; 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 misconception this section closes is that ISG is a list of curated allowed apps: a corporate-managed allowlist administered by Microsoft. It is not. Calling ISG "cloud-reputation-driven allow-listing" is half-true in spirit and wrong in mechanism. ISG is reputation. The allowlist is what the App Control policy still has to author explicitly.

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?

Where this link breaks

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

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 [593]. 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 [594]. 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 [595]. 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 [596]. The .NET Framework System.AddIn out-of-process add-in host (%WINDIR%\Microsoft.NET\Framework\v4.0.30319\) that can be coerced into loading an attacker DLL while the parent process satisfies the signed-publisher policy.
• dotnet.exe: Jimmy Bayne, August 2019 [597]. 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 App Control.

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

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.

The community corpus. Jimmy Bayne's bohops/UltimateWDACBypassList [565] preserves per-binary attribution to Forshaw, Smith, Nelson, Graeber, Moe, and others. Pair with the LOLBAS Project [592] as the cross-platform LOLBin catalog 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 [563]. 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.

"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 [596]

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

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.

Smart App Control

Windows 11 22H2 ships on September 20, 2022 [383] [580]. Microsoft introduces Smart App Control (SAC) for consumer Windows. It runs on the same kernel CI machinery as App Control for Business [599]. 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 [599]. On an eligible clean install of Windows 11 22H2 or later, SAC starts in evaluation mode and either moves to enforcement or turns itself off, depending on whether Microsoft assesses the device as a good fit.

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 [599].
• Enterprise-managed devices keep it off: SAC stays off if "your device is enterprise-managed or developer-mode has been configured" [600].

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 [600] 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) [599].