AppLocker vs App Control for Business: Full Guide · CloudEngineerHub
Endpoint Security8 min read2 views
AppLocker vs App Control for Business: Picking the Right Policy for Your Fleet
AppLocker or App Control for Business? Compare OS support, event IDs, managed installer and a phased audit-to-enforce plan for real Windows fleets.
C
CloudEngineerHub Team
Published: September 15, 2026· Last Updated: October 3, 2026·8 min read
AppLocker vs App Control for Business: Picking the Right Policy
"Block unknown executables" has two Microsoft answers, and choosing wrong costs you a year. AppLocker is the familiar, user-and-path-oriented engine every hybrid admin has half-deployed somewhere. App Control for Business (formerly WDAC) is the signer-based, kernel-enforced policy Microsoft positions as the strategic control. Most real fleets end up running both — App Control as the foundation, AppLocker for the residual app-specific cases — but the order you deploy them and the events you trust during rollout determine whether the project lands or dies in a week of user revolts.
Visual Walkthrough
The policy engine's four questions, answered in order at execution.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
App Control Evaluation — Why Did It Run (or Not)?. Gate: Binary requests execution — Explicitly trusted: Signed by trusted signer — Explicitly trusted: Managed installer authored — Explicitly trusted: Execution allowed — Untrusted: Rule scan fails — Untrusted: ISG heuristic (if enabled) — Untrusted: Blocked in enforce — Untrusted: Tune if legitimate
Prerequisites
Editions: App Control for Business requires Windows 10/11 Enterprise or Education on Windows 10, and additionally works on Windows 11 Pro 22H2 and later. AppLocker runs on Enterprise/Education (and Pro with caveats). Neither is supported on Home.
Intune: Policy and profile admin rights for Settings catalog deployment; the App Control CSP and AppLocker CSP are reachable through custom OMA-URI where the catalog falls short.
Defender for Endpoint (Plan 2 recommended) for advanced hunting over audit events — the analysis engine that makes audit mode tractable at scale.
Tooling: the WDAC Policy Wizard (GUI) and the ConfigCI PowerShell module (New-CIPolicy, Set-RuleOption, ConvertFrom-CIPolicy).
A ring strategy: you will not pilot this on the executive floor, whatever anyone tells you.
Two engines, two philosophies
What AppLocker does well
AppLocker answers "who can run what, from where": rule collections for EXE/DLL, Windows Installer, scripts, and packaged apps, each supporting path, hash, and publisher rules. Its strengths are operational familiarity — GPO deployment works in hybrid estates — and granularity: you can allow C:\Program Files\Contoso\* for one AD group and deny it for another in the same afternoon. Its structural weakness is that it's a user-mode control with path-based roots: well-known writable paths, DLL-rule overhead, and a bypass culture documented for a decade.
What App Control adds
App Control authorizes on signer and file attributes, enforced in the kernel at both user and driver level. It's the basis for modern Windows security postures and integrates with concepts AppLocker lacks: managed installers, the Intelligent Security Graph (ISG), signed policies, and multiple concurrent base policies.
Capability
AppLocker
App Control for Business
Enforcement layer
User mode (EXE/DLL/Script/MSI)
Kernel + user mode (drivers and apps)
Rule basis
Path, hash, publisher per collection
Publisher/signer, hash, file attributes, ISG
Windows 11 Pro support
Supported (Enterprise recommended)
Supported on 22H2+
Multiple base policies
No
Yes (Windows 11 22H2+)
Managed installer
No
Yes (Intune Management Extension, ConfigMgr)
Signed policy with boot protection
No
Yes
Deployment
GPO, AppLocker CSP
Intune Settings catalog / AppControl CSP, GPO
Event log
AppLocker (EXE and DLL, MSI and Script, …)
CodeIntegrity Operational
Neither engine replaces the other outright. The pragmatic pattern: App Control as the base trust posture, AppLocker layered for per-group app control the base policy shouldn't encode.
Deploying App Control for Business with Intune
Start from a policy generated from a reference machine with your standard software load, then soften it into audit mode:
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
# Build the initial policy from a golden reference drive
New-Cipolicy -FilePath .\fleet-base.xml -ScanPath C:\ `
-UserPEs -Level Publisher -Fallback Hash `
-RulesReferToUserModeApps# Audit mode ON, and bump policy version for later updates
Set-RuleOption -FilePath .\fleet-base.xml -Option3 # Enabled: Audit Mode
Set-CipolicyVersion -FilePath .\fleet-base.xml -Version"1.0.0.0"
Set-CipolicyIdInfo -FilePath .\fleet-base.xml -PolicyName"Fleet Base v1"# Compile to binary for deployment
ConvertFrom-Cipolicy -XmlFilePath .\fleet-base.xml -BinaryFilePath .\fleet-base.bin
Deployment paths, in order of preference:
Intune Settings catalog — App Control for Business profile using the built-in templates for the OS baseline (the "Default Windows" and "Signed and Reputable" style templates), customized where needed.
Custom policy via the AppControl CSP (OMA-URI) when you need full control of the compiled binary — the path for wizard-built or cmdlet-built policies.
GPO only in co-managed limbo, with a migration date attached.
Signed policies add tamper resistance — a signed policy can't be removed without a policy signed by the same cert — but they raise the stakes for policy errors. Common practice: unsigned audit policies first, signed and enforced after two clean quarters.
Field note: Every policy revision must bump the policy version, or devices silently keep the old one. Half of all "App Control isn't applying" tickets are a recompiled binary with the same version GUID sitting in the deployment.
AppLocker events and where they live
If AppLocker stays in your estate, its events are your tuning loop. Under Applications and Services Logs > Microsoft > Windows > AppLocker:
8002 — EXE allowed. 8003 — EXE would be blocked (audit). 8004 — EXE blocked (enforce).
AppLocker audit mode is per-rule-collection and produces volume; if you enable DLL rules for real, watch performance — they're the classic self-inflicted wound.
Audit-then-enforce: the methodology both engines share
The methodology is identical regardless of engine; only the log sources differ:
Deploy in audit mode to the pilot ring. For App Control, option 3 (audit) blocks nothing; every would-be block logs as event 3076 (event 3077 in enforcement, with 3089 carrying signature details).
Harvest and classify audit events in advanced hunting — this is why MDE Plan 2 earns its license here:
KQL
1
2
3
4
5
6
7
// Would-be blocks by publisher, last 14 days
DeviceEvents
| where Timestamp > ago(14d)
| where ActionType has "AppControlCodeIntegrityPolicy"
| summarize Hits = count(), Devices = dcount(DeviceId)
by ActionType, bin(Timestamp, 1d)
| order by Hits desc
Build exceptions deliberately. Add publisher rules for legitimate unsigned line-of-business apps — ideally after pushing vendors to sign, not by whitelisting hashes that rot on every update.
Flip to enforce per ring, starting with the ring that has the cleanest audit signal (usually VDI or kiosk fleets), never the sales floor with thirty years of unsigned installers.
Keep audit logging on after enforcement. Event 3076 disappears in enforce mode; event 3077 plus MDE alerts become your drift detector.
A 30-day audit window per ring is typical; shorter works on standardized fleets, and longer means your window was actually procrastination.
Visual Walkthrough
Same goal, different engines — pick per fleet reality, not fashion.
Side-by-SideAppLocker vs App Control for Business6/6
AppLocker
legacy engine
App Control for Business
modern WDAC
GPO/Intune via ADMX ingestion
Signed policy, tamper-resistant
Path & hash rules (bypassable paths)
Signer + managed installer trust
No managed-installer concept
ISG / Smart App Control options
Audit + enforce collections
Per-rule audit events 3076/3077
Familiar for GPO-heavy estates
Right choice for Win11 fleets
AppLocker vs App Control for Business. AppLocker vs App Control for Business. AppLocker: GPO/Intune via ADMX ingestion · App Control for Business: Signed policy, tamper-resistant — AppLocker: Path & hash rules (bypassable paths) · App Control for Business: Signer + managed installer trust — AppLocker: No managed-installer concept · App Control for Business: ISG / Smart App Control options — AppLocker: Audit + enforce collections · App Control for Business: Per-rule audit events 3076/3077 — AppLocker: Familiar for GPO-heavy estates · App Control for Business: Right choice for Win11 fleets
Managed installer and supplemental policies
The reason App Control feels viable on a fleet that installs software weekly is managed installer: binaries deposited by a designated deployment mechanism — in Intune's case the Intune Management Extension deploying Win32 apps — are trusted automatically. You enable it as a policy rule option on the base or supplemental policy, and from then on "installed by Intune" means "trusted," which converts the scariest App Control question ("what about the next app deployment?") into a solved problem.
Supplemental policies do the rest: a supplemental policy extends a base policy with additional trust (a new signer, a new app) without touching the base, and multiple base policies on Windows 11 22H2+ let segments with different postures coexist. The anti-pattern to avoid: merging every exception into one ever-growing base policy until it's un-reviewable. Base policy stays boring; supplementals carry the business.
Edition realities: Home, Pro, and Smart App Control
Home: neither AppLocker nor App Control is supported. BYOD Home machines are an App Protection Policy / MAM problem, not an app-control one.
Pro: App Control for Business is supported from Windows 11 22H2 onward; Windows 10 Pro is not. Check your fleet report before committing to App Control-only design.
Smart App Control: the consumer-leaning control on new Windows 11 installs evaluates app reputation in the cloud. It cannot be re-enabled once disabled, and it is not an enterprise management surface — mention it in your docs so helpdesk doesn't confuse it with your policies.
Key takeaways
App Control for Business is the strategic control: signer-based, kernel-enforced, managed-installer aware; AppLocker is the flexible residual tool for per-group path rules.
App Control works on Windows 11 Pro from 22H2; Windows 10 needs Enterprise/Education. Verify editions before you design.
Audit mode (event 3076) plus advanced hunting over AppControlCodeIntegrityPolicy* events is the only scalable way to build the allowlist — never from a spreadsheet.
Bump the policy version on every revision; identical versions silently fail to apply.
Enable managed installer with the Intune Management Extension so Win32 app deployments remain trusted without manual policy edits.
Keep the base policy stable and boring; push exceptions into supplemental policies and use multiple base policies on Windows 11 for segment postures.
AppLocker's event IDs (8002/8003/8004 and friends) remain your tuning loop wherever AppLocker persists; DLL rules carry a real performance cost.
Frequently asked questions
Should we turn AppLocker off once App Control is enforced?
Not necessarily. App Control sets the trust floor for everyone; AppLocker still adds value for per-group restrictions (blocking specific tools for specific populations) that you don't want baked into kernel policy. Keep it lean: AppLocker rules that duplicate the base policy are pure overhead.
Is the Intelligent Security Graph safe to rely on?
ISG authorization trusts files with good cloud reputation. It's reasonable as an audit-mode companion or on fleets with heavy consumer software, but it's not deterministic: a file's reputation can change, and offline behavior degrades. Production posture: publisher rules and managed installer as the spine, ISG as a supplement you monitor.
How do we handle unsigned internal line-of-business apps?
Push vendors to Authenticode-sign — that's the durable fix. Interim: publisher rules for the internal signing cert, or hash rules for single binaries you control the lifecycle of. Avoid broad path allowlists for network shares; that's the bypass classic AppLocker was criticized for and App Control exists to outgrow.
Comments
0No comments yet — be the first to share your thoughts.