TL;DR: Essential 8 application control is a default-deny control that decides which programs, scripts and libraries are permitted to run on your systems. ML1 targets user-writable paths on workstations and internet-facing servers. ML2 extends that to all servers with centralised logging. ML3 mandates publisher certificate rules and WDAC enforcement at the kernel level. The ACSC lists it first among the eight strategies because it is one of the most effective mitigations against malware that relies on execution to cause damage.
What is application control in the Essential Eight?
Application control is one of the eight mitigation strategies in the ACSC's Essential Eight framework, and the ACSC places it at the top of the list for a reason. Where antivirus detects known-malicious files after they arrive, application control prevents unauthorised programs from executing in the first place. It operates on a default-deny basis: only programs on an approved list run.
The ACSC's Essential Eight Maturity Model defines application control as governing which executables, software libraries, scripts, installers, compiled HTML files, HTML applications and control panel applets are permitted to execute on a system. That covers the full range of entry points attackers use: a downloaded .exe, a PowerShell script triggered by a phishing email, or a malicious .dll loaded by a compromised browser extension.
Application control must be assessed across all maturity levels alongside the other seven strategies. For a breakdown of how ML1, ML2 and ML3 differ across all eight controls, see the Essential 8 maturity levels overview.
What application control blocks
Application control targets a specific gap: attackers who land a file on a system and then need it to execute. Ransomware, remote access trojans, keyloggers and spyware all require execution to cause harm. So do lateral movement tools such as Cobalt Strike payloads and the living-off-the-land binaries attackers drop into temporary folders before use.
The ACSC identifies user-writable paths as the critical exposure. Locations including %TEMP%, %APPDATA%, the Downloads folder and the Desktop are paths where a standard user can write files. These are the preferred landing zones for malware because they are almost always writable by the logged-in user. Application control that blocks execution from these paths removes the most common delivery-to-execution pathway.
Higher maturity levels address more sophisticated bypass techniques. At ML1, path rules are acceptable, but an attacker who can write to an approved path can bypass them. ML3's preference for publisher certificate rules closes that gap: a rule tied to a software vendor's code-signing certificate cannot be bypassed by placing a file at an approved directory path.
Essential 8 application control at ML1
ML1 requires application control on workstations and internet-facing servers, applied to the locations most commonly exploited for malware execution.
Per the ACSC's Essential Eight Maturity Model [1], ML1 application control must cover executables, software libraries, scripts, installers, compiled HTML files, HTML applications and control panel applets. It must apply to user profiles and temporary folders used by the operating system, web browser and email client. Allowed and blocked execution events must be logged on workstations and internet-facing servers, and those logs must be protected from modification or deletion by unprivileged users.
Rules at ML1 can be path-based, hash-based or publisher certificate-based. The ACSC notes that publisher and hash rules provide stronger control than path rules, because path rules can be bypassed when users have write access to an approved location.
The practical bar at ML1 is achievable for most Australian SMBs: block execution from user-writable paths on workstations, build a basic approved list covering standard business software, and make sure logs are captured and protected. For a full control-by-control walkthrough of all eight ML1 requirements, see the Essential 8 ML1 checklist.
ML2: server coverage and centralised logs
ML2 extends application control requirements in two directions: broader coverage and stricter monitoring.
Per the ACSC, ML2 requires application control on all servers, not only internet-facing ones. Internal servers that sit outside ML1 scope come into scope at ML2. ML2 also requires centralised logging: event logs from workstations and all servers must be sent to a logging facility inaccessible to the systems being monitored. This prevents an attacker who compromises a workstation from tampering with local logs to cover their activity.
ML2 also requires annual review and validation of application control rulesets. Software gets added over time without corresponding ruleset updates, old rules for removed software remain in place, and coverage gaps open. The annual validation requirement exists to catch this drift before an assessor or attacker does.
For most organisations, moving from ML1 to ML2 for application control means extending deployment to internal servers and routing logs to a centralised platform such as Microsoft Sentinel, Splunk or a managed security operations centre.
ML3: publisher certificate rules and WDAC
ML3 sets a significantly higher bar, targeting the bypass techniques that capable attackers use against ML1 and ML2 deployments.
Per the ACSC, ML3 requires publisher certificate rules as the preferred rule type, moving away from path and hash rules. ML3 also requires implementation of Microsoft's recommended application blocklist, which covers known-vulnerable and abused binaries that should never execute even if a publisher certificate would otherwise permit them.
The most significant ML3 requirement is the choice of tool. The ACSC requires an application control solution that enforces at both user-mode and kernel-mode [2]. In the Windows environment, that means Windows Defender Application Control (WDAC), not AppLocker. AppLocker operates at user-mode only and does not restrict administrator accounts by default. WDAC enforces at kernel-mode, applies to all users including local administrators, and when combined with Hypervisor-Protected Code Integrity (HVCI), addresses kernel-level attacks that AppLocker cannot.
AppLocker vs WDAC: which one fits your environment
AppLocker and WDAC are both referenced in ASD guidance as tools for delivering application control, but they differ in coverage, licensing and deployment method [3].
AppLocker requires Windows Enterprise or Education editions. WDAC is available on all Windows 10 and Windows 11 editions including Pro. AppLocker deploys via Group Policy only. WDAC deploys via Group Policy or via Microsoft Intune, making it the natural choice for cloud-managed environments.
For ML1 and ML2, either tool can satisfy the ACSC requirements. For ML3, WDAC is required: AppLocker's user-mode-only enforcement and its lack of administrator account coverage do not meet the ML3 bar.
If your environment runs Windows 10 or 11 Pro and is managed via Intune, WDAC is the better path at every maturity level. If you manage devices via Group Policy only and are targeting ML1 or ML2, AppLocker remains a supported option per ASD guidance.
How to implement application control: the ASD's recommended approach
Start in Audit mode, not Enforce mode. Audit mode logs what would be blocked without blocking anything. Run it for two to four weeks to capture all legitimate business software your users run, including line-of-business applications that may lack obvious publisher certificates. Switching straight to Enforce without this step will block legitimate software and generate support calls.
Build your approved list using publisher certificate rules where possible. These survive software updates without requiring ruleset changes each time a vendor releases a patch. Use hash rules as a fallback for unsigned software, and path rules only as a last resort. Document why each path rule exists.
Switch to Enforce mode once the approved list is stable. Monitor blocked-execution events for the first two to four weeks and respond to any legitimate software caught by the rules. At ML2 and above, route all logs to your centralised logging platform before switching to Enforce [3].
Common application control failures in Australian SMBs
The most common failure is treating antivirus as application control. They are not interchangeable. Antivirus detects files that match known-malicious signatures. Application control restricts what is permitted to execute at all, regardless of whether a file appears in any signature database. Both controls are needed. They address different threat categories.
The second common failure is covering only program directories while leaving user-writable paths open. The ACSC's ML1 requirement targets user profiles and temporary folders specifically, which is where malware lands after delivery. A ruleset covering only C:\Program Files and C:\Windows leaves %TEMP%, %APPDATA% and the Downloads folder completely uncontrolled.
Ruleset drift is the third common failure. Organisations implement application control ahead of an assessment, then add software over the following months by temporarily disabling enforcement or creating broad path exceptions, without updating the approved list. By the time of the next assessment, the ruleset no longer meets what the maturity level requires. Use the Essential 8 maturity self-assessment periodically, not only when an audit is scheduled.
How CYBERWHITE tests and automates application control
CYBERWHITE's Essential 8 scanner tests your Microsoft 365 and Intune environment against the ACSC's application control requirements at your current target maturity level. It checks whether application control policies are deployed, whether the required paths and file types are in scope, and whether event logs are configured correctly and flowing to the right destination.
For organisations using Intune, CYBERWHITE's AutoFix engine can deploy WDAC policies via the Microsoft Graph API, with a preview of exactly what will change, an approval step before any change is applied, and a full rollback capability. The AutoFix feature page has a walkthrough of the snapshot-to-rollback sequence.
CYBERWHITE is a DSI Licensed Commercial Holder of the SMB1001 standard, so a single assessment maps your application control posture across both Essential 8 and SMB1001 requirements. See the Essential 8 compliance page for the full picture, or book a demo to walk through the scanner with your own environment.
Frequently asked questions
What is Essential 8 application control?
Essential 8 application control is the ACSC's requirement that organisations restrict which programs, scripts and software libraries are permitted to run on their systems. It operates on a default-deny basis: only approved applications execute. The ACSC includes it in the Essential Eight because it is one of the most effective controls against malware that requires execution to cause damage, including ransomware, trojans and keyloggers [1].
Does ML1 application control apply to servers?
Yes. Per the ACSC's Essential Eight Maturity Model, ML1 requires application control on both workstations and internet-facing servers. ML2 extends coverage to all servers, including internal ones. Organisations that only deploy application control to workstations will fail ML1 if internet-facing servers are not also covered.
What is the difference between application control and antivirus?
Antivirus detects files that match known-malicious signatures. Application control restricts which programs are permitted to execute at all, regardless of whether they appear in a signature database. The ACSC requires both: they serve different purposes. Application control stops unknown or novel malware from running; antivirus catches known threats that might reach an endpoint through other means.
Should I use AppLocker or WDAC for Essential 8?
For ML1 and ML2, both AppLocker and WDAC can satisfy the ACSC requirements. For ML3, the ACSC requires a tool that enforces at both user-mode and kernel-mode, which means WDAC. WDAC is also available on all Windows 10 and 11 editions including Pro, while AppLocker requires Enterprise or Education. If your environment is managed via Intune, WDAC is the better path at every maturity level [3].
What paths must application control cover at ML1?
At minimum, application control must cover user profiles and temporary folders used by the operating system, web browser and email client. In practice this means %TEMP%, %TMP%, %APPDATA%, the Downloads folder and the Desktop. These are the paths where malware lands after delivery, because they are writable by the standard logged-in user.
What are publisher certificate rules, and why does ML3 require them?
Publisher certificate rules tie the approved list to the code-signing certificate of a software vendor, rather than to a specific file path or file hash. They survive software updates without requiring ruleset changes on each patch cycle, and they cannot be bypassed by placing a malicious file at an approved directory path. The ACSC requires them at ML3 because path and hash rules are more easily circumvented by capable, targeted attackers [1].
How often does an application control ruleset need to be reviewed?
The ACSC requires annual validation of application control rulesets from ML2 upward, to confirm the rules still match the software in use and to remove stale entries that create unnecessary exposure or noise in blocked-execution logs. This is a formal requirement, not a best practice recommendation.
Does application control restrict administrator accounts?
AppLocker does not restrict administrator accounts by default, which is one of the reasons the ACSC mandates WDAC at ML3. WDAC applies to all users including local administrators. This is a meaningful gap at higher maturity levels, because compromised administrator accounts are a common lateral movement technique in targeted attacks.
Can application control work on macOS or Linux endpoints?
The ACSC's Essential Eight Maturity Model is written primarily for Windows environments. The maturity model references Windows-specific file types and tools. If your environment includes macOS or Linux endpoints, you need to apply equivalent controls using the tools available on those platforms. Your assessor will determine whether the controls in use satisfy the intent of the ACSC requirements for those systems.
Sources used in this post:
[1] ACSC Essential Eight Maturity Model, Australian Cyber Security Centre (cyber.gov.au), November 2023. [2] ACSC Essential Eight: Application Control, Australian Cyber Security Centre (cyber.gov.au). [3] ASD Guidance: Application Control Using Microsoft AppLocker, Australian Signals Directorate. [4] Microsoft Learn: Windows Defender Application Control, Microsoft.