WDAC or AppLocker: which application control to actually deploy, and why running both is a trap

Windows ships two application control stacks. Not one with two names. Two, with separate engines, separate policy stores, separate event logs and separate futures. One is App Control for Business, which most people still call WDAC. The other is AppLocker, which most people inherited from someone who left in 2016.

They overlap in purpose and differ in almost every mechanical detail. That combination is what produces the support ticket nobody can close: a file that one engine allows and the other blocks, with the block event sitting in a log channel nobody thought to open. This post explains what each stack actually enforces, at which layer, where its policy lives, which Event IDs it writes, and what Microsoft's own documentation says about choosing between them. Then it walks the audit-first path for whichever one you pick.

The problem: enforcement nobody can explain

The pattern is always the same. A team inherits an AppLocker policy from an old Group Policy Object. Somebody reads that App Control for Business is the strategic direction and deploys an App Control policy from Intune. Nobody removes the AppLocker rules, because nobody is certain what they still protect.

Now the device has two enforcement engines running at once. Three symptoms follow.

First, a line-of-business executable runs for one user and not another. That is a signature of AppLocker, because AppLocker rules carry a security identifier and can be scoped to a user or a group. App Control policies cannot: they apply to the managed computer as a whole and affect every user of the device.

Support then looks in the wrong log. App Control block events live in Microsoft-Windows-CodeIntegrity/Operational. AppLocker events live under a completely different tree with four sub-channels. If you only opened one of them, you concluded the block did not happen.

Second, a PowerShell script silently runs with fewer capabilities instead of failing. That is not a bug. It is App Control script enforcement handing the script host a verdict, and PowerShell responding by running the script in Constrained Language Mode rather than refusing outright.

Third, an App Control allow rule is added and the file still will not run. That is the part that breaks people's mental model. An allow rule in one stack does not override a deny in the other. The two stacks are not merged, ranked or reconciled anywhere.

Why it happens: two engines, two layers, two log trees

To untangle a device you need to know what each stack is, mechanically, before you touch any policy. Start with plain English definitions, then follow the call chain.

What App Control for Business is

App Control for Business is a code integrity policy. You compile an XML policy into a binary and place it where the Windows Code Integrity engine reads it. That engine lives in C:\Windows\System32\ci.dll and it is part of the operating system's code loading path, not an add-on. There is no service to start. If an active policy exists, it is being evaluated.

Because it is a code integrity policy, it can cover kernel mode drivers as well as user mode applications. Microsoft designed it as a security feature under the Microsoft Security Response Center servicing criteria, which in practice means a documented bypass is treated as a security vulnerability.

App Control rules can be built from the code signing certificate, from signed file metadata such as original filename and version, from the file hash, from the file path, from the reputation of the app according to Microsoft's Intelligent Security Graph, from the identity of the process that installed the app (the managed installer), or from the process that launched the binary.

What AppLocker is

AppLocker is an access control mechanism layered on top of process creation, DLL loading and script host callbacks. Microsoft's architecture documentation is specific about the mechanism: AppLocker policies are conditional access control entries, evaluated using the attribute-based access control functions SeAccessCheckWithSecurityAttributes or AuthzAccessCheck.

There are three interception points, and understanding them explains every AppLocker symptom you will ever see:

1. A new process is created. AppLocker calls the Application Identity component to calculate the attributes of the main executable, updates the new process token with those attributes, then checks the policy.
2. A DLL is loaded. A notification goes to AppLocker, which duplicates the process token, swaps in the DLL's attributes, evaluates the policy, and discards the duplicate token. This is why DLL rules are expensive.
3. A script is run. The script host - PowerShell, for example - calls AppLocker before running the file. AppLocker calls Application Identity in user mode to calculate file properties, then evaluates.

Every one of those paths depends on the Application Identity service. Microsoft's wording is blunt: stopping this service prevents AppLocker policies from being enforced. That single sentence explains most "AppLocker is not working" tickets.

What each one covers

AppLocker divides code into five rule collections, and the file extensions are documented exactly:

App Control is not organised by extension. It evaluates code as the loader encounters it, which is why its coverage includes kernel drivers that AppLocker cannot touch, and why a poorly built App Control policy can slow boot or prevent it. Microsoft explicitly recommends building on the supplied base templates so that Windows signers are trusted, because App Control evaluates all processes that run, including inbox Windows processes.

