WDAC for Essential Eight: The Application Control Guide Nobody Wanted to Write

Application control is the strategy that stalls more Essential Eight projects than any other.

Not because the concept is hard. The concept is simple: only approved software runs on your machines. Everything else gets blocked.

The hard part is the tool you need to make it happen. Windows Defender Application Control. WDAC. It's powerful. It's also the thing most likely to brick your fleet if you get the policy wrong.

I've seen businesses cruise through the first five or six Essential Eight controls, then hit application control and stall for months. This guide is the honest version of what's involved.

What WDAC Actually Is

WDAC stands for Windows Defender Application Control. You might also see it called "App Control for Business," which is the newer name that shipped with Windows 11 24H2. Same technology, different label. Most people still call it WDAC.

In plain English, WDAC is an allowlisting tool built into Windows. You create a policy that says "these applications are approved." Everything not on the list gets blocked from running. Executables, scripts, installers, DLLs, even drivers.

That last part matters. WDAC operates at both user mode and kernel mode. It can control not just your apps but the drivers loading into the Windows kernel. AppLocker, the older tool, can only do user mode. This distinction is what makes WDAC necessary for higher Essential Eight maturity levels.

WDAC policies are device-wide. They apply to every user on the machine. You can't set different policies for different user groups the way you can with AppLocker. That's both a strength (harder to bypass) and a limitation (less flexible).

WDAC vs AppLocker

AppLocker has been around since Windows 7. It's simpler to set up and manage. But it's also being left behind.

AppLocker continues to receive security fixes but is no longer getting new feature improvements. Development effort has moved to WDAC. That doesn't mean AppLocker is going away tomorrow, but it does mean the gap between the two tools is only going to widen.

For Essential Eight compliance, the split is clear: AppLocker can meet Maturity Level 1. WDAC is required for Maturity Levels 2 and 3.

The key takeaway: if you're aiming for ML1 and want to move fast, AppLocker is a valid starting point. If you need ML2 (which is what most cyber insurers and government contracts expect), you need WDAC. And since AppLocker isn't getting new features, starting with WDAC makes sense if you plan to reach ML2 eventually.

What Each Maturity Level Requires for Application Control

The ASD's Essential Eight Maturity Model (updated November 2023) lays out specific requirements for application control at each level. Here's what they actually mean.

Maturity Level 1

The basics. Application control is implemented on workstations. Not servers, just workstations.

The policy must restrict executables, software libraries, scripts, installers, compiled HTML, HTML applications, and control panel applets to an approved set. This applies to user profiles and temporary folders used by the operating system, web browsers, and email clients.

In practice, this means blocking execution from paths like C:\Windows\Temp, %USERPROFILE%\AppData\Local, and %USERPROFILE%\AppData\Roaming. These are the directories where malware typically lands after a user clicks a bad link or opens a dodgy attachment.

Tool: AppLocker or WDAC. AppLocker is sufficient.

Timeline: 2-4 weeks for a 50-person business.

Maturity Level 2

This is where it gets serious. ML2 adds several requirements on top of ML1:

• Application control extends to internet-facing servers (not just workstations)
• The recommended application blocklist must be implemented (this blocks known-abused Windows tools used in "living off the land" attacks)
• Application control applies to all locations, not just user profiles and temp folders
• Rulesets must be validated annually (or more frequently)
• All allowed and blocked events must be centrally logged
• Event logs must be protected from modification and deletion
• Cyber security events must be analysed in a timely manner

Tool: WDAC. AppLocker cannot meet ML2 due to the additional ISM requirements around blocklists, server coverage, and kernel-level control.

Timeline: 8-12 weeks for a 50-person business, including audit mode discovery.

Maturity Level 3

ML3 extends application control to every server (not just internet-facing ones), adds driver control to an approved set, requires the vulnerable driver blocklist, and mandates SIEM integration for event analysis.

Most private businesses don't need ML3. It's designed for organisations facing nation-state level threats. If nobody has explicitly told you that you need ML3, you don't.

How to Actually Implement WDAC

The implementation follows a predictable sequence. Rushing through it is what causes problems.

Phase 1: Planning

Before you touch a policy, you need to know what's running in your environment. Every legitimate application. Every script. Every installer that IT runs.

There are three ways to create WDAC rules:

• Publisher rules (recommended). Trust software signed by a specific publisher. This is the most maintainable approach because new versions from the same publisher are automatically trusted.
• Hash rules. Trust a specific file by its cryptographic hash. Very secure but brittle. Every time the app updates, the hash changes and you need a new rule.
• Path rules. Trust everything in a specific folder. Convenient but weaker. Only acceptable if file system permissions prevent users from writing to that path.

For most businesses, publisher rules are the right default. Hash rules for anything unsigned. Avoid path rules unless you have strong NTFS permissions in place.

Phase 2: Audit Mode

This is the most important phase and the one people try to skip.

Deploy your WDAC policy in audit mode. It logs what would have been blocked but doesn't actually block anything. Users don't notice. Business carries on normally. Meanwhile, you're building a picture of every application that runs across your fleet.

Run audit mode for at least 2-4 weeks. Longer if your business has seasonal software (end-of-month reporting tools, quarterly finance packages). You want to capture everything before you start blocking.

