When WDAC or AppLocker is only in audit mode, a local user can still execute the binary that starts the exploit chain. That leaves user-writable paths open for privilege escalation, so the first control failure is execution, not detection. Enforcement mode is what turns the policy into a real barrier.
What stops the exploit chain from starting?
Windows application control fails first at the execution boundary. If WDAC or AppLocker is only auditing, the policy may record the event, but it does not stop a local user from launching the binary that begins the exploit chain. That means the attack still gets to run from a user-writable location, which is exactly where privilege escalation paths often begin.
When application control is enforced, the decision changes from “observe and log” to “block and prevent.” That distinction matters because local exploit code usually assumes it can be started by the current user without needing a separate malware delivery step. If execution is already denied, the attacker never reaches the code path that would trigger the next privilege boundary failure.
Why audit mode is a weak control for local exploit code
Audit mode is useful for policy tuning, but it is not a containment control. It tells you what would have been blocked, not what was actually prevented, so user-space exploit testing can still succeed even while the logs look healthy. For this reason, audit-only rollout is best treated as a discovery phase, not a protection phase.
Local exploit code also tends to benefit from trusted Windows behaviours such as script hosts, LOLBins, installer-mediated execution, or user-controlled directories. If the policy does not actively deny those launch paths, the control plane is downstream of the exploit rather than in front of it. The practical result is that detection may happen after the user session is already compromised or privilege has already been raised.
For teams standardising Windows enforcement, the Application Allowlisting Guide is the natural reference for turning policy into an actual execution barrier, especially where WDAC and AppLocker coexist with managed installers, script control, and audit-mode rollout.
What the broken assumption really is
The broken assumption is that policy visibility is equivalent to policy enforcement. It is not. Audit mode can prove that a rule would have matched, but it cannot stop a signed, renamed, or locally staged binary from starting if the policy is not enforced. In other words, the security outcome depends on whether execution is denied before the first instruction runs, not on whether the event is later recorded.
This is why local exploit code is such a useful test case for application control maturity. The attacker does not need remote delivery success, phishing success, or an initial payload with broad privileges. They only need a permitted execution path, which makes weak allowlisting immediately visible as a privilege-escalation enabler rather than a logging gap.
For mature endpoint programmes, this is part of the broader control stack described in the Top 10 Endpoint Security Risks and the Endpoint Security Maturity Model, where application control is treated as one of the controls that materially reduces local attack paths, not just their observability.
Risk and Threat Considerations
When application control is not enforced, the main risk is that a low-privilege user can still launch code that should never have been allowed to execute. That makes user-writable paths, staging folders, and other local execution surfaces attractive because they preserve the attacker’s ability to start the exploit chain even when monitoring is present.
Failure mechanism: The policy is evaluated in audit mode only, so the binary is observed but not blocked. The exploit chain then reaches the code path needed for privilege escalation, persistence, or follow-on abuse before defenders can intervene.
Impact: The organisation loses the preventative value of application control and is left relying on detection after execution has already occurred. That increases the chance of local privilege escalation, broader endpoint compromise, and delayed containment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Application control blocks unapproved software execution on endpoints. |
| Recommendation — Enforce software allowlisting and block unknown executables on user endpoints. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Blocking exploit binaries is a core malicious-code prevention function. |
| AC-3 — Access Enforcement | Enforced allowlisting is an access decision over what code may execute. | |
| Recommendation — Deploy execution controls that prevent malicious code from running. Apply access enforcement to deny execution of unapproved binaries. | ||
| ISO/IEC 27001:2022 | A.8.7 — Protection Against Malware | Application control is a practical malware-prevention safeguard on endpoints. |
| Recommendation — Use endpoint execution controls to reduce malware and exploit code execution. | ||
Practitioner Guidance
What to verify: Confirm that the relevant WDAC or AppLocker policy is in enforcement for the target device set, not merely generating audit events. Verify the actual launch behaviour for binaries in user-writable locations, script hosts, and common living-off-the-land execution paths.
Decision rule: If a local binary can still execute from a path the user controls, treat the control as incomplete for exploit prevention, even if logging is working correctly. If the aim is to stop privilege escalation, execution denial has to happen before the exploit chain starts.
Practitioner takeaway: For local exploit code, the question is not whether you will see it run, but whether the endpoint will stop it from running at all. Audit mode supports tuning; enforcement mode creates the barrier.
Related resources from NHI Mgmt Group
- What breaks when LLM access control is limited to application code instead of a central policy layer?
- What breaks when a compensating control is deployed but never retested against the known exploit path?
- What breaks when input validation is the only control against code injection?
- What breaks when application control is not enforced on endpoints?