WDAC Deployment Guide: How to Make Windows Application Allowlisting Actually Work

AppLocker has been the dominant Windows application control mechanism for most enterprises since Windows 7 and has served its purpose, but it has fundamental architectural limitations that make it inappropriate as a long-term allowlisting strategy. AppLocker enforcement runs in user mode, meaning that an attacker with local administrator rights can disable AppLocker rules, modify the Application Identity service, or bypass enforcement through well-documented techniques. WDAC enforcement is implemented as a kernel-level code integrity policy. The kernel evaluates every binary attempting to load or execute against the active policy before allowing it to run. An administrator-level process cannot modify an active WDAC policy without rebooting to a trusted recovery environment, and when WDAC is combined with Hypervisor-Protected Code Integrity (HVCI), even a kernel exploit cannot modify the code integrity policy because it is protected inside the virtualization-based security boundary.

Microsoft has explicitly stated that AppLocker will not receive new feature development and that WDAC is the supported path forward. The practical implication for organizations currently running AppLocker is not to panic, but to include WDAC migration in the 2026-2027 planning cycle. Running both simultaneously is possible and supported: AppLocker handles user-mode script control in some configurations while WDAC handles kernel and user-mode binary control.

WDAC policies are XML documents that define which code signing certificates, file hashes, file paths, or software publishers are trusted to execute. The policy is converted to a binary format and deployed via MDM (Intune), Group Policy, or direct file copy. Multiple policies can be active simultaneously on Windows 11 and Windows Server 2022 and later, enabling the supplemental policy architecture that makes enterprise exception handling tractable.

The reason most WDAC projects fail is that teams attempt to build a policy from a software inventory spreadsheet, deploy it in block mode, and discover immediately that the spreadsheet did not reflect reality. The audit mode workflow eliminates this problem by deploying WDAC in a state where it logs everything it would block without actually blocking anything. The data collected during the audit period becomes the empirical basis for the policy, not assumptions about what software is installed.

Deploy the Microsoft-recommended default policy in audit mode across a representative sample of your endpoint population. The default policy includes signing rules for Windows components, the Windows Hardware Quality Labs signing certificate, and a set of well-known software publishers. Enable Intune or Group Policy deployment of the policy and set EventLog auditing to write Event ID 3076 (CodeIntegrity operational) entries for everything the policy would block. Run the audit period for a minimum of 30 days, with 60 days preferred for environments with irregular software usage cycles (month-end finance applications, quarterly reporting tools, annual audit software).

At the end of the audit period, collect Event ID 3076 entries from all endpoints using your log aggregation platform. Each 3076 event contains the file path, the file hash, the signing certificate (if present), and the process that attempted to load the binary. The aggregate dataset tells you exactly what the policy would block if you switched to enforcement mode. Process this data to identify: unsigned binaries that need to either be replaced with signed versions or added as explicit hash rules, software signed by publishers not already in the default policy that need a new signer rule, and scripts and interpreted code that require script enforcement configuration.

Building a WDAC policy from scratch by listing every permitted binary as a file hash is a maintenance nightmare that does not scale. The correct starting point is a base policy built on code signing certificate rules rather than hash rules. The Windows-recommended signing rules cover the Windows operating system components, Microsoft applications, and WHQL-signed hardware drivers. This base covers the vast majority of software on a typical enterprise endpoint without requiring any custom rules.

The Allow Microsoft mode default policy is the most restrictive Microsoft-provided starting point: it only allows binaries signed by Microsoft. This is appropriate for fully-managed endpoints where all software is Microsoft-sourced, but breaks every third-party application immediately. The DefaultWindows mode policy is more permissive, allowing Microsoft software plus Windows components. For most enterprises, the practical starting point is the DefaultWindows policy combined with signer rules for your specific third-party software publishers.

Signer rules are more maintainable than hash rules because they cover all current and future versions of software from a trusted publisher without requiring a policy update for each version upgrade. When Adobe ships a new version of Acrobat, a signer rule for the Adobe Inc. code signing certificate automatically covers it. A hash rule for Acrobat 2025 does not cover Acrobat 2026 and requires a policy update for every version change. The practical guidance is to use signer rules wherever possible, path rules only for internal unsigned software from trusted locations, and hash rules only as a last resort for software that cannot be signed.

The managed installer tag is one of the most important WDAC features for enterprise deployability and one of the least understood. A managed installer is a process designated in the WDAC policy as trusted to install software. Any binary installed by the managed installer process receives a trust tag at the file system level using extended attributes, and WDAC trusts tagged binaries to execute without requiring an explicit signer or hash rule.

For most enterprises, the managed installer configuration consists of two entries: the Microsoft Endpoint Configuration Manager (SCCM/MECM) client process and the Intune Management Extension process. Once these are designated as managed installers, every application deployed through your standard software deployment tooling will be automatically trusted by WDAC. This means that your software deployment process, which presumably already requires change management approval, becomes the trust mechanism for application execution as well.

The security implication of managed installer trust is important to understand: managed installer trust is inherited, meaning a process installed by the managed installer can itself install other processes that also inherit trust. This is intentional behavior that supports complex installer chains, but it also means that an attacker who compromises the SCCM client or Intune agent can use them to deploy trusted malware. The managed installer configuration should always be paired with strong controls on who can create SCCM deployments and Intune packages, and with monitoring for unexpected package deployments. Managed installer trust does not replace code signing; it augments it for the specific scenario of enterprise software deployment.

