WDAC: App Control for Business and Allowlisting on Windows

Updated: October 2026

Antivirus decides what looks bad and lets everything else run. Application control flips that: nothing runs unless you said it could. Here's how WDAC, now called App Control for Business, works, how it differs from AppLocker and Smart App Control, and how to roll it out without breaking half the apps on the fleet.

What Is WDAC?

WDAC stands for Windows Defender Application Control. Microsoft now calls it App Control for Business, and the old name still shows up in the wizard, in Intune and in half the forum threads you'll read. It's the same feature.

It changes one default. Normally Windows runs any code unless your antivirus flags it. With an App Control policy, code runs only if the policy allows it. That covers executables, DLLs and drivers, plus scripts, MSI installers and PowerShell, which drops into Constrained Language Mode for anything the policy doesn't trust.

Policies apply to the whole device, not to individual users. It runs on Windows Pro, Enterprise and Education editions. Microsoft is clear that it doesn't replace antivirus software, so you keep both.

WDAC vs AppLocker vs Smart App Control

Windows ships three ways to control what runs. They overlap, so it helps to see them side by side.

Microsoft's own guidance is direct: if you can use App Control, use it over AppLocker. AppLocker still gets security fixes but no new features. It stays useful for one job App Control can't do, which is different rules for different users on a shared PC. You can run both, with App Control as the strict base and AppLocker tightening per-user rules on top.

Smart App Control is App Control with a fixed, cloud-reputation policy. It's the consumer version, and our guide on turning off Smart App Control covers why managed fleets swap it out. The good news is that its policy ships as an example you can start from, so you're not building from nothing.

This r/sysadmin thread from September 2026 is the question every pilot hits: the policy works, but is the upkeep worth it?

The top replies agree it goes quiet eventually. It gets there once you stop chasing every DLL and split the rules into an enforced base policy plus a supplemental policy per line-of-business app.

Base and Supplemental Policies

Since Windows 10 version 1903, a device can run several App Control policies at once. That's what makes the feature manageable.

A base policy sets the rules. If a device has two base policies, a file has to pass both to run. A supplemental policy extends one base policy with extra allow rules, and a file runs if the base or any of its supplementals allows it. The base needs rule option 17, Allow Supplemental Policies, for that to work.

The practical pattern is one strict base policy for every device, then one supplemental per app or per team. When the finance app updates, you edit its supplemental and leave the base alone. The old limit of 32 active policies per device is gone on Windows security updates released on or after April 9, 2024, except on Windows 11 21H2.

The Rule Options and File Rules That Matter

A policy has two parts: rule options, which switch behaviours on, and file rules, which say what you trust.

Five rule options do most of the work. Option 3, Audit Mode, logs what would be blocked without blocking it. Option 13 trusts apps installed by a managed installer, such as the Intune Management Extension. Option 14 trusts files with a good reputation in Microsoft's Intelligent Security Graph. Option 16 applies policy updates without a reboot, and option 17 allows supplemental policies.

File rules decide how specific each allow is. Publisher and FilePublisher rules trust a vendor's signing certificate, so updates keep working without policy changes. Hash rules match one exact file and break on every update. FilePath rules only work for folders that just admins can write to, which is why they fail in AppData.

App Control checks rules in a fixed order. Explicit deny rules come first, then explicit allow rules, then the managed installer tag, and the reputation check comes last. Use publisher rules wherever you can, path rules for admin-only folders, and hashes as the last resort.

Build a Policy With the Wizard

You don't write policy XML by hand. The App Control Policy Wizard, a free Microsoft tool, builds base and supplemental policies, sets rule options and merges policies.

Start from a template rather than an empty policy. Microsoft ships example policies in %windir%\schemas\CodeIntegrity\ExamplePolicies, including the Smart App Control policy. If you start from that one, remove the option Enabled:Conditional Windows Lockdown Policy first, as Microsoft's docs note.

For a reference machine with your standard apps installed, PowerShell can scan and build the policy:

powershell
New-CIPolicy -MultiplePolicyFormat -ScanPath "C:\Program Files" -UserPEs -FilePath .\base.xml -Level FilePublisher -Fallback SignedVersion,Publisher,Hash
Set-RuleOption -FilePath .\base.xml -Option 3   # audit mode
Set-RuleOption -FilePath .\base.xml -Option 17  # allow supplemental policies

More cmdlets like these are in our PowerShell commands guide.

Roll Out in Audit Mode First

Every App Control deployment that goes smoothly starts in audit mode. Nothing gets blocked, and every would-be block gets logged.

The events live in two logs. Executables, DLLs and drivers go to Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational. Scripts and MSI installers go to the AppLocker > MSI and Script log. The IDs to watch:

• 3076: the file would have been blocked if the policy were enforced (audit mode).
• 3077: the file was blocked (enforce mode).
• 3089: the signature details for a blocked file, matched to its 3076 or 3077 by Correlation ActivityID.
• 8028 and 8029: the same audit and enforce pair for scripts and MSIs.

To pull audit hits on one PC:

powershell
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" |
  Where-Object Id -eq 3076 | Select-Object TimeCreated, Message -First 20

At scale, Microsoft points to Advanced Hunting in Defender for Endpoint, which queries these events across the fleet. Collect a couple of weeks of audit data, turn the hits into supplemental rules, then remove option 3 on a pilot ring. You can run the audit policy side by side with the enforced one while you test changes.

This walkthrough shows the Intune side of building an App Control for Business policy and testing it:

Deploy With Intune or Group Policy

In Intune, App Control lives under Endpoint security > App Control for Business. The built-in controls give you three switches: trust Windows components and Store apps, trust apps with a good reputation, and trust apps from managed installers. Each combination maps to a fixed base policy ID, and you add supplemental policies as uploaded XML.

Set the Intune Management Extension as a managed installer early. Apps you deploy through Intune afterwards get tagged as trusted. Tagging isn't retroactive, so anything installed before that needs explicit rules. Our Intune review covers where this fits with the rest of Intune.

Group Policy can deploy App Control too, but only single-policy format policies for Windows Server 2016 and 2019. For multiple policies without Intune, Microsoft points to the ApplicationControl CSP through the MDM Bridge WMI Provider.

Removing a policy has one trap. Deleting it from Intune doesn't lift blocks until the next reboot, and a careless removal can stop a device from booting. Microsoft's fix is to push an allow-all version of the policy first, then delete it.

What Breaks, and How to Fix It

Four things cause most App Control tickets.

Unsigned line-of-business apps have no publisher to trust. Ask the vendor to sign them, or fall back to hash rules and accept updating them with every release.

Self-updating apps come back untagged. The managed installer tag only lands on files written by the installer or a process it started. An app that updates itself through its own updater needs a publisher rule.

Apps that install into AppData fight FilePath rules. App Control ignores path rules for folders standard users can write to, because that's an easy bypass. You can switch that check off with option 18, but you're accepting the risk.

Scripts are the fourth. PowerShell scripts that aren't trusted run in Constrained Language Mode instead of failing outright, so they break in odd ways. Sign your admin scripts, or allow them by publisher.

When Not to Use WDAC

App Control is worth it where apps are managed and users aren't local admins. It's a hard fit in a few cases.

Shared PCs that need different rules per user are an AppLocker job. Fleets where every user installs their own software will drown in audit events. And if nobody owns the policy, it rots: the first blocked update gets "fixed" by switching enforcement off.

Check your fleet before you start. OpenFrame can run the Get-WinEvent check above as a script across a client's devices and collect the 3076 counts in one place, which shows how noisy enforcement would be.

The Short Version

WDAC, now App Control for Business, lets only approved code run. Use it over AppLocker unless you need per-user rules, build one strict base policy plus supplementals, prefer publisher rules, and stay in audit mode until the 3076 events go quiet. If admin rights are the bigger gap on your fleet, read our guide to endpoint privilege management next.