The events show up in Windows Event Log under Microsoft-Windows-CodeIntegrity/Operational. Event ID 3076 means "this would have been blocked." Every one of those events needs investigation: is it legitimate software that needs a rule, or is it something that shouldn't be running?

Phase 3: Policy Refinement

This is the iterative part. Review audit logs. Find legitimate apps being flagged. Add them to your policy. Redeploy in audit mode. Repeat until the noise drops to near zero.

The WDAC Wizard (a free, open-source tool) makes this significantly easier. It provides a GUI for creating and editing policies instead of hand-editing XML. You can create policies from directory scans, certificate files, or audit log events. Download it from the official GitHub repository.

Phase 4: Managed Installer

If you're using Intune to deploy applications, configure it as a managed installer. This tells WDAC to trust anything that Intune deploys. It's a major quality-of-life improvement because you don't need individual rules for every app Intune pushes.

One catch: managed installer only applies to files installed after the policy is active. Apps installed before you enabled managed installer won't have the trust tag. Those need explicit rules in your policy.

Phase 5: Enforcement

Start with a pilot group. Pick 10-20 users who are representative of your environment (not just IT staff who only run standard tools). Enforce the policy on their devices. Watch for breakage. Fix it.

Then expand in waves. Department by department. Each wave is a chance to catch apps you missed in audit mode.

Critical safety net: Enable "Boot Audit on Failure" in your WDAC policy settings. If a system driver gets blocked and the device can't boot, this setting automatically switches the policy from enforcement back to audit mode. It's the difference between a support ticket and a bricked laptop.

Common Failure Modes

These are the things that actually go wrong. Not theoretical risks. Real problems I see in implementations.

Going straight to enforcement

Skipping audit mode is the single most common mistake. Someone reads the docs, writes a policy based on their known application list, and enforces it. Then discovers the finance team uses a 15-year-old reporting tool that nobody told IT about. Suddenly half the company can't work.

Always run audit mode first. No exceptions.

Forgetting about pre-existing applications

If you enable managed installer with Intune and assume everything is covered, you'll have a bad day. Managed installer only tags files that Intune installs after the policy is active. Every app already on the device needs an explicit rule. This catches almost every organisation that moves from "no application control" to "managed installer should handle it."

Not accounting for updates

Hash-based rules break every time an application updates. If you're relying on hash rules for frequently-updated software (browsers, PDF readers, collaboration tools), you'll be writing new rules weekly. Publisher rules are almost always the better choice for applications that update regularly.

Blocking line-of-business apps

Every organisation has at least one critical application that's poorly signed, unsigned, or behaves unusually. The old accounting package. The custom database tool from 2012. The industry-specific software that only runs as admin.

Find these during audit mode. Document them. Create specific rules. If the app genuinely can't be accommodated, you need a documented exception with compensating controls, not a policy that blocks it in production.

Ignoring the logging requirement

ML2 requires centrally logged application control events. That means a SIEM or equivalent. Defender for Endpoint P2 with Sentinel is the standard path for shops already in the Windows ecosystem, but any SIEM that can ingest Windows Event Logs works. Without central logging, you might have WDAC running perfectly and still fail your assessment.

What It Costs

WDAC itself is free. It's built into Windows 10 and 11 (Pro, Enterprise, and Education editions). The cost is in the time and expertise to implement it properly.

The real cost driver isn't the tool. It's the audit mode phase (someone needs to review every flagged event), the LOB app exceptions (custom rules for unusual software), and the central logging requirement (SIEM setup and ongoing costs).

For most 50-person SMEs, application control is $8,000-$15,000 of the total Essential Eight implementation budget when done with outside help. More if the environment is complex (legacy apps, multiple sites, mixed OS versions).

When to DIY vs Get Help

The honest answer: if you've never done WDAC before and you're on a compliance deadline, get help for the enforcement phase. The audit phase is safe to run internally. Enforcement is where experience matters.

If you have an experienced sysadmin who's comfortable with Windows security policies, Group Policy, and Intune, DIY is viable. Just budget the time. It's not a weekend project.

The AppLocker-First Path

If ML2 feels too far away right now, there's a valid stepping-stone approach.

Start with AppLocker for ML1. It's simpler, the risk of breaking things is lower, and it still blocks the most common attack paths (malware running from temp folders and user profiles). You can get AppLocker deployed in 2-4 weeks.

Then plan WDAC for ML2 as a separate project. You'll already have an inventory of your applications from the AppLocker phase, which makes the WDAC audit mode faster.

This two-step approach works well for businesses that need to show progress to their cyber insurer or a government contract but can't commit to a full ML2 implementation immediately.

Quick Reference: Application Control Requirements by Maturity Level

Getting Started

Application control is hard. It's not the kind of control you knock out in a weekend. But it's also not optional if you're targeting ML2, which is what most cyber insurers and government contracts expect.

Three things to do this week:

1. Find out what maturity level you actually need. If nobody has explicitly asked for ML2, start with ML1 (AppLocker). It's faster, cheaper, and still blocks the most common malware delivery paths.

2. Start an application inventory. Before any policy work, you need to know what software runs in your environment. Intune's app discovery, or even a simple spreadsheet from your IT team, is a starting point.

3. Deploy WDAC in audit mode on a handful of devices. Not enforcement. Just audit. Let it run for a few weeks. Look at what gets flagged. That data tells you how big the project really is.