Windows Defender Application Control is a Windows code integrity feature that permits only approved drivers, scripts, DLLs, and applications to run. It shifts enforcement from detecting bad software after the fact to allowing only known-good code paths before execution begins.
Expanded Definition
Windows Defender application control, often shortened to WDAC, is a Windows code integrity control that restricts execution to approved binaries, scripts, DLLs, and drivers. It is best understood as a policy-based allowlisting mechanism for endpoint code, rather than a detection tool. That distinction matters: WDAC does not primarily look for malicious behavior after launch, it constrains what can launch at all.
In practice, WDAC is used to enforce trust decisions at the operating system layer. Policies can be built around publisher rules, file hashes, path rules, or combinations of these signals, depending on the assurance required and the operational tolerance for change. Definitions and deployment patterns vary across vendors and practitioners, but the security goal is consistent: reduce the chance that unapproved code can execute on a managed Windows device. NIST guidance on application allowlisting and endpoint hardening is directionally aligned with this model, even when it does not name WDAC explicitly.
The most common misapplication is treating WDAC as a one-time hardening setting, which occurs when organisations deploy an allow policy without a process for application updates, exceptions, and signed software lifecycle management.
Examples and Use Cases
Implementing WDAC rigorously often introduces operational friction, requiring organisations to weigh stronger execution control against the cost of policy maintenance and application onboarding.
- Restricting workstations so only Microsoft-signed code and approved line-of-business applications can run, helping block opportunistic malware and unauthorized utilities.
- Protecting high-value administrative endpoints by allowing only trusted management tools, reducing the risk of credential theft tooling and post-exploitation payloads.
- Controlling script execution in environments that rely heavily on PowerShell, where signed scripts and constrained policy states can reduce unsafe ad hoc execution.
- Supporting incident response by narrowing the executable surface, making it easier to investigate unexpected binaries after alerts from CISA cyber threat advisories.
- Separating production and developer workstations with different policy baselines so that experimental tooling does not appear on sensitive systems by default.
Why It Matters for Security Teams
WDAC matters because many endpoint compromises succeed through trusted execution paths, not through obviously malicious files. If security teams focus only on malware detection, they can miss the larger problem of uncontrolled software execution. WDAC closes that gap by turning execution into an explicit governance decision, which is especially valuable where devices handle privileged access, sensitive data, or administrative sessions.
The identity connection is direct. On endpoints used for privileged access, application control helps protect tokens, certificates, browser sessions, and admin tooling from being abused by unapproved code. That makes WDAC relevant to privileged access management, non-human identity operations, and agentic workflows that depend on signed tooling or tightly governed executables. It also complements broader Zero Trust Architecture by reducing implicit trust in local software.
For teams aligning endpoint policy with resilience expectations, NIST Cybersecurity Framework concepts around protective controls, and NIST software allowlisting guidance provide useful context for policy governance. Organisations typically encounter the real value of WDAC only after an unapproved tool, script, or loader is used during a compromise, at which point application control becomes operationally unavoidable to contain execution paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.PT | Protective technology guidance covers application control as an endpoint hardening measure. |
| NIST SP 800-53 Rev 5 | CM-7 | Least functionality control supports restricting software to only what is explicitly approved. |
| NIST Zero Trust (SP 800-207) | Zero trust assumes no implicit trust in endpoint software or execution context. | |
| NIST SP 800-63 | Credential and authenticator protection depends on trusted endpoint execution environments. | |
| OWASP Non-Human Identity Top 10 | NHI operations depend on governing scripts, agents, and tooling that WDAC can constrain. |
Protect authenticators and session material by restricting unapproved code on admin endpoints.
Related resources from NHI Mgmt Group
- What is the difference between application input validation and identity control?
- What is the difference between PAM and basic access control for Windows Server?
- Why does relationship-based access control matter for application and NHI governance?
- What do teams get wrong about policy engines and application access control?
