App Control for Business (WDAC): Plan, Audit and Enforce Application Control on Windows

Most Windows estates still let any binary a user downloads run, and App Control for Business is the built-in feature that can stop that, but only if the policy is designed, tested and owned properly. App Control for Business is the current Microsoft name for what most teams still call Windows Defender Application Control (WDAC), and it was originally released as configurable code integrity, which is why its policies are still called code integrity (CI) policies. This guide is the deployment companion to our general allowlisting guidance: it covers policy rule options, file rule levels, base and supplemental policies, managed installer, the Intelligent Security Graph (ISG), Intune deployment, the event IDs to monitor and how to roll back safely. It is written for Windows endpoint engineers and Intune administrators. See the Application Allowlisting Guide for the wider comparison of approaches and platforms.

Key takeaways

• App Control is the security boundary, AppLocker is the tuning layer. Microsoft services App Control as a security feature and AppLocker only receives security fixes, so enforce App Control as tightly as you can and use AppLocker only for per-user or per-group rules on shared devices.
• Audit mode is option 3, and enforcement means deleting it. Every policy starts in audit, logs event 3076 for what it would block, and only becomes enforcing when Enabled:Audit Mode is removed and the policy is redeployed.
• Managed installer and ISG are heuristics. They tag files with an origin claim extended attribute and are convenient, but Microsoft is clear that they do not give the guarantees of explicit signer or hash rules, and neither authorises kernel drivers.
• Use the multiple policy format. From Windows 10 1903 a locked base policy plus small supplemental policies per application or team keeps change control manageable; base policies intersect, base plus supplemental policies combine.
• Plan the rollback before the first enforced ring. Deleting a policy in Intune leaves it enforced until reboot; the safe exit is deploying an allow all policy first, and a bad driver rule can stop a device booting.

How App Control decides what runs

App Control evaluates every executable, DLL, driver and, when user mode code integrity is on, script against the active policies. A file runs only if it passes every active base policy (each base policy together with its supplemental policies). Explicit deny rules win over allow rules and over reputation. Only when no explicit rule matches does App Control consult the managed installer origin claim and then, if enabled, the ISG reputation lookup.

• Kernel and user mode: by default a policy restricts only kernel mode binaries; option 0 (Enabled:UMCI) extends it to user mode executables and scripts.
• Scripts: with UMCI, script hosts such as PowerShell, wscript, cscript and mshta ask App Control about each script. In enforcement, PowerShell runs scripts that fail the policy in Constrained Language Mode rather than refusing them outright, and the event log records 8029.
• Signing: policies are unsigned by default (option 6). A signed policy cannot be removed by a local administrator without the signing key, which is the strongest tamper protection but also the hardest to recover from if the policy is wrong.

Policy rule options that matter

Options are set with Set-RuleOption -FilePath policy.xml -Option <n> and removed with the -Delete switch.

Choosing file rule levels

The rule level decides how specific each allow rule is. Policies are usually created with a primary level and fallbacks, for example -Level FilePublisher -Fallback SignedVersion,Publisher,Hash, so signed files get publisher rules and unsigned files fall back to hashes.

• RootCertificate is not supported: and signer rules need RSA signatures (up to 4096 bit keys). ECDSA signed files fail signer rules with VerificationError 23, so they need hash rules.
• Path rules and permissions: at runtime App Control checks that only well-known administrator SIDs can write to an allowed path. A write permission for any other SID, even a custom admin group, makes the path user writable and the rule does not apply. Configuration Manager file and folder rules are a one-time scan snapshot, not FilePath rules.
• Wildcards: * works in path rules on Windows 10, Windows 11 and Windows Server 2022 and later; ? and wildcards in any position need Windows 11 or Windows Server 2025. Macros %OSDRIVE%, %WINDIR% and %SYSTEM32% can be combined with them.

Base policies, supplemental policies and templates

Start from a Microsoft example policy rather than a blank file. The examples live in %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\ and are provided as-is, so test them.

• How multiple policies combine: with several base policies, a file must be allowed by every one of them. A supplemental policy extends one base policy, and a file allowed by either runs. Use one locked base per device class and supplemental policies for line-of-business applications and team-specific tools.
• Creating a supplemental: generate it with New-CIPolicy -MultiplePolicyFormat, then link it with Set-CIPolicyIdInfo -SupplementsBasePolicyID <base GUID>. The base needs option 17, and for signed bases the supplemental signers must be defined with Add-SignerRule -Supplemental.
• Policy count: devices with the Windows security update of 9 April 2024 or later have no limit on active policies. Without it, and on Windows 11 21H2 even with it, the limit is 32.
• Merging the block rules: the recommended block list includes two allow all rules (ID_ALLOW_A_1 and ID_ALLOW_A_2). Before merging it into an allowlist with Merge-CIPolicy, remove them and their FileRuleRefs, or the merged policy allows everything.

