WDAC / Windows App Control via Intune: Audit First, Then Enforce · CloudEngineerHub
WDAC13 min read5 views
WDAC / Windows App Control via Intune: Audit First, Then Enforce
A production-grade WDAC rollout: author with the Policy Wizard or ConfigCI cmdlets, deploy the policy binary through Intune, read 3076 audit events, then flip to enforcement safely.
C
CloudEngineerHub Team
Published: August 26, 2026· Last Updated: September 24, 2026·13 min read
WDAC / Windows App Control via Intune: Audit First, Then Enforce
Application allowlisting used to be enterprise kryptonite — powerful, brittle, and hated. Modern Windows App Control (WDAC), deployed through Intune and staged audit-mode-first, is finally practical. The difference between a clean rollout and a bricked pilot fleet is almost always the sequence: build in audit, gather evidence, then enforce. Skip the audit window and you will meet every legacy LOB installer in your company at once.
Visual Walkthrough
The staged path from invisible logging to fleet-wide app control.
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.
One enforcement ring; managed installer trusts deployed apps.
phase 5
5
Fleet enforcement
Block mode everywhere; audit events still feed tuning.
WDAC — Audit First, Enforce Forever. 1. Base policy in audit: Policy deployed with Enabled:Audit — nothing blocks yet. — 2. Collect 3076/3077 events: AppControl operational log gathers would-block evidence. — 3. Refine with publisher rules: Signer-based rules replace fragile path allow-lists. — 4. Pilot enforcement: One enforcement ring; managed installer trusts deployed apps. — 5. Fleet enforcement: Block mode everywhere; audit events still feed tuning.
Prerequisites
OS: Windows 10 1903+ / Windows 11 for multi-policy format; verify edition support (App Control is built into Windows, no agent).
Intune: the Windows App Control configuration template (Devices → Configuration → Windows → Templates); devices must be enrolled and checking in.
Authoring tools: the WDAC Policy Wizard or the ConfigCI cmdlets built into Windows (New-CIPolicy, ConvertFrom-CIPolicy).
Defender for Endpoint (recommended): Advanced Hunting aggregates App Control events tenant-wide — the difference between sampling events on one laptop and seeing the whole fleet.
A pilot ring you can reboot on demand; every policy change requires a reboot to activate.
How It Works: The Code Integrity Model
App Control is enforced by Windows code integrity: on every process launch and driver load, the kernel validates the binary against your policy — signature chains, file hashes, or explicit path/file rules — before execution. Audit mode validates and logs what would be blocked (event 3076); enforcement mode actually blocks (event 3077). Both land in Microsoft-Windows-CodeIntegrity/Operational. Policies are XML authored from a reference machine, converted to a binary format MDM can deploy, and merged on the device when multiple policies apply — which is why the multi-policy model (a stable base policy plus fast-moving supplemental policies) is the maintenance strategy, not an option. If you run EPM, the managed installer supplemental policy lets binaries installed by EPM-elevated processes pass validation automatically, closing the "apps can't install" objection before it is raised.
Build the Policy Right
Author with the WDAC Policy Wizard or the ConfigCI cmdlets. Start from a template — Microsoft recommended block rules, Microsoft-signed-only, or the Intelligent Security Graph (dynamic code security) for heuristic trust of reputable apps. Match the rule level to reality — Publisher for centrally signed ISV software, FilePublisher or Hash for in-house tools — and remember user-mode and kernel-mode rules are authored in the same policy file.
PowerShell
1
2
3
4
5
# From a reference machine: audit-mode base policy from an app scan
New-CIPolicy -ScanPath C:\ -UserPEs -Level Publisher -FilePath .\Contoso-Base.xml -Audit# Convert to the binary format MDM consumes
ConvertFrom-CIPolicy -XmlFilePath .\Contoso-Base.xml -BinaryFilePath .\Contoso-Base.bin
# Expected output: Contoso-Base.xml (editable source of truth) + Contoso-Base.bin (deployable artifact)
Keep the XML in source control with review discipline — it is your policy source code. The binary is disposable; regenerate it from the XML after every change.
Deploy via Intune and Read the Signal
Intune path: Devices → Configuration → Create policy → Windows → Templates → Windows App Control. Upload the converted policy binary, assign to a pilot ring, and remember that every new or updated policy requires a reboot to activate — schedule it, or your pilot results will quietly compare pre- and post-reboot states. Multiple policies can target one device; they merge with policy priority ordering, which is exactly why supplemental policies — not base-policy edits — are the maintenance path.
Stay in audit mode for two to four weeks. Would-be blocks log as 3076, enforced blocks as 3077:
PowerShell
1
2
3
4
Get-WinEvent -LogName'Microsoft-Windows-CodeIntegrity/Operational' -MaxEvents500 |
Where-Object { $_.Id -in3076,3077 } |
Group-Object Id | Select-Object Name, Count
# Expected output: counts per event ID — 3076 growth during audit is expected, 3077 growth after enforcement is a red flag
Confirm which policies are actually active on a device — the local authority is Citool.exe:
PowerShell
1
2
3
# List active App Control policies on the device
Citool.exe -lp# Expected output: one entry per policy — Policy ID, friendly name, and enforcement/authorization state flags
If devices are onboarded to Defender for Endpoint, Advanced Hunting aggregates the same signal tenant-wide:
KUSTO
1
2
3
4
DeviceEvents
| where ActionType in ("AppControlCodeIntegrityPolicyAudited","AppControlCodeIntegrityPolicyBlocked")
| summarize Hits = count() by FileName, ActionType
| order by Hits desc
Whitelist exactly what the audit data justifies — supplemental policies are cheap. Then flip the base policy to enforcement and watch 3077: the only acceptable remaining source is malware.
Configuration Deep Dive: Rule Levels and Policy Options
Three choices define a policy's stability. Rule level: Publisher trusts a signing chain and survives updates; FilePublisher pins publisher + filename + minimum version; Hash pins an exact binary — best for in-house tools, worst for anything that patches. Options: Enabled: Audit Mode during rollout, Enabled: UMCI for user-mode control (kernel-mode is always enforced by default), and consider Enabled: Script Enforcement to constrain PowerShell — with the understanding that unsigned internal scripts will surface immediately in your audit data. Trust anchors: the Intelligent Security Graph (dynamic code security) reduces policy churn for reputable but constantly-updated apps, at the cost of heuristic trust — decide deliberately whether your risk profile accepts it. Whatever you choose, document why per rule; future admins inherit exceptions they did not create.
Real-World Enterprise Scenario: 3,100 Engineering and Finance Workstations
A logistics firm piloted App Control on 150 finance machines: two weeks of audit produced 41 unique 3076 sources, resolved into one supplemental policy (9 publisher rules, 3 hashes) plus managed installer from their existing EPM deployment. Enforcement flipped after a clean week of zero legitimate 3077s. Engineering workstations followed with a separate supplemental policy for build tooling. The firm's scorecard: a malware dropper blocked in month three (3077 + Defender alert, zero spread), and a supplemental-policy request process with a 2-business-day SLA that kept developers from routing around the program.
Troubleshooting
Symptom
Likely cause
Fix
Legitimate app blocked after enforcement
App absent from policy; audit window missed it
Confirm via 3077 details, add a supplemental rule, redeploy supplemental policy
Policy changes "not applying"
Reboot not yet performed
Code integrity loads policies at boot — schedule and verify the reboot
Citool.exe -lp shows no policy
Deployment failed or wrong binary format
Confirm the .bin was uploaded (not the XML) and the profile assigned
PowerShell scripts blocked unexpectedly
Script enforcement option enabled
Sign internal scripts or scope script enforcement deliberately
Audit events missing entirely
Wrong log queried or event-log service policy
Query the CodeIntegrity/Operational log; verify audit logging isn't disabled by another policy
Common Errors
Deploying the XML instead of the .bin — Intune needs the binary; keep the XML in source control and convert on release.
Editing the base policy for every exception — churn, risk, and reboots for everyone; supplemental policies exist for this.
Flipping to enforcement before reading audit data — you enforce guesses; the 3076 backlog is the requirements document.
Forgetting the reboot in pilot comms — users interpret a pending reboot as "the policy broke my laptop".
Visual Walkthrough
The policy engine's four questions, answered in order at execution.
Decision TreeApp Control Evaluation — Why Did It Run (or Not)?5/5
Decision gate
Binary requests execution
Every launch is a policy question with a binary answer.
Explicitly trusted
1
Signed by trusted signer
Publisher rule match (EKU + signer) allows the binary.
2
Managed installer authored
File deployed by Intune/SCCM → ISG trust applies.
3
Execution allowed
Process runs; event 3076/3077 logs audit vs enforce.
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
Best Practices
Audit two to four weeks per ring; treat the 3076 dataset as requirements gathering, not noise.
Multi-policy forever: stable base, supplemental per business unit, managed installer when EPM exists.
Keep the XML in Git with code review; regenerate binaries on release.
Wire 3076/3077 (or the Advanced Hunting equivalents) into your SOC's alerting after enforcement.
Keep the supplemental pipeline warm — a frozen policy becomes shadow IT's favorite reason to ask for exceptions.
Security Considerations
App Control is the single most effective control against unsigned malware execution on Windows — a blocked dropper never executes, so EDR has nothing to chase. Balance that with usability: the Intelligent Security Graph reduces churn but adds heuristic trust; managed installer ties execution trust to your EPM-governed install path. Sign internal scripts and tools, keep block-rule templates (Microsoft recommended block list) refreshed, and remember audit mode is itself a signal — attackers probe in audit-mode tenants that never enforce.
FAQ
Is WDAC the same as App Control for Business?
Yes — Microsoft renamed Windows Defender Application Control to Windows App Control / App Control for Business; the technology and event model are unchanged.
Does Intune deploy the policy XML directly?
No — convert the XML to binary with ConvertFrom-CIPolicy and upload the .bin through the Windows App Control template.
Can I run audit and enforce side by side?
Per policy, one mode at a time — but you can deploy an enforcing base to stable rings and an audit-mode copy to the next ring in parallel.
How do multiple policies merge?
They merge additively with priority ordering — anything any policy allows is allowed, which is why unmanaged supplemental policies erode the model.
What if an LOB app has no publisher signature?
Use FilePublisher or hash rules in a supplemental policy, and press the vendor for signing — hash-only estates age badly.
Conclusion
Audit-first turns allowlisting from folklore into data engineering: build from templates, deploy the binary through the App Control template, read 3076 for a month, codify with supplemental policies, then enforce and keep the pipeline alive. Rehearse the full pipeline in a lab, prove your knowledge with /mock practice tests, automate event triage with /tools, and find hardened Windows bundles in the /store.
Use App Control with Intune: learn.microsoft.com/mem/intune/protect/app-control-for-business-with-intune
App Control event IDs: learn.microsoft.com/windows/security/application-security/application-control/app-control-for-business/operations/event-id-explanations
Comments
0No comments yet — be the first to share your thoughts.