Two built-in Windows features restrict what software may run: AppLocker and Windows Defender Application Control (WDAC, formerly Device Guard Code Integrity). They overlap enough that teams pick the wrong one and then fight it. AppLocker is policy-through-Group-Policy and readable by anyone who understands file paths and publishers. WDAC is kernel-enforced code integrity with a signed policy, richer file rules, and a harder failure mode. This comparison maps the technical differences, shows where each belongs on a Windows Server VPS, and gives a staged rollout that avoids locking yourself out. Any host you deploy this on needs the policy files staged before enforcement, which is worth planning on the Windows VPS hosting comparison.
Core Differences
| Dimension | AppLocker | WDAC |
|---|---|---|
| Enforcement layer | User mode, AppLocker service | Kernel code integrity |
| Policy format | GPO XML | Signed binary policy |
| Rule types | Path, publisher, file hash | Path, publisher, hash, package, PE attributes |
| Signed policy required | No | Yes for protected mode |
| Managed installer | No | Yes |
| Kernel driver control | Limited | Full |
| Bypassable by local admin | Yes | Harder; kernel enforced |
| Script support | Native (.ps1, .bat) | Via rules + script enforcement |
When AppLocker Is the Right Tool
- You need to block scripts and installers by publisher without signing infrastructure.
- You manage the fleet with Group Policy and want policy visible in the GPO editor.
- The threat model is insiders or dropped files, not a determined administrator.
- You want audit-only rollout with minimal friction.
AppLocker’s weakness is that a local administrator can stop or bypass it. On a single-tenant VPS where the admin is you, that is often acceptable. On a shared or delegated box, it is not.
When WDAC Is the Right Tool
- You must guarantee only trusted code runs, including kernel drivers.
- You can sign and distribute a policy through your management plane.
- You are defending against a privileged attacker or an advanced persistent threat.
- You want to allow known-good code and deny everything else by default.
WDAC’s cost is operational: policies must be signed, versioned, and delivered without bricking the host. On a small VPS the signing workflow is often the reason WDAC stalls in audit mode indefinitely.
Can You Run Both?
Yes, and it is common. WDAC enforces at the kernel while AppLocker handles user-mode script and installer rules that are easier to express as GPO. Where both apply, WDAC wins — a file allowed by AppLocker but blocked by WDAC will not run. Keep that ordering in mind when troubleshooting.
A Staged Rollout
- Audit only. Create the policy with enforcement off and collect events (AppLocker 8003/8004; WDAC 3076/3077) for two to four weeks.
- Build the allowlist from the observed-good hash or publisher data, not from guesses.
- Enforce on one non-critical host. Keep a fallback: physical console, or a signed “audit” policy you can swap in.
- Expand. Roll across the fleet only after the first host runs a full business cycle without blocks.
Avoiding Lockout
The classic failure is enforcing a policy that blocks the management agent or RDP stack, leaving no way back in. Mitigate with three habits: always keep an audit-mode policy ready to swap, never enforce remotely until verified on a console, and exclude the binaries your access path depends on (winlogon, the RDP client stack, your EDR agent) until the baseline is proven.
Choosing Between Them
| Scenario | Recommended |
|---|---|
| Block unsigned scripts on a dev box | AppLocker |
| Prevent kernel driver loads | WDAC |
| Simple publisher rules, GPO-managed | AppLocker |
| Hardened production server, can sign policies | WDAC |
| Both script and kernel control | WDAC + AppLocker |
Deployment Notes
Application control is a strong hardening layer, but it is not a first move. Patch management, least-privilege accounts, and a hardened RDP surface come first — application control without those simply locks a vulnerable box more tightly.
Performance and Storage Implications
Both features add measurable overhead, though small on modern hardware. AppLocker checks cost roughly 5–15 ms of latency on first launch of a binary and near zero on subsequent runs cached in the app’s session. WDAC’s kernel checks add negligible per-launch cost but expand policy evaluation at boot and on every driver load.
- Audit-mode logging volume — on a busy server, 3077 (would-block) and 8004 (AppLocker audit) events can produce thousands of entries per day. Size the log drive or forward events off-box.
- Signed policy storage — WDAC policies live in a protected system path and are part of the boot chain; keep backups on separate media.
- Rule count — thousands of publisher rules measurably slow policy evaluation; consolidate with hash rules or a managed installer where possible.
Once your baseline configuration is solid, budget the operational effort application control requires; if hardware capacity for the extra policy evaluation and logging is in question, check the tiers on the Windows VPS provider comparison.
Decision Summary
- Start with AppLocker when you want script and installer control managed through Group Policy and can accept that a local admin can stop it.
- Choose WDAC when the requirement is kernel-enforced code integrity, driver control, and resistance to privileged tampering — and you can run a signing workflow.
- Run both when you need broad user-mode coverage plus a hard kernel boundary; remember WDAC takes precedence when rules conflict.
- In every case, roll out in audit mode, build the allowlist from observed data, and keep an escape hatch before enforcing.
Neither tool replaces fundamental hygiene. Patch consistently, remove standing admin rights, and restrict the RDP and WinRM surface first. Application control is the layer that stops what gets past those — not the layer that makes them unnecessary.