Microsoft's documented guidance on choosing

This is the part worth quoting rather than paraphrasing, because it settles most internal arguments. From the App Control and AppLocker overview: "Generally, customers who are able to implement application control using App Control, rather than AppLocker, should do so. App Control is undergoing continual improvements, and is getting added support from Microsoft management platforms. Although AppLocker continues to receive security fixes, it isn't getting new feature improvements."

That is the current support statement. AppLocker is not deprecated and not removed. It is in security-fix-only maintenance. The AppLocker overview page adds a second, sharper note: AppLocker "is a defense-in-depth security feature and not considered a defensible Windows security feature", and App Control "should be used when the goal is to provide robust protection against a threat".

Microsoft then names the two cases where AppLocker is still the better answer: a mixed Windows estate where you need the same controls on versions older than Windows 10, and shared computers where you need different policies for different users or groups.

On running both, the documentation is permissive but specific. "AppLocker can also be deployed as a complement to App Control to add user or group-specific rules for shared device scenarios... As a best practice, you should enforce App Control at the most restrictive level possible for your organization, and then you can use AppLocker to further fine-tune the restrictions."

Read that carefully. It sanctions AppLocker as a deliberate narrowing layer on top of an App Control baseline. It does not sanction two independently authored, independently owned allow-lists that were never designed together. That distinction is the whole difference between a supported design and the trap.

Why both-active behaves the way it does

There is no published precedence table between the two stacks, because there is no arbitration between them. Each is an independent gate on the same execution attempt. A file that fails either one does not run.

Microsoft documents the equivalent behaviour inside App Control, and it is the clearest available statement of the intersection model: "If two base policies exist on a device, an application must pass both policies for it to run." The design page states it as a rule - multiple base policies intersect, and only applications allowed by both run without generating block events. Supplemental policies are the opposite: a base plus its supplementals is a union.

Within a single App Control policy set, evaluation order is documented as well. Deny rules win first, then explicit allow rules, then managed installer or Intelligent Security Graph extended attributes, then reputation, and anything left over is blocked implicitly. That last line is the one that surprises people: an App Control policy is default-deny.

The binaries involved

Naming the actual files makes the two layers concrete.

How to verify: prove which stack is actually enforcing

Before changing anything, establish ground truth. Every command below is read-only. Run them elevated - the Code Integrity channel, CiTool and the Device Guard WMI class all need administrator rights.

Step 1: ask the Code Integrity engine what it is enforcing

The Device Guard WMI class reports enforcement mode as a number. Kernel and user mode are reported separately, and that separation matters enormously.

Step 2: list the App Control policies on the device

CiTool dumps every policy, active or not. The two fields that matter are IsEnforced and FriendlyName. Microsoft's own example filters on enforcement state.

You can corroborate that against the files on disk. Microsoft documents the policy file locations precisely, and the presence of the legacy filename is itself a finding.

Signed policies must be deployed into the EFI System Partition, which is why a signed policy survives an operating system reinstall and why removing one is a documented, careful procedure rather than a file delete.

Step 3: ask AppLocker what it is enforcing

The effective policy is the merged result of every AppLocker source that applies. If the object has zero rule collections, no AppLocker policy is in effect at all.

Then confirm the enforcement machinery is actually running, because rules without the service are decoration.

Step 4: read the registry, both stores

AppLocker's policy store predates the current naming. In the registry the feature is still called Software Restriction Policies version 2. Parent key, stated once:

App Control's own state lives under the Code Integrity control key. Only one value here is documented, and it is a diagnostic switch:

Step 5: read both event trees

This is the step that resolves the "allowed by one, blocked by the other" ticket. There are two channel families. State each once, then map the IDs.

Step 6: the scheduled task and the log files

AppLocker has exactly one documented scheduled task, and it is on-demand rather than periodic. The AppLocker overview's baseline settings table states: "Appidpolicyconverter.exe is put in a scheduled task to be run on demand." That converter is what turns a deployed policy into the *.AppLocker cache files under C:\Windows\System32\AppLocker. If those files are missing while a policy exists, the conversion is where to look, and event 8000 is the matching failure signal.