Managed installer and the Intelligent Security Graph

Both features reduce the number of rules you write by trusting how a file arrived rather than what it is. Both mark authorised files with a kernel-managed extended attribute, $KERNEL.SMARTLOCKER.ORIGINCLAIM, which Windows honours only on the operating system volume, because other volumes can be modified offline.

• Trust propagation ends: when the original installer exits or a process crosses a security boundary. Installers that launch the app at the end of setup extend trust to whatever the app writes on first run, so disable auto-launch in deployment packages.
• No retroactive tagging: Intune's managed installer does not tag applications that were installed before it was enabled. Those need explicit rules, which is why Microsoft recommends audit mode first on existing devices.
• Business critical and boot critical code: Microsoft advises static rules (signer, file attribute or hash) for these, not reputation or managed installer trust.

Deploying with Intune

Intune offers two routes. Endpoint security, App Control for Business, with Built-in controls enables trust of Windows components and Store apps, and optionally Trust apps with a good reputation (ISG) and Trust apps from managed installers, in audit only or enforced mode. Enter xml data, or a custom OMA-URI profile, carries your own policy.

• Managed installer tenant setting: Endpoint security, App Control for Business, Managed installer tab, with Enable Intune Managed Extension as Managed Installer. It takes up to 10 minutes to appear in the tenant and up to 30 minutes to reach devices. Enabling it once needs the Intune Administrator role; day-to-day policy work needs only the App Control for Business permission.
• Prerequisites: Windows Enterprise or Education on Windows 10 1903 or later or Windows 11; Windows Pro with specific updates (KB5019959 for Windows 10, KB5019980 for Windows 11 22H2, KB5019961 for 21H2). Co-managed devices need the Endpoint Protection workload slider set to Intune.
• Custom OMA-URI: ./Vendor/MSFT/ApplicationControl/Policies/<PolicyGUID>/Policy, data type Base64 (file), GUID without braces, the .cip renamed to .bin, and a 350,000 byte size limit. Devices before Windows 10 1903 use the older AppLocker CSP path and a reboot.
• AppLocker side effect: enabling the managed installer deploys an AppLocker policy with a dummy rule. If a device already has an AppLocker rule collection set to NotConfigured with no rules, the merge can enforce it, blocking apps and even sign-in. Find and remove those empty collections first.

The Intune tenant becomes part of your execution control plane: whoever can edit these policies can allow or block code on every device. The Stryker Intune wiper attack showed what a single compromised administrator can do through the same console, so protect App Control permissions with the same rigour as device wipe rights.

How to implement: audit, pilot, enforce

1. Inventory and classify devices: group by role (standard workstation, developer, admin workstation, kiosk, server). Fixed function devices and admin workstations are the easiest and highest value first targets.
2. Remove local admin rights first: managed installer and unsigned policies both assume standard users. Pair with the LAPS Guide so the built-in administrator password is unique and rotated.
3. Build the base: start from DefaultWindows or AllowMicrosoft, add options 0, 3, 10, 16, 17 and 20, merge the recommended user mode block list (allow all rules removed), and decide whether managed installer (13) and ISG (14 with 15) are acceptable for that device class.
4. Audit on a pilot ring: deploy in audit mode to 20 to 50 representative devices for at least one full business cycle, including month-end and patch day. Collect 3076 and 8028 events centrally.
5. Write supplemental policies: convert audit findings into FilePublisher rules where files are signed and hash rules where they are not. Give every supplemental an owner, a ticket reference and a review date in its policy name.
6. Enforce in rings: delete option 3 for the pilot ring, keep option 10 as a safety net, then widen to further rings at fixed dates. Keep at least one audit mode policy deployed to the next ring so new software shows up before enforcement reaches it.
7. Add the driver block list: enable memory integrity where hardware allows (the vulnerable driver block list is then enforced, and is on by default since the Windows 11 2022 update); otherwise merge RecommendedDriverBlock_Enforced.xml into the base after an audit pass. Enable the attack surface reduction rule Block abuse of exploited vulnerable signed drivers as well.
8. Sign policies for high value devices: once rules are stable, remove option 6 and sign the base so a local administrator cannot simply delete it. Keep the signing key in an HSM with dual control.

Rollback: deleting a policy in Intune removes it, but enforcement continues until the next reboot. The documented safe sequence is to deploy a replacement allow all policy (AllowAll.xml), confirm it is applied, then delete it. Unenrolling a device from MDM removes every App Control policy that is not actively deployed, so follow Microsoft's boot stop failure guidance before unenrolling or removing policies at scale.

