Auditing Windows Defender Application Control: From Audit Mode to Enforced Trust

Windows Defender Application Control (WDAC), now commonly called App Control for Business, changes the endpoint security question from “is this file malicious?” to “is this code explicitly trusted?” That distinction matters. Antivirus must recognize bad behavior; application control blocks everything outside a defined trust boundary, including novel malware, unsigned tools, and renamed utilities. The hard part is not generating a policy. It is proving that the policy covers legitimate work before enforcement turns a security improvement into an outage.

Start with the trust model, not the wizard

A durable WDAC policy usually combines several trust signals. Microsoft-signed Windows components can be trusted by publisher. Managed business software can use publisher or signed catalog rules. Internally developed code should be signed by an organizational certificate. Path rules deserve caution because a writable directory turns “trusted path” into “drop anything here and run it.” Hash rules are precise but operationally expensive because every binary update creates a new hash.

Before deployment, classify endpoints by role. A developer workstation, a kiosk, and a domain controller should not share one broad policy. Build a restrictive base policy for common Windows components, then layer supplemental policies for role-specific applications. This reduces exceptions and makes policy ownership understandable.

Audit mode is a measurement phase

Audit mode allows code to run while recording what enforcement would block. Treat it as production telemetry, not a box to check for one afternoon. Cover monthly patching, software deployment, logon scripts, VPN use, maintenance windows, and rarely used recovery tools. Two weeks may be enough for a stable kiosk; a complex workstation population may need a full business cycle.

Review the Code Integrity operational log for policy decisions:

Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-CodeIntegrity/Operational'
  Id      = 3076,3077,3089
} | Select-Object TimeCreated, Id, Message

Event 3076 identifies code that would have been denied in audit mode. Event 3077 records an actual enforcement block. Event 3089 often supplies signing details that explain why a file failed trust evaluation. Also inspect the AppLocker MSI and Script log when script enforcement is in scope; executable coverage alone leaves PowerShell, installers, and dynamic code as blind spots.

Triage audit events like security findings

Do not convert every observed file into an allow rule. Each event belongs in one of four buckets:

• Expected and trustworthy: add the narrowest maintainable publisher, catalog, or signer rule.
• Expected but poorly controlled: sign the code or move deployment into a managed process instead of trusting a writable path.
• Obsolete: remove the application rather than enlarging the policy.
• Unexpected: investigate provenance, parent process, user, prevalence, and network activity before allowing anything.

An audit event is not automatically a false positive. It may be the first inventory record of shadow software or an attacker’s unsigned utility.

Move to enforcement with a recovery path

Begin with a representative pilot group, not just IT administrators. Confirm that policy deployment, rollback, and emergency access all work before expanding. Keep the last known-good signed policy available through an out-of-band management channel. If policy removal is disabled, understand the documented replacement procedure and test it on disposable hardware.

Use staged rings: lab, security and IT, business pilot, then broad deployment. Define objective promotion gates such as seven days without unexplained 3076 events, successful patching, successful line-of-business workflows, and a tested rollback. During enforcement, alert on 3077 spikes by policy version and application so a bad rollout is distinguishable from active intrusion.

Continuously verify policy health

WDAC is not “set and forget.” Policies drift, certificates expire, supplemental policies accumulate, and emergency exceptions outlive the incident that created them. Audit the deployed policy identifiers, mode, version, signing state, and recent Code Integrity events. Compare those facts with an approved baseline and flag machines that are running audit mode when enforcement is required.

WinSentinel provides all 64 security modules free on one machine, with no reduced feature set, so an administrator can audit local application-control posture alongside signing, script, privilege, and Defender settings. WinSentinel Pro adds organizational fleet orchestration: a central node, agent management, compliance rollups, drift alerts, and visibility into which endpoints stopped enforcing the approved policy. The security control remains local; Pro makes its state governable across 10, 50, or hundreds of machines.

The operational standard

A strong WDAC program can answer five questions at any time: which policy should this machine run, which policy is actually active, what would be blocked, what was blocked, and who approved each exception. Build narrow trust rules, observe a complete operating cycle, investigate instead of blindly allowlisting, deploy through measured rings, and continuously compare reality with policy. That is how audit mode becomes enforced trust without becoming enforced downtime.