App Control has no equivalent task and no text log file. Its policy binaries are the state, and the Operational channel is the log. That is genuinely a point of asymmetry between the stacks, and it is worth saying out loud: there is no App Control log file to tail. If you want file-level authorisation evidence rather than block events, Microsoft's documented route is fsutil.exe file queryEA against a file, looking for the $KERNEL.SMARTLOCKER.ORIGINCLAIM extended attribute that managed installer and the Intelligent Security Graph write.

The fix: pick one, audit first, retire the other

The decision follows directly from the documented guidance. Two questions decide it.

1. Do you need per-user or per-group application rules on shared devices? If yes, AppLocker is the only stack that can express them, because App Control applies to the whole computer. If no, App Control alone is sufficient.
2. Do you still manage Windows versions older than Windows 10? If yes, AppLocker gives you one policy across the estate. If no, that argument is gone.

Two noes means deploy App Control and retire AppLocker. Any yes means you have a legitimate reason to keep AppLocker - but keep it as the documented narrowing layer on top of an App Control baseline, authored by the same people, in the same change, with both audit trails reviewed together.

Deploy App Control in audit mode from Intune

Intune's App Control for Business policies use the ApplicationControl configuration service provider. Microsoft states this CSP was introduced to replace the AppLocker CSP, and that while the AppLocker CSP is still supported, no new features are being added to it and development continues through ApplicationControl.

1. Sign in to the Microsoft Intune admin center.
2. Go to Endpoint security and select App Control for Business.
3. Select the App Control for Business tab, then Create Policy. The platform type is assigned automatically.
4. On Basics, enter a name and a description you will recognise in a report six months from now.
5. On Configuration settings, choose a Configuration settings format. Built-in controls is the simplest path; Enter xml data takes a policy you authored yourself.
6. With built-in controls, set Enable trust of Windows components and store apps to Audit only. This is the whole point of the first deployment: events are logged in the local client logs but apps are not blocked.
7. Under Select additional options for trusting apps, choose Trust apps from managed installers and/or Trust apps with a good reputation as your design requires.
8. On Scope tags, apply your scope tags, then Next.
9. On Assignments, target device groups. App Control policies apply to the device scope only, so a user group will only affect the devices inside it.
10. On Review + create, select Create.

If you want Intune-deployed apps trusted automatically, the managed installer policy is a separate tab in the same node.

1. Select the Managed installer tab, then Create.
2. Name the policy on Basics.
3. On Settings, set Enable Intune Managed Extension as Managed Installer to Enabled, which is the default.
4. Apply scope tags, then include or exclude device groups on Assignments.
5. Review + create. Allow up to ten minutes for the policy to appear and up to thirty for devices to receive it.

Deploy App Control from Group Policy, and know the limitation

The GPO route exists, but it is deliberately constrained.

1. On a machine with the Remote Server Administration Tools installed, run GPMC.MSC.
2. Right-click the target organisational unit and choose Create a GPO in this domain, and Link it here. Name it.
3. Right-click the new GPO and choose Edit to open the Group Policy Management Editor.
4. Navigate to Computer Configuration\Administrative Templates\System\Device Guard.
5. Right-click Deploy App Control for Business and choose Edit.
6. Select Enabled and specify the local path or the UNC path where clients will fetch the policy binary.
7. Close the editor and restart a test machine. Restarting is what updates the policy.

Deploy AppLocker in audit mode

AppLocker's own console path is a different branch of the policy tree entirely - Windows Settings, not Administrative Templates.

1. For a single machine open secpol.msc; for a group of machines edit a GPO in the Group Policy Management Console.
2. Expand Application Control Policies and select AppLocker.
3. Right-click AppLocker and choose Properties.
4. On the Enforcement tab, tick Configured for the rule collection you want, then select Audit only in that collection's list.
5. Repeat for each collection you intend to control, then select OK.
6. In the same GPO, go to Computer Configuration\Windows Settings\Security Settings\System Services, double-click Application Identity, and configure it to start automatically. Without this the rules will never be evaluated.

Rules themselves are created per collection through the wizard, and can also be generated with the AppLocker cmdlets:

Intune and AppLocker: there is no settings catalog path