Choosing the right design

• Small organisation, Intune only, little packaging discipline: Intune built-in controls with Windows components, Store apps and ISG in audit, then enforce.
• Mature software distribution: DefaultWindows base, managed installer on, ISG off, supplemental policies per application family. This gives the tightest result with the least rule writing.
• Developer workstations: separate base with path rules for admin writable tool folders only, msbuild allowed where they genuinely build managed code (Microsoft's block list advises blocking it otherwise), and option 19 tested separately.
• Servers: signer and hash rules only, no ISG (servers often lack internet access), no DenyAllAudit on Windows Server 2019 or earlier.
• Shared devices needing different rules per group: enforce App Control for the device, then layer AppLocker for the user or group differences, which is the combination Microsoft recommends.

Detection and measurement

In Microsoft Defender for Endpoint advanced hunting the origin events appear as AppControlCodeIntegrityOriginAllowed, AppControlCodeIntegrityOriginAudited and AppControlCodeIntegrityOriginBlocked. Collect these channels with the method in the Windows Event Forwarding Guide, and set a data cap, because Microsoft warns that 3091 and AppLocker events can sharply increase Log Analytics cost.

• Enforcement coverage: percentage of devices with an enforced (not audit) base policy, by device class.
• Policy drift: devices whose 3099 events do not show the expected set of policy IDs.
• Heuristic reliance: share of allowed executions coming from 3090 origin events rather than explicit rules.
• Exception hygiene: number of supplemental policies or hash rules with no owner or past their review date.
• Block quality: enforced blocks (3077) per 1,000 devices per week, split into malicious, unwanted and false positive.

Where identity fits

App Control is an identity decision about code: a publisher rule trusts whoever holds the signing key. In the NVIDIA code-signing certificate theft, expired certificates were used to sign malware that Windows still accepted, and Microsoft's guidance was to use application control policies to block it. That is why option 20 and narrow FilePublisher rules matter, and why your own policy signing key is a privileged machine credential. The identities that can change policy also matter: Intune roles with App Control permission, the Configuration Manager service, and any local administrator on devices with unsigned policies. See the Machine Identity PKI Certificate Lifecycle Guide for signing key custody.

Common failure patterns

• Leaving option 3 in place for good. Teams deploy audit mode, see the event volume and never schedule enforcement. Set enforcement dates per ring at the start.
• Merging the block list with its allow all rules. The merged policy silently allows everything. Check the merged XML for ID_ALLOW_A_1 and ID_ALLOW_A_2 before deploying.
• Deleting a policy to fix an outage. Enforcement persists until reboot, and a broken driver rule can prevent boot. Deploy AllowAll first and keep option 10 on early rings.
• Relying on managed installer while users are local admins. Microsoft states admins can bypass managed installer intent. Remove admin rights before relying on it.
• Empty AppLocker collections on the estate. Enabling Intune's managed installer can enforce an empty NotConfigured collection and block sign-in. Audit existing AppLocker state first.

Framework mapping

Practitioner checklist

• Remove local administrator rights from the devices in scope before relying on managed installer or unsigned policies.
• Start from DefaultWindows or AllowMicrosoft with options 0, 3, 10, 16, 17 and 20 set.
• Merge the Microsoft recommended user mode block rules with the allow all rules removed.
• Decide per device class whether managed installer and ISG are acceptable, and document the decision.
• Audit a pilot ring through a full business cycle and collect 3076, 3089 and 8028 centrally.
• Give every supplemental policy an owner, ticket reference and review date.
• Enforce by ring on fixed dates, with an AllowAll rollback policy tested in advance.
• Enable memory integrity or deploy the vulnerable driver block list, plus the matching ASR rule.
• Restrict who holds Intune App Control permissions and sign base policies on high value devices.

Standards and references

• Microsoft Learn: Understand App Control for Business policy rules and file rules
• Microsoft Learn: App Control and AppLocker overview
• Microsoft Learn: Allow apps deployed with an App Control managed installer
• Microsoft Learn: Authorise reputable apps with the Intelligent Security Graph
• Microsoft Learn: Deploy App Control policies using Microsoft Intune
• Microsoft Learn: Manage approved apps for Windows devices with App Control for Business policy in Intune
• Microsoft Learn: Understanding App Control event IDs
• Microsoft Learn: Applications that can bypass App Control and how to block them

Related NHI Mgmt Group resources: Application Allowlisting Guide · Endpoint Security Guide · Local Administrator Password Solution (LAPS) Guide · Windows Event Log Guide