Windows Defender Application Control (WDAC): Enterprise Application Whitelisting and Code Integrity

Modern enterprise security demands more than reactive malware detection. Windows Defender Application Control (WDAC) represents a fundamental shift in endpoint protection philosophy—moving from “allow everything unless blocked” to “deny everything unless explicitly permitted.” For system administrators managing Windows environments facing sophisticated threats, ransomware, and supply chain compromises, WDAC provides kernel-level enforcement that validates every piece of executable code before it runs.

What is Windows Defender Application Control (WDAC)?

Windows Defender Application Control (WDAC) is a code integrity policy enforcement system built into Windows 10, Windows 11, and Windows Server 2016 and later. Rather than relying solely on signature-based antivirus detection, WDAC restricts code execution to applications, scripts, and drivers that meet administrator-defined policy rules. This application whitelisting approach operates at both kernel-mode and user-mode, controlling executables, DLLs, MSI installers, PowerShell scripts, and even macros.

According to Microsoft’s official documentation, WDAC is one of the most effective defenses against executable-based malware because it inverts the traditional security model. Instead of asking “is this known to be bad?” WDAC asks “is this approved to run?” This fundamental shift protects against zero-day exploits, polymorphic malware, and advanced persistent threats that evade traditional antivirus solutions.

WDAC is available across all Windows editions—Professional, Enterprise, and Education—making it accessible beyond just high-security environments. It evolved from earlier technologies like Device Guard and relates to other application control mechanisms like AppLocker and Smart App Control, but provides deeper kernel-level enforcement and more granular policy options. Integration with Microsoft’s Intelligent Security Graph (ISG) enables cloud-powered reputation checks, combining local policy enforcement with global threat intelligence.

The Problem WDAC Solves

Traditional antivirus solutions face inherent limitations in modern threat landscapes. Signature-based detection cannot protect against zero-day malware that lacks known signatures. Behavioral analysis can be fooled by sophisticated obfuscation techniques. Meanwhile, attackers increasingly leverage “living-off-the-land” tactics—using legitimate Windows binaries like PowerShell, WMI, and certutil to execute malicious operations without dropping traditional malware files.

Supply chain compromises present another challenge. When attackers steal or abuse legitimate code-signing certificates, malicious software appears trusted to conventional security controls. The SolarWinds breach demonstrated how signed malware can bypass standard defenses and persist for months. Similarly, ransomware operators frequently use stolen credentials and approved remote access tools to move laterally through networks before deploying encryption payloads.

Compliance frameworks recognize these limitations. The National Institute of Standards and Technology (NIST), Center for Internet Security (CIS) Benchmarks, and Australia’s Signals Directorate all recommend application whitelisting as an essential security control. Organizations in regulated industries—healthcare, finance, government—face requirements to demonstrate positive control over code execution, not just reactive detection.

WDAC addresses these problems by establishing a trust boundary around executable code. Rather than trusting all signed applications or attempting to identify malicious patterns, WDAC requires explicit approval for every executable, script, and driver. This “default deny” posture prevents unauthorized software installation by both external attackers and internal users, while maintaining legitimate business functionality through carefully constructed policies.

How WDAC Works

At the core of WDAC sits Windows’ Code Integrity (CI) engine, a kernel component that validates digital signatures and policy compliance before allowing code to execute. When a process attempts to start, load a DLL, or execute a script, the CI engine checks this action against active WDAC policies. Only when the code meets policy requirements does execution proceed—otherwise, the system blocks the operation and logs an event.

WDAC policies are XML documents that define which code is permitted to run. These policies contain rules specifying allowed signers (certificate authorities or specific publishers), file hashes (cryptographic fingerprints of approved files), file paths (locations where trusted code resides), and file attributes (properties like product name or version number). Policies support both allow-lists and deny-lists, enabling administrators to block known-bad code even when it would otherwise meet approval criteria.

The system supports multiple rule types with different security-flexibility trade-offs:

• Publisher rules validate code signatures against specified publishers and optionally require minimum version numbers, balancing security with the flexibility to accept application updates
• Hash rules explicitly authorize specific file versions based on SHA256 fingerprints, providing maximum security but requiring policy updates with every application patch
• File path rules permit code based on location, offering flexibility but less security since users can potentially copy unauthorized files to trusted locations
• SignedVersion rules combine publisher validation with version constraints, allowing updates while preventing downgrade attacks
• FileAttribute rules match against PE file properties like product name, internal name, or original filename

Policies operate in two modes. Audit mode monitors what would be blocked without enforcement, logging events for policy refinement. Enforcement mode actively prevents execution of policy violations. This dual approach enables safe testing before deployment.

WDAC supports a modular architecture through base policies and supplemental policies. A base policy establishes organization-wide controls, while supplemental policies add exceptions for specific departments, applications, or use cases without modifying the base. Multiple supplemental policies can be active simultaneously, simplifying exception management.

For PowerShell, WDAC enforces Constrained Language Mode, which restricts scripts to a safe subset of cmdlets and prevents access to dangerous .NET types. This control operates at the PowerShell engine level, preventing bypass through alternate shells or script hosts. Events are logged to the Microsoft-Windows-CodeIntegrity/Operational event log, with Event ID 3076 for audit mode violations, 3077 for enforcement blocks, and 3089 for policy activation.

WDAC vs. AppLocker vs. Smart App Control

Microsoft offers three application control technologies with different target audiences and capabilities:

WDAC is appropriate for large enterprises with complex line-of-business applications, servers requiring kernel-mode driver control, and environments needing deep integration with existing security infrastructure. Its kernel-level enforcement provides protection against advanced threats and rootkits.

AppLocker suits organizations with simpler requirements and existing Group Policy infrastructure. It provides user-mode application control with lower complexity but lacks kernel-mode protection and restricts availability to Enterprise and Education editions only.

Smart App Control targets consumer devices and small businesses with standard software portfolios. It operates automatically using cloud reputation checks and requires minimal configuration but offers limited policy customization. Organizations can migrate from AppLocker to WDAC for enhanced protection, though policies must be recreated rather than converted. While both can technically coexist on a system, Microsoft recommends choosing one to avoid conflicting rules and management complexity.

Components and Key Concepts

Policy Structure

WDAC policies are XML documents defined by the SiPolicy.xsd schema. Key elements include:

• PolicyInfo: Metadata including policy GUID, name, and version number
• Rules: Configuration options like audit mode, script enforcement, and boot driver restrictions
• Signers: Trusted certificate authorities and publishers, optionally with EKU (Extended Key Usage) constraints
• FileRules: Hash-based and path-based rules authorizing specific files
• SigningScenarios: Separate rule sets for user-mode and kernel-mode code
• UpdatePolicySigners: For signed policies, signers authorized to deploy policy updates

Policy Options

Rule options control policy behavior. Common options include:

• Option 3 (Enabled:Audit Mode): Log violations without blocking
• Option 0 (Enabled:UMCI): Enable User Mode Code Integrity
• Option 6 (Enabled:Unsigned System Integrity Policy): Allow unsigned policy updates (less secure but simpler)
• Option 11 (Disabled:Script Enforcement): Disable PowerShell script restrictions
• Option 16 (Enabled:Update Policy No Reboot): Apply policy updates without restart
• Option 19 (Enabled:Dynamic Code Security): Validate dynamically generated code

Signers and Certificates

WDAC validates code based on the certificate chain used for signing. Policies can trust:

• Specific leaf certificates (individual publishers)
• Intermediate CA certificates (multiple publishers under one authority)
• Root CA certificates (broad trust, less granular)
• Windows Hardware Quality Labs (WHQL) signatures for drivers

Certificate rules can include additional constraints like Extended Key Usage values (code signing, kernel-mode signing) and minimum version numbers to prevent downgrade attacks.

CiTool Utility

Introduced in Windows 11 22H2 and Windows Server 2025, CiTool.exe provides command-line policy management. The official reference documents commands for deploying, listing, removing, and refreshing policies without manual file operations.

Managed Installer

The Managed Installer concept automatically trusts applications deployed by approved software distribution systems like Microsoft Intune, Configuration Manager, or third-party tools. When enabled, WDAC tags executables installed by managed installers as trusted, significantly reducing policy maintenance burden.

Real-World Use Cases

Financial Services Compliance: A global bank deploys WDAC across 50,000 trading workstations to meet regulatory requirements for application control. Base policies restrict execution to approved trading platforms, Bloomberg terminals, and standard business applications. Supplemental policies handle department-specific tools while maintaining audit evidence for compliance reviews.

Healthcare Ransomware Prevention: A hospital system implements WDAC on clinical workstations and servers after a near-miss with ransomware. Publisher-based policies allow approved EMR systems, medical devices, and standard productivity tools while blocking PowerShell execution in user context. Twelve months post-deployment, the system has blocked 847 unauthorized execution attempts including several confirmed malware samples.

Government High-Security Networks: A defense agency uses WDAC with signed policies on classified networks. Hash-based rules enforce strict version control, requiring policy updates for every approved software change. HVCI (Hypervisor-protected Code Integrity) adds virtualization-based security, preventing kernel-mode exploits even with administrator privileges. WDAC enforcement is particularly critical on Privileged Access Workstations (PAWs), where restricting code execution to explicitly approved administrative tools prevents credential theft and lateral movement.

Manufacturing OT/IT Convergence: An automotive manufacturer applies WDAC to industrial control system endpoints interfacing with manufacturing equipment. Locked-down policies prevent unauthorized software installation on HMIs and SCADA systems, reducing risk of operational disruption from malware or insider actions.

Managed Service Provider Multi-Tenant Security: An MSP standardizes WDAC across customer environments using Intune for cloud-based policy distribution. Base policies enforce organizational security requirements, while customer-specific supplemental policies accommodate line-of-business applications. Centralized logging aggregates enforcement events across all tenants for security monitoring.

Getting Started with WDAC

Prerequisites and Planning

Successful WDAC deployment requires executive sponsorship and business alignment. As Microsoft’s design guide emphasizes, application control is fundamentally a business decision that impacts user productivity, application compatibility, and operational workflows. Technical implementation follows strategic planning.

Begin with comprehensive application inventory. Catalog all executables, scripts, drivers, and components across representative systems. Identify:

• Standard business applications (Office, browsers, LOB software)
• Custom or legacy applications without modern signatures
• Administrative tools required by IT staff
• Scheduled tasks and service executables
• Browser plugins and extensions
• Macros and scripts used in business processes

Establish a ring deployment strategy:

1. Ring 0 (IT Pilot): Deploy to 10-20 IT-managed systems in audit mode
2. Ring 1 (Department Pilot): Expand to 100-200 users in a single business unit
3. Ring 2 (Production Rollout): Deploy to remaining systems in phases
4. Ring 3 (Monitoring): Continuous refinement based on helpdesk requests

Creating Your First Policy

Start with Microsoft-recommended baseline policies located in %windir%\schemas\CodeIntegrity\ExamplePolicies:

• DefaultWindows_Enforced.xml: Allows only Windows components (very restrictive)
• AllowMicrosoft.xml: Permits Windows and Microsoft-signed software
• SmartAppControl.xml: Replicates Smart App Control behavior for enterprises

The following PowerShell creates a baseline policy by copying and modifying the Smart App Control example:

# Copy Smart App Control example policy as baseline
Copy-Item "$env:windir\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml" `
          -Destination "C:\WDAC\BasePolicy.xml"

# Remove the Conditional Windows Lockdown option to convert to WDAC policy
[xml]$policy = Get-Content "C:\WDAC\BasePolicy.xml"
$rules = $policy.SiPolicy.Rules.Rule | Where-Object { $_.Name -ne "Enabled:Conditional Windows Lockdown Policy" }
$policy.SiPolicy.Rules.RemoveAll()
$rules | ForEach-Object { $policy.SiPolicy.Rules.AppendChild($_) | Out-Null }
$policy.Save("C:\WDAC\BasePolicy.xml")

Alternatively, scan a reference system with your approved applications installed:

# Scan system for installed applications and generate policy
New-CIPolicy -FilePath "C:\WDAC\ScanPolicy.xml" `
             -ScanPath "C:\" `
             -Level Publisher `
             -Fallback Hash `
             -UserPEs

# Add common Microsoft product rules
New-CIPolicy -FilePath "C:\WDAC\MSRules.xml" `
             -Level Publisher `
             -UserPEs

# Merge the policies
Merge-CIPolicy -PolicyPaths "C:\WDAC\ScanPolicy.xml","C:\WDAC\MSRules.xml" `
               -OutputFilePath "C:\WDAC\MergedPolicy.xml"

The -Level parameter determines rule granularity:

• Publisher: Most flexible, allows updates from same publisher
• SignedVersion: Publisher plus minimum version
• FilePublisher: Publisher plus specific filename
• Hash: Most secure, requires policy update for each file version
• FileName: Matches only the filename (weak security)

Testing in Audit Mode

Enable audit mode to test policy impact without blocking execution:

# Set policy to audit mode (logs blocks without enforcement)
Set-RuleOption -FilePath "C:\WDAC\TestPolicy.xml" -Option 3

# Deploy audit mode policy
ConvertFrom-CIPolicy -XmlFilePath "C:\WDAC\TestPolicy.xml" `
                     -BinaryFilePath "C:\WDAC\TestAudit.cip"
CiTool --update-policy "C:\WDAC\TestAudit.cip"

# Monitor audit events in Event Viewer
# Microsoft-Windows-CodeIntegrity/Operational log
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" `
             -MaxEvents 50 | Where-Object { $_.Id -eq 3076 }

Run audit mode for at least 30 days to capture monthly processes like payroll systems, end-of-month reporting, and quarterly tasks. Analyze logged events to identify legitimate applications requiring policy additions.

Deploying to Enforcement Mode

Once audit mode testing confirms policy completeness, convert to enforcement:

# Convert XML policy to binary CIP format
ConvertFrom-CIPolicy -XmlFilePath "C:\WDAC\MergedPolicy.xml" `
                     -BinaryFilePath "C:\WDAC\{PolicyGUID}.cip"

# Deploy policy using CiTool (Windows 11 22H2+)
CiTool --update-policy "C:\WDAC\{PolicyGUID}.cip"

# Refresh policies to activate immediately
CiTool --refresh

# Alternative: Copy to enforcement directory (legacy method)
Copy-Item "C:\WDAC\{PolicyGUID}.cip" `
          -Destination "$env:windir\System32\CodeIntegrity\CiPolicies\Active\"

Policies activate immediately with CiTool or after reboot with legacy deployment. Monitor the first 48 hours closely for user impact.

Managing Exceptions with Supplemental Policies

Rather than modifying the base policy for every new application, create supplemental policies:

# Generate supplemental policy for specific application directory
New-CIPolicy -FilePath "C:\WDAC\Supplemental_LOB.xml" `
             -ScanPath "C:\Program Files\LineOfBusinessApp" `
             -Level Publisher `
             -Fallback Hash `
             -UserPEs

# Set as supplemental to base policy
Set-CIPolicyIdInfo -FilePath "C:\WDAC\Supplemental_LOB.xml" `
                   -SupplementsBasePolicyID "{BasePolicy-GUID-Here}" `
                   -PolicyName "LOB Application Supplement"

# Convert and deploy
ConvertFrom-CIPolicy -XmlFilePath "C:\WDAC\Supplemental_LOB.xml" `
                     -BinaryFilePath "C:\WDAC\Supplement_LOB.cip"
CiTool --update-policy "C:\WDAC\Supplement_LOB.cip"

Supplemental policies require Option 17 (Enabled:Allow Supplemental Policies) in the base policy. This modular approach enables department-specific exceptions without impacting organization-wide controls.

Monitoring and Troubleshooting

Event Monitoring

WDAC enforcement generates events in the Microsoft-Windows-CodeIntegrity/Operational log:

• Event ID 3076: Audit mode - code would be blocked under enforcement
• Event ID 3077: Enforcement mode - code execution blocked
• Event ID 3089: WDAC policy successfully activated
• Event ID 3099: Driver failed signature validation

Query recent blocks with PowerShell:

# List all policies on system (including inactive)
CiTool --list-policies

# List only enforced policies with PowerShell filtering
(CiTool -lp -json | ConvertFrom-Json).Policies | 
  Where-Object {$_.IsEnforced -eq "True"} |
  Select-Object PolicyID, FriendlyName, Version

# Remove specific policy by GUID
CiTool --remove-policy "{BF61FE40-8929-4FDF-9EC2-F7A767717F0B}"

Integrate these events with Windows Event Forwarding for centralized visibility or SIEM platforms like Microsoft Sentinel, Splunk, or Elastic for correlation with other security telemetry.

Common Issues and Solutions

Problem: Legitimate application updates are blocked after deployment.

Solution: Use publisher rules with SignedVersion instead of hash rules. Publisher rules trust the signing certificate, allowing updated files from the same publisher. Alternatively, implement managed installer trust to automatically approve software distributed through approved deployment tools.

Problem: PowerShell scripts fail with “Cannot run” errors.

Solution: WDAC enforces script signing. Either sign scripts with a trusted certificate, add script hashes to policy, or use publisher rules for signed scripts. For development environments, Option 11 disables script enforcement (less secure).

Problem: Custom line-of-business applications lack valid signatures.

Solution: Implement internal code signing infrastructure using Active Directory Certificate Services or a third-party CA. Sign LOB applications with enterprise certificates and add the signing certificate to WDAC policy. Alternatively, use hash rules for unsigned legacy applications that cannot be re-signed.

Problem: Drivers fail to load causing hardware malfunctions.

Solution: Verify drivers have valid WHQL signatures. Add WHQLFilePublisher rules for specific drivers or use hash rules for unsigned legacy drivers. Test driver policies thoroughly in isolated environments before production deployment.

Problem: Policy deployment causes boot failures or system instability.

Solution: Boot into Safe Mode or Windows Recovery Environment. Policies in %windir%\System32\CodeIntegrity\CiPolicies\Active\ can be manually removed. For signed policies, you must deploy a signed policy update or use recovery procedures documented in your deployment plan.

Performance Considerations

WDAC adds minimal CPU overhead—typically under 2% even on high-throughput servers. Code signature validation occurs once per executable load and caches results. Hash verification is optimized through catalog files and intelligent caching.

For very large deployments (10,000+ systems), consider:

• Using publisher rules rather than hash rules to reduce policy file size
• Implementing multiple base policies for different system types (workstations, servers, specialized systems)
• Distributing policies through Group Policy rather than copying large CIP files
• Enabling Option 16 (Update Policy No Reboot) to apply policy changes without restart

Advanced WDAC Scenarios

Managed Installer Configuration

Managed Installer trust automatically approves applications deployed by specified tools, dramatically reducing policy maintenance:

# Enable managed installer in base policy
Set-RuleOption -FilePath "C:\WDAC\BasePolicy.xml" -Option 13

# Add Intune as managed installer (using Microsoft's example)
# Requires Windows 10 1903+ and managed device enrollment

Applications installed by Intune, Configuration Manager, or other approved deployment systems are automatically tagged as trusted. Manual installations remain subject to policy restrictions.

Multiple Policy Format

Windows 10 version 1903 and later support multiple simultaneous base policies (not just base + supplementals). This enables:

• Separate policies for different security zones
• Organization-wide policy plus business-unit-specific policies
• Microsoft recommended default policy alongside custom rules

Convert single-policy format to multiple-policy format:

Set-CIPolicyIdInfo -FilePath "C:\WDAC\Policy.xml" -ResetPolicyID
Set-RuleOption -FilePath "C:\WDAC\Policy.xml" -Option 2

Integration with HVCI

Hypervisor-protected Code Integrity (HVCI) uses virtualization-based security to protect Code Integrity enforcement from tampering. Even administrators cannot disable WDAC when HVCI is active. Enable through:

# Check HVCI status
Get-ComputerInfo | Select-Object DeviceGuardSecurityServicesConfigured

# Enable via Group Policy:
# Computer Configuration → Administrative Templates → System → Device Guard
# Turn On Virtualization Based Security

HVCI requires compatible hardware (Intel VT-x/AMD-V, SLAT, UEFI with Secure Boot) and may impact legacy driver compatibility.

Dynamic Code and JIT Compilation

Applications using Just-In-Time compilation (.NET applications, Java, JavaScript engines) generate code at runtime. Enable Option 19 (Dynamic Code Security) to validate dynamically generated code while allowing legitimate JIT scenarios.

Common Misconceptions

Misconception: WDAC is only for high-security government environments.

Reality: WDAC is available in all Windows Pro, Enterprise, and Education editions and provides valuable protection for any organization. Many mid-market companies successfully implement WDAC using baseline policies with incremental customization. The key is starting with audit mode and building policy incrementally rather than attempting perfect day-one coverage.

Misconception: WDAC prevents all legitimate software updates and breaks business operations.

Reality: Publisher-based rules allow applications to update automatically as long as updates come from the same trusted publisher. Managed installer trust further reduces friction by automatically trusting software deployed through approved distribution tools. Properly designed policies minimize operational impact while maintaining security.

Misconception: WDAC replaces antivirus and endpoint protection.

Reality: WDAC is a complementary defense-in-depth control, not a replacement. It works alongside Microsoft Defender for Endpoint, EDR solutions, Windows Firewall, and traditional antivirus. WDAC prevents unauthorized code execution, while EDR detects anomalous behavior, and antivirus catches known malware that might bypass other controls.

Related Technologies and Further Reading

WDAC integrates with broader Windows security hardening practices including BitLocker encryption, Credential Guard, and Attack Surface Reduction rules. Organizations implementing Zero Trust architecture use WDAC as the application-layer trust enforcement mechanism, validating code integrity before allowing execution.

For centralized management, Group Policy and Microsoft Intune provide enterprise-scale deployment capabilities. PowerShell security features including Script Block Logging complement WDAC’s Constrained Language Mode to provide comprehensive script execution control.

The Microsoft Tech Community maintains active forums for WDAC questions, and Microsoft regularly publishes updated example policies and guidance in their GitHub repositories. The App Control for Business community provides real-world deployment experiences and troubleshooting assistance.

Conclusion

Windows Defender Application Control transforms Windows endpoint security from reactive detection to proactive prevention. By enforcing explicit trust requirements for all executable code, WDAC protects against zero-day exploits, supply chain compromises, and sophisticated threats that evade traditional antivirus. While implementation requires planning and testing, the security benefits justify the investment for organizations facing modern threat landscapes. Starting with Microsoft’s baseline policies, deploying in audit mode, and using supplemental policies for exceptions provides a pragmatic path to enterprise-wide application control.