This is worth stating plainly because people search for it and do not find it. Intune has a first-class node for App Control for Business under Endpoint security. It has no equivalent modern node for AppLocker rules. AppLocker from Intune means the AppLocker CSP, and the CSP's own node structure is where you author it:

Sibling nodes exist for DLL, MSI, Script, StoreApps and CodeIntegrity. Microsoft's guidance on the {Grouping} segment is that the value should include some randomness and that the best practice is a randomly generated GUID, to avoid problems on unenrollment. Note also that applying or deleting a policy through the CodeIntegrity/Policy node under this CSP schedules a reboot.

Retire the loser deliberately

Neither stack should be switched off by deleting files. Both have documented removal paths, and both can leave a device blocking things after the policy is "gone".

To remove App Control enforcement, Microsoft's documented sequence is to first replace the existing policy with a version that allows everything - the example policy shipped on every device at %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml - deploy that, and only then delete the policy from Intune. Policies deleted from the Intune interface are removed from the device but stay in effect until the next reboot, so deleting first and allowing second leaves a window where the device is enforcing a policy you can no longer edit.

To remove AppLocker, the documented route is to clear the policy rather than edit around it. Microsoft also publishes two scripts for the managed installer case specifically: CatCleanIMEOnly.ps1, which removes only the Intune Management Extension as a managed installer, and CatCleanAll.ps1, which removes all AppLocker-based policies from the device. Read that second name twice before you run it.

Proof it worked: a real posture report

Reading eight surfaces by hand on every device does not scale, so there is a companion script for this post that reads all of them and states a verdict. It is read-only: no Set, New, Remove, Enable or Disable against any device setting, service or registry value. It requires no PowerShell module. It aborts with exit code 1 if any read fails, rather than printing a clean result that would be a lie.

What follows is a genuine run on a managed Windows 11 Enterprise device, with identifiers replaced. Every value below was read live.

The event pass and verdict from the same run:

What the report gives you that a single command does not is the join. Kernel enforced with user mode off, fourteen policies of which none are yours, an AppLocker service stopped with no policy behind it: individually each of those readings is easy to misinterpret, and three of them are routinely quoted as evidence that application control is deployed when it is not.

References

• App Control and AppLocker Overview - Microsoft Learn. The positioning statement, the choose-when-to-use criteria, and the complement guidance.
• AppLocker - Microsoft Learn. The defense-in-depth note, the baseline settings table naming appidsvc and the Appidpolicyconverter.exe scheduled task.
• Understanding App Control event IDs - Microsoft Learn. The two core channels, 3076/3077/3089/3099 and the 8028/8029/8036-8040 set.
• Using Event Viewer with AppLocker - Microsoft Learn. The full 8000-8040 table and the log verbosity warning.
• AppLocker architecture and components - Microsoft Learn. The three interception points and the access check functions.
• Configure the Application Identity service - Microsoft Learn. Why a stopped service means no enforcement, and the sc.exe config appidsvc start=auto requirement.
• App Control Admin Tips and Known Issues - Microsoft Learn. Policy file locations, file rule precedence order, and the ci.dll 32-policy bug check.
• Use multiple App Control for Business Policies - Microsoft Learn. The intersection rule for multiple base policies.
• Deploy App Control policies via Group Policy - Microsoft Learn. The Device Guard GPO path and the single-policy-format limitation.
• Deploy App Control for Business policies using script - Microsoft Learn. CiPolicies\Active, SiPolicy.p7b and the EFI partition path.
• Managing CI policies and tokens with CiTool - Microsoft Learn. Command reference and the --list-policies output fields.
• Managed installer and ISG technical reference - Microsoft Learn. The appidsvc and AppLockerFltr checks, the System32\AppLocker cache files and fsutil queryEA.
• Manage approved apps with App Control for Business policy in Intune - Microsoft Learn. The admin center paths, the ApplicationControl versus AppLocker CSP statement, and the AppLocker merge no-boot warning.
• AppLocker CSP - Microsoft Learn. Node structure, enforcement mode values and the {Grouping} GUID guidance.
• Enable memory integrity - Microsoft Learn. The Win32_DeviceGuard property tables, including the 0/1/2 enforcement values.
• Understanding AppLocker rule collections - Microsoft Learn. The five collections and their extensions.

Community deep-dives that verify against the same documentation: