# Application Control (WDAC and AppLocker)
Application control is a security strategy that restricts which programs are permitted to execute on an endpoint or server. Rather than attempting to detect and block malicious software after the fact, application control takes the opposite approach: define a list of approved, trusted applications, and block everything else by default. This model is called allowlisting (previously "whitelisting"), and it represents one of the most effective endpoint hardening techniques available to defenders today.
On Windows, two mechanisms implement application control: Windows Defender Application Control (WDAC), the modern kernel-enforced system introduced with Windows 10 and Windows Server 2016, and AppLocker, the older Group Policy-based predecessor. Understanding both, and particularly why WDAC supersedes AppLocker for mature security programs, is essential for any organization pursuing robust endpoint posture management.
Application control falls squarely within CDA's Security Posture and Hygiene (SPH) domain, which governs how organizations build and maintain the configurations and controls that determine the resilience of every endpoint, workload, and system in their environment.
---
The fundamental shift in allowlisting is philosophical: instead of maintaining a list of known-bad software to block (the antivirus model), you maintain a list of known-good software to allow. Everything not on the list is denied. This inversion has a powerful consequence: ransomware, novel malware, and attacker tools are almost never on your approved application list. They get blocked not because anyone identified them as malicious, but because they are simply not approved.
This is why application control can stop zero-day malware that no signature-based tool has ever seen. The malware is new and unknown, but it is also unapproved, and that is sufficient to block it.
WDAC is the modern application control framework for Windows. It operates through Code Integrity (CI) policies, which are XML-defined rulesets that Windows loads during boot and enforces at the kernel level before any user-mode process can run code. Because enforcement happens in the kernel, even a fully compromised administrator account cannot disable WDAC at runtime. The policy must be changed through the proper management channel (Intune, SCCM, or a signed policy update), which itself requires trusted infrastructure access.
WDAC supports two operational modes:
Audit mode logs every binary execution that would have been blocked if the policy were enforced, but allows execution to proceed. Audit mode is the correct starting point for any WDAC deployment. Running in audit mode for two to four weeks against a representative sample of endpoints reveals which legitimate applications, scripts, and libraries would be blocked by the policy. This baseline-building phase is critical: organizations that skip it and go directly to enforce mode frequently break production workflows and generate emergency rollbacks that undermine confidence in the program.
Enforce mode blocks all execution not permitted by the policy. Once the policy is deployed in enforce mode, users attempting to launch an unapproved binary receive an error and the attempt is logged in the Windows Event Log under the Code Integrity event channel (Event IDs 3076 and 3077 for audit; 3033 and 3034 for enforce).
WDAC supports three categories of rules, in decreasing order of security:
Hash-based rules allow a specific file version based on its cryptographic hash (SHA-256). This is the most precise control: only that exact version of that file is permitted. The downside is maintenance overhead. Every time an application updates, its binary hash changes, requiring the policy to be updated before users can run the new version. Hash rules are appropriate for tightly controlled server environments where application updates are planned and infrequent.
Publisher-based rules allow any binary signed by a specific certificate chain. For example, a rule might permit all binaries signed by Microsoft's production code signing certificate, plus binaries signed by your organization's internal signing certificate. Publisher rules scale well: when Microsoft releases a Windows update, the new binaries are still signed by the same certificate and are automatically allowed. Publisher rules are the preferred approach for most enterprise environments. They can be further scoped by product name and minimum version number to restrict which signed applications from a vendor are permitted.
Filepath-based rules allow any binary located in a specified directory path. These are the least secure rule type. An attacker or privileged user who can place a malicious binary into an approved directory (such as C:\Program Files\) can execute it without restriction. Filepath rules are sometimes used as a transitional measure but should not be relied upon as a security control in an enforce-mode policy.
Microsoft offers an optional enhancement to WDAC called the Intelligent Security Graph (ISG). When ISG is enabled, WDAC queries Microsoft's telemetry network in real time and allows binaries that Microsoft's cloud data indicates are widely trusted and reputable, even if they are not explicitly listed in the local policy. ISG expands coverage without requiring administrators to enumerate every legitimate application manually. The tradeoff: ISG introduces a cloud dependency and Microsoft's reputation data, which is not infallible. ISG is a useful supplement, particularly during initial rollouts, but should not replace explicit publisher or hash rules for high-sensitivity endpoints.
AppLocker, available since Windows 7 and Server 2008 R2, provides application control through Group Policy. Rules are configured per-user or per-group and can restrict executables (.exe), Windows Installer packages (.msi, .msx), scripts (.ps1, .vbs, .cmd), packaged apps (MSIX/AppX), and DLLs.
AppLocker supports the same three rule types as WDAC (hash, publisher, filepath) but enforces them through a user-mode service called the Application Identity service (AppIDSvc). This is AppLocker's fundamental vulnerability: a sufficiently privileged attacker who has compromised an endpoint can stop or tamper with this service, disabling AppLocker enforcement entirely. AppLocker is also vulnerable to living-off-the-land (LOLBin) bypasses, where attackers use trusted Windows binaries (such as mshta.exe, wscript.exe, or regsvr32.exe) to execute malicious code through an approved process.
WDAC supersedes AppLocker for any security-focused deployment. Organizations running AppLocker should treat it as a transitional control and plan migration to WDAC. On systems where both are deployed simultaneously, WDAC takes precedence.
---
Application control is consistently ranked among the most impactful endpoint security controls by major cybersecurity frameworks and incident response data. The Australian Signals Directorate's Essential Eight places application control at the top of its mitigation strategies. The CIS Controls include it as a critical safeguard. NIST SP 800-167 is dedicated entirely to application whitelisting guidance.
The reason for this consensus is empirical: most malware, including ransomware delivered via phishing, commodity trojans, and custom attacker tools, relies on executing binary code that organizations would never have approved. Ransomware is not a legitimate business application. If a policy permits only approved executables, ransomware cannot run, regardless of whether any antivirus engine has ever seen it before.
This matters particularly in the context of sophisticated threat actors who use custom tooling specifically to evade signature detection. Application control stops them not by recognizing the tool as malicious, but by recognizing it as unapproved.
For regulated industries, application control supports compliance requirements in frameworks including NIST SP 800-53 (control CM-7: Least Functionality), CIS Controls v8 (Control 2: Inventory and Control of Software Assets), and PCI DSS Requirement 5 (anti-malware), where application control is increasingly accepted as a compensating control.
---
WDAC policies can be deployed through:
C:\Windows\System32\CodeIntegrity\) via GPO file distribution.Windows 10 version 1903 and later support deploying multiple simultaneous WDAC policies. This enables organizations to layer policies: a base policy defining broadly trusted signers, combined with supplemental policies that restrict specific user groups or system roles. A supplemental policy cannot expand permissions beyond what the base policy allows, but it can further restrict them.
WDAC logs enforcement events to two locations:
Microsoft-Windows-CodeIntegrity/Operational (kernel CI events, IDs 3033/3076)Microsoft-Windows-AppLocker/MSI and Script (for AppLocker, if active)A mature WDAC deployment ships these events to a SIEM platform for alerting and trend analysis. A spike in blocked execution events on a single host is an immediate indicator of either a legitimate software change that needs policy update or an active attack attempt.
WDAC supports a "Managed Installer" designation for software deployment tools (typically SCCM or Intune). Binaries installed by the Managed Installer are automatically tagged and allowed, reducing the manual policy update burden when software is deployed through approved channels. This significantly eases ongoing policy maintenance in large environments.
---
Application control is a cornerstone of CDA's Autonomous Posture Command (APC) methodology within the Security Posture and Hygiene domain. APC holds that security posture must be continuously maintained and self-healing, not dependent on human intervention for every configuration decision.
In the APC framework, application control policies are treated as living configuration artifacts. They are version-controlled alongside the rest of the infrastructure codebase. Changes to the approved application list go through a review and approval process before deployment, not after. Audit mode telemetry feeds into automated policy generation pipelines that identify candidate applications for approval based on verified installation through managed software distribution channels.
APC's tagline, "Your posture adapts. Your hygiene never sleeps," reflects precisely the kind of control application control provides: a continuously enforced, automatically maintained boundary that does not rely on a human remembering to block a new threat. The threat was never approved in the first place.
CDA treats WDAC deployment in enforce mode as a baseline requirement for any endpoint handling sensitive data. AppLocker is acceptable in environments where WDAC is not technically feasible (older Windows versions, specific compatibility constraints), but migration to WDAC is prioritized during any endpoint refresh cycle.
The operational challenge that kills most application control programs is not technical. It is the discipline to maintain the policy as software changes. Organizations that treat the allowlist as a one-time project rather than a continuous operational process find themselves either breaking production applications or gradually expanding exceptions until the policy is meaningless. CDA's APC methodology addresses this by integrating policy maintenance into the software delivery lifecycle itself.
---
---