App Control for Business (WDAC) vs AppLocker

Antivirus asks "is this file known to be bad?". Application control asks the opposite question: "is this file known to be good?". Everything else is refused. That inversion defeats commodity malware, most ransomware droppers and the majority of hands-on-keyboard tooling that attackers bring to a host, because none of it is on your allowlist.

Windows has two built-in allowlisting technologies. This guide explains when to use which, then walks through a realistic rollout of App Control for Business (the new name for Windows Defender Application Control, WDAC).

App Control vs AppLocker

Microsoft positions App Control as the security boundary and AppLocker as a complementary control. If you are starting fresh, start with App Control.

Step 1: pick a starting policy

Don't build from scratch. Windows ships example base policies in C:\Windows\schemas\CodeIntegrity\ExamplePolicies:

The App Control Policy Wizard (a free Microsoft tool) builds on these templates with a GUI and is the easiest way to start. Everything it does can also be done with the ConfigCI PowerShell module.

Step 2: add your software and a managed installer

A policy that only trusts Microsoft blocks every third-party app. Three ways to extend it:

1. Publisher rules for software signed by vendors you trust (least maintenance).
2. Managed installer: tag Intune Management Extension or Configuration Manager as a managed installer, and anything it installs is automatically trusted. This is how most enterprises make App Control maintainable.
3. Hash rules for unsigned in-house tools, regenerated on each release.

Scan a reference machine to generate rules for what is installed:

New-CIPolicy -Level Publisher -Fallback Hash -UserPEs `
  -ScanPath "C:\Program Files" -FilePath .\ProgramFiles.xml
Merge-CIPolicy -PolicyPaths .\AllowMicrosoft.xml, .\ProgramFiles.xml -OutputFilePath .\Base.xml

Avoid path rules for user-writable locations. App Control only honours path rules when the path is writable by administrators alone, by default, which is a good safety net; do not disable that check.

Step 3: add the block rules

Allowlists trust Microsoft, and Microsoft signs tools that attackers abuse (the "living off the land" binaries). Merge in:

• Microsoft recommended block rules: a published list of signed binaries that can bypass application control (for example old versions of scripting hosts and debuggers). Include them in every policy.
• Microsoft vulnerable driver blocklist: known-vulnerable signed drivers. It is on by default for all devices since Windows 11 22H2 (and enforced whenever memory integrity, Smart App Control or S mode is active), but the in-box copy is updated less often than Microsoft's downloadable list; include it explicitly for older builds and servers.

Step 4: deploy in audit mode

Audit mode is policy rule option 3. Make sure it is set, give the policy an ID and convert it to binary:

Set-RuleOption -FilePath .\Base.xml -Option 3          # Enabled:Audit Mode
Set-RuleOption -FilePath .\Base.xml -Option 16         # Enabled:Update Policy No Reboot
Set-CIPolicyIdInfo -FilePath .\Base.xml -PolicyName "Corp Base" -ResetPolicyID
ConvertFrom-CIPolicy -XmlFilePath .\Base.xml -BinaryFilePath .\Base.cip

Deploy it with Intune (Endpoint security > App Control for Business), Configuration Manager, Group Policy (System > Device Guard > Deploy Windows Defender Application Control, renamed for App Control in newer ADMX; single-policy format only), or locally with CiTool on Windows 11 22H2 and later:

CiTool.exe --update-policy .\Base.cip
CiTool.exe --list-policies

Step 5: read the events

Code integrity events are in Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational. Script and MSI events are in AppLocker > MSI and Script even when App Control is the enforcing technology.

Collect a few weeks of 3076 events from the pilot. You can generate a supplemental policy straight from the audit log:

New-CIPolicy -Audit -Level Publisher -Fallback Hash -UserPEs -FilePath .\FromAudit.xml

Review that output by hand. Audit data from a machine that was already compromised, or where a user ran a random download, will happily allow things you don't want.

Step 6: enforce, ring by ring

Remove option 3 (Set-RuleOption -Option 3 -Delete), convert and deploy to a first ring of IT devices, then pilot users, then everyone. Keep the audit policy for new ring members until their events are clean.

Use supplemental policies (multiple policy format, Windows 10 1903+) so that application owners can extend the base policy without touching it. Once stable, sign the base policy; a signed policy cannot be removed without a signed update, which stops an attacker with admin rights from simply deleting it.

When AppLocker still makes sense

• Per-user rules on shared machines (kiosk staff accounts vs. administrators).
• Quick wins on legacy systems where you cannot deploy App Control yet: at minimum, block execution from %USERPROFILE%, %TEMP% and %APPDATA% for standard users.

If you use AppLocker, remember that the default rules allow everything under %WINDIR% and %PROGRAMFILES%, and some subfolders of C:\Windows (such as C:\Windows\Tasks and C:\Windows\Temp) are writable by standard users. Add explicit deny rules for those or use publisher rules instead of the path defaults. AppLocker requires the Application Identity service (AppIDSvc) set to automatic; its events are under AppLocker > EXE and DLL: 8003 (audit: would be blocked) and 8004 (blocked).

Get-AppLockerPolicy -Effective -Xml > effective.xml
Get-ChildItem C:\Users\Public -Recurse -Filter *.exe | Convert-Path |
  Test-AppLockerPolicy -XmlPolicy .\effective.xml -User Everyone

Checklist

• Technology chosen: App Control as baseline, AppLocker only where it adds value
• Base policy from a Microsoft example, plus recommended block rules and driver blocklist
• Managed installer configured for your deployment tool
• Audit mode on a pilot, 3076 / 8028 events reviewed for at least two weeks
• Enforced ring by ring; supplemental policies for app owners
• Base policy signed once stable
• 3077 events forwarded and alerted

Application control is the control that makes most others easier: it forces PowerShell into Constrained Language Mode, makes ASR rules a second line rather than the first, and turns "user ran something" into a logged, blocked event.