How to Configure Windows Defender Application Control (WDAC)
A complete walkthrough building an allow-list policy that only permits explicitly trusted applications to run — a meaningfully stronger control than antivirus scanning alone.
Windows Defender Application Control (WDAC) enforces an allow-list model — only applications explicitly permitted by policy can run at all — a fundamentally different security posture than antivirus, which tries to block known-bad software rather than only permit known-good software.
Step 1: understand the model shift before building a policy
Antivirus/EDR tools operate on a deny-list: everything runs by default except what’s specifically flagged as malicious. WDAC inverts this: nothing runs except what’s specifically allowed — a much stronger guarantee against novel or unknown malware, at the cost of requiring deliberate policy maintenance for legitimate new software.
Step 2: create a policy from a reference (golden) system
New-CIPolicy -Level Publisher -FilePath ".\InitialPolicy.xml" -UserPEs -ScanPath "C:\"Building an initial policy by scanning a known-clean, fully-configured reference machine (with -Level Publisher, trusting code by its digital signature rather than an exact file hash) is the practical starting point rather than hand-authoring rules for every application from scratch.
Step 3: review the generated policy
Get-CIPolicy -FilePath ".\InitialPolicy.xml"Confirm the policy actually covers the applications your users genuinely need — a policy built from an incomplete reference system will block legitimate software the reference machine simply didn’t have installed at scan time.
Step 4: convert the policy to binary format for deployment
ConvertFrom-CIPolicy -XmlFilePath ".\InitialPolicy.xml" -BinaryFilePath ".\InitialPolicy.cip"Step 5: deploy in audit mode first, not enforced
Set-RuleOption -FilePath ".\InitialPolicy.xml" -Option 3Option 3 sets audit mode — the policy logs what would be blocked without actually blocking anything yet. Deploying straight to enforcement without an audit period risks breaking legitimate, unaccounted-for software immediately.
Step 6: review audit logs before enforcing
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" | Where-Object {$_.Id -eq 3076}Event ID 3076 entries show what the policy would have blocked — use these to refine the policy (add legitimate publishers/hashes) before switching to actual enforcement.
Step 7: deploy via Group Policy or Intune
Computer Configuration → Administrative Templates →
System → Device Guard → Deploy Windows Defender
Application ControlPoint the policy setting at the deployed .cip binary file, the same distribution mechanism covered in deploying software via Group Policy.
Step 8: switch to enforced mode once audit results look clean
Set-RuleOption -FilePath ".\InitialPolicy.xml" -Option 3 -DeleteRemoving option 3 (rather than adding it) switches the policy from audit to full enforcement.
Step 9: plan for ongoing policy maintenance
New legitimate software still needs to be added to the policy (by publisher certificate or file hash) before it can run under enforcement — WDAC genuinely requires an ongoing maintenance process, not a one-time setup.
Why the audit-first rollout isn’t optional in practice
Deploying an allow-list policy directly to enforcement, without first validating it against real-world usage via audit mode, risks blocking legitimate business-critical software the moment enforcement takes effect — a considerably more disruptive failure mode than a missed antivirus detection. The audit period is what actually makes WDAC deployable in a real organization rather than a theoretical security improvement nobody can safely turn on.