WDAC's supplemental policy architecture is the feature that makes enterprise exception management tractable at scale. A supplemental policy is a WDAC policy that extends a base policy by adding additional allow rules without modifying the base policy itself. This architecture enables a clean separation between the base policy (which represents your standard security posture and requires change control to modify) and supplemental policies (which represent scoped exceptions for specific departments, applications, or use cases).

A practical example: your base WDAC policy covers the standard enterprise software stack. The research and development department needs to run Python scripts, Jupyter notebooks, and custom tools that are not in the standard stack. Rather than adding development tool exceptions to the base policy for all endpoints, you create an RD-Supplemental policy that allows these tools and deploy it only to RD department devices using an Intune device group assignment. The finance department needs a legacy payroll application that is unsigned and cannot be updated. You create a Finance-Payroll-Supplemental policy with a hash rule for the specific payroll application binary and deploy it only to the machines running payroll.

Supplemental policies are themselves enforced by WDAC, meaning they are compiled to the binary format and deployed through the same mechanism as the base policy. They are not a bypass mechanism; they are a scoped extension mechanism. The security team maintains control over what supplemental policies exist and what they contain. The exception request workflow becomes: business unit submits a request identifying the application and business justification, security team creates a targeted supplemental policy for the minimum set of allowed binaries, the supplemental policy is deployed only to the endpoints that need it.

PowerShell, VBScript, Windows Script Host, and other interpreted scripting environments are the most frequent cause of WDAC rollbacks in enterprise deployments. When WDAC script enforcement is enabled, these environments enforce the active policy for script files as well as binaries. A PowerShell script that is not signed by a trusted publisher will fail to execute in FullLanguage mode and drop into Constrained Language Mode or block entirely, depending on the policy configuration.

The three common scenarios that cause immediate script-related rollbacks: administrative scripts in SYSVOL or NETLOGON that are unsigned and have been running for years, software installation scripts embedded in MSI packages that call external unsigned PowerShell modules, and monitoring agent scripts (backup agents, endpoint agents, SIEM collectors) that run as scheduled tasks using unsigned PowerShell.

The practical approach to script enforcement is to deploy it separately from binary enforcement and use a longer audit period specifically for script execution events. Collect Event ID 3076 specifically from PowerShell, wscript, and cscript processes during the extended audit period. The output tells you which scripts need to be either signed using your internal CA or replaced with signed alternatives from vendors. Microsoft has made script signing straightforward in the enterprise context: PowerShell supports catalog signing, and most modern management platforms ship with signed scripts. The unsigned script problem is typically concentrated in legacy automation that predates modern signing practices and needs to be inventoried and addressed explicitly.

The rollout sequence that produces the fewest incidents is: baseline assessment, pilot enforcement on IT department devices, department-by-department expansion in enforce mode, and finally the remaining endpoint population. The IT department pilot is not an afterthought. IT staff have the technical skills to investigate and report a WDAC block event accurately, they have access to the administrative consoles to pull Event ID 3077 details quickly, and they have the organizational credibility to communicate that a block event is a WDAC policy issue rather than a system malfunction. Running enforce mode on IT devices for two weeks before any other department ensures that common IT tools like diagnostic utilities, scripting environments, and remote administration tools are correctly handled in the policy before they become user-facing incidents.

For each subsequent department, the sequence is: announce the deployment date two weeks in advance (this is not optional; it gives department managers an opportunity to surface software the security team does not know about), deploy audit mode for one week, review the audit period Event ID 3076 data for that department specifically, create any necessary supplemental policies, then switch to enforce mode. This per-department audit window adds time to the rollout but eliminates the rollback risk that comes from deploying block mode based only on the initial 30-day fleet-wide audit.

The exception workflow for production block events should be documented before the first enforce mode deployment. The workflow is: user receives a block notification (configure a custom notification message with a help desk ticket URL), help desk collects Event ID 3077 details and opens a ticket, security team reviews the blocked binary and determines whether it is a legitimate application (supplement policy needed), a violation of software deployment policy (user education needed), or a genuine threat (incident response activated). The response time target for legitimate application blocks should be four hours during business hours. A longer response time trains users to avoid blocking by taking other paths around the control.

Even a well-designed WDAC deployment will generate production block events for legitimate software during the first 90 days in enforce mode. The exception workflow determines whether the deployment succeeds or gets rolled back, because rollback decisions are usually made by business leadership responding to frustrated users, not by the security team reviewing evidence.

The pre-emptive communication strategy matters as much as the technical workflow. Before going into enforce mode for any department, send communication that explains what WDAC is, what a block event looks like, and exactly how to report it. The message should include a direct link to a help desk ticket form with pre-filled fields for the required diagnostic information (computer name, username, timestamp, application name). Make the reporting process take less than 60 seconds. Friction in the reporting process causes users to find workarounds rather than report blocks, which means the security team does not learn about policy gaps until a manager escalates.

For the security team review of exception requests: the decision tree is binary. Either the software is legitimate and needs a rule, or it is not legitimate and should not run. For legitimate software, create the most restrictive rule possible: prefer a signer rule for software from a known publisher, a hash rule for a specific binary version if no signing certificate exists, and a path rule only for internal unsigned tools deployed to a known controlled location. Document each exception rule with the requestor, the business justification, and a review date. Build a quarterly exception review into the WDAC operations calendar to identify rules that are no longer needed or that can be replaced with more restrictive alternatives.