TL;DR: Essential 8 application control is a mitigation strategy that stops unapproved code from running on workstations and servers. It is not antivirus. ML1 requires application control on workstations, blocking execution from user-writable paths. ML2 extends it to servers with centralised logging. ML3 requires a full allowlist, verified annually, with vendor-signed applications. On Microsoft 365, Windows Defender Application Control (WDAC) is the recommended implementation tool for ML2 and above.
What is Essential 8 application control?
Essential 8 application control is one of the eight mitigation strategies defined by the Australian Signals Directorate's Australian Cyber Security Centre (ACSC). The strategy operates on a straightforward principle: only code that is explicitly approved can run on a system. Any executable, script, installer, or software library not on the approved list is blocked before it executes.
The ACSC includes application control in the Essential Eight because it directly counters the execution phase of most attacks. Ransomware, credential stealers, and remote access tools all need code to run on the target machine. Application control removes that option for any code the organisation has not approved.
Application control sits alongside the other seven strategies: patch applications, patch operating systems, configure Microsoft Office macro settings, user application hardening, restrict administrative privileges, multi-factor authentication, and regular backups. For a full overview of how all eight fit together, see our Essential 8 compliance guide.
Application control is not antivirus
The most common misconception about Essential 8 application control among Australian SMBs is treating antivirus or endpoint detection software as a substitute. They are fundamentally different controls.
Antivirus works reactively: it detects code that matches known malicious signatures or behaviour patterns. Application control works proactively: it prevents execution of any code not on the approved list, regardless of whether that code is known or unknown.
A novel piece of ransomware with no antivirus signature can still be stopped by application control, because the executable is not on the allowlist. This is why the ACSC specifies application control as a separate, mandatory control. Antivirus and endpoint detection can complement it, but they do not replace it.
What ML1 requires for application control
At Maturity Level One, the ACSC requires application control to be implemented on workstations. The control must prevent execution in the locations where malware most commonly lands: user profiles and temporary folders used by the operating system, web browsers, and email clients.
Specifically, ML1 application control must block the execution of:
- Executables (.exe files)
- Software libraries (.dll files)
- Scripts, including PowerShell, VBScript, and batch files
- Installers (.msi files)
- Compiled HTML files (.chm)
- HTML applications (.hta)
- Control panel applets (.cpl)
These file types must be blocked in user-writable locations. Legitimate applications are typically installed to protected system paths, not user profiles or temp folders. Malware drops into user-writable paths because it runs without administrator rights.
On Windows, ML1 can be satisfied using AppLocker or WDAC. Most Microsoft 365 environments configure this through Microsoft Intune, deploying either AppLocker policies or WDAC policies to managed devices. This requires Windows 10 Pro or higher. For the full set of ML1 requirements across all eight strategies, see our Essential 8 ML1 checklist.
What ML2 adds to application control
ML2 raises the scope and the evidence bar for application control. Two changes apply beyond ML1.
First, application control must be extended to servers, not just workstations. Many SMBs that reach ML1 miss this step, leaving servers without the same execution controls applied to their desktops.
Second, ML2 requires centralised logging of application control events. The ACSC specifies that these logs must be protected from unauthorised modification and deletion, and analysed in a timely manner to identify events of interest. A control that blocks execution without logging what it blocked gives protection with no visibility. ML2 closes that gap.
The logging requirement is where AppLocker starts to show its limits. WDAC integrates with Microsoft's centralised logging stack, including Windows Event Forwarding, Microsoft Sentinel, and Microsoft Defender for Endpoint, more reliably than AppLocker. The ACSC's guidance recommends WDAC from ML2 onwards.
At ML2, application control needs to be paired with genuine log review, not collection alone. That typically means alert rules in a SIEM or regular manual review of blocked execution events by a responsible person or a managed service provider.
For context on what else changes between ML1 and ML2, see our Essential 8 maturity levels guide.
What ML3 requires from application control
ML3 extends application control from path-based blocking to full allowlisting. Instead of only blocking execution in user-writable locations, ML3 requires an organisation to maintain an explicit list of approved applications. Code not on that list cannot run anywhere on the system.
The ACSC specifies additional requirements at ML3:
- The allowlist must cover system-wide execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications, and control panel applets
- Permitted applications must be digitally signed by the vendor
- The allowlist must be validated at least once every 12 months
Full allowlisting is a significant operational undertaking. It means documenting every approved application in the environment, enforcing that list through WDAC policies, and maintaining it as software changes. For most Australian SMBs, ML3 application control is appropriate only when the contract or risk profile specifically demands it. Government entities with higher classification requirements are the typical ML3 target audience.
Implementing application control on Microsoft 365
For Australian SMBs running Microsoft 365 and Intune, the practical implementation path follows the maturity levels:
At ML1: Deploy AppLocker or WDAC policies via Intune to block execution in user profiles and temp folders. AppLocker policies can be deployed through Intune using custom OMA-URI configuration. This requires Windows 10 Pro or higher on all managed devices.
At ML2: Move to WDAC rather than AppLocker, and configure Microsoft Defender for Endpoint or Windows Event Forwarding to centralise application control logs. The WDAC Wizard tool from Microsoft helps author policies, which are then deployed via Intune. Enable audit mode first to identify blocked events before switching to enforce mode.
At ML3: Build a full application inventory, convert it to a WDAC allowlist, configure allow-by-signature rules for vendor-signed applications, and establish a 12-month review cycle. This level typically requires ongoing managed service support to maintain the allowlist as the software environment changes.
Microsoft Learn's Essential Eight application control article maps each maturity level to specific WDAC policy configurations. The ACSC's Implementing Application Control guide provides the authoritative requirements context alongside practical examples for Microsoft and non-Microsoft environments.
Four mistakes Australian SMBs make with application control
Mistake 1: Not covering all workstations. Application control only satisfies ML1 if it is implemented on every in-scope workstation. A policy deployed to 80% of devices leaves 20% of the attack surface open and breaks the control for the whole organisation.
Mistake 2: Staying on AppLocker at ML2. AppLocker can satisfy ML1, but it does not provide the centralised logging and event analysis capabilities that ML2 requires. Organisations that remain on AppLocker when moving to ML2 typically fail the logging and event analysis requirements during assessment.
Mistake 3: Forgetting servers. ML2 requires application control on servers as well as workstations. A server without application control in an ML2-claiming environment is a gap that an assessor will identify and record as a failure.
Mistake 4: Setting and forgetting. Application control policies that are never reviewed become stale. New software enters the environment, employees find workarounds, and blocked events go unreviewed. The ML2 logging requirement exists to catch this drift. If blocked events are not reviewed regularly, the control provides protection in name only.
How CYBERWHITE scans and remediates application control gaps
CYBERWHITE's Microsoft 365 compliance scanner reads your tenant configuration through the Microsoft Graph API and checks application control against the ACSC's maturity model requirements for ML1, ML2, and ML3. The scan is read-only and does not modify your environment.
Where gaps are identified, CYBERWHITE's AutoFix engine can deploy remediation actions, including application control policy deployment via Intune. CYBERWHITE offers 149 automated remediation actions across Essential 8 and SMB1001 combined. CYBERWHITE is a DSI Licensed Commercial Holder of the SMB1001 standard, which shares significant control overlap with Essential 8 application control requirements.
You can check your current application control maturity using the Essential 8 maturity self-assessment, or request a guided demo to see the scanner run against a test tenant.
Frequently asked questions
Is Essential 8 application control the same as antivirus?
No. Antivirus detects code that matches known malicious patterns. Application control prevents execution of any code not on an approved list, regardless of whether it is known to be malicious. A novel threat with no antivirus signature can still be stopped by application control. The ACSC specifies them as separate controls, and passing the Essential Eight requires both.
What tool should I use to implement application control on Windows?
For ML1, either AppLocker or WDAC on Windows 10 or 11 can satisfy the requirements. For ML2 and ML3, the ACSC and Microsoft Learn guidance both point to WDAC as the preferred tool. WDAC provides stronger logging integration with Microsoft Sentinel and Defender for Endpoint, and supports allowlisting by vendor signature at ML3. Most Microsoft 365 environments deploy WDAC policies through Microsoft Intune.
Does application control need to cover servers or just workstations?
At ML1, application control is required on workstations only. At ML2 and ML3, it must also be implemented on servers. Missing server coverage is one of the most common gaps identified during ML2 assessments of Australian SMBs.
How often does the application control allowlist need to be reviewed?
At ML3, the ACSC requires the allowlist to be validated at least once every 12 months. At ML1 and ML2, there is no formal review cadence requirement for the policy itself, but ML2 requires that application control event logs are reviewed in a timely manner to identify events of interest.
What is the difference between application control at ML1 and ML3?
ML1 blocks execution of specific file types in user-writable locations such as user profiles and temp folders. Code running from system paths is not restricted at ML1. ML3 requires a full organisational allowlist: no code runs unless explicitly approved, regardless of where it executes from. ML3 also requires permitted applications to be digitally signed by the vendor, and the allowlist to be validated at least annually.
Sources: ACSC Essential Eight Maturity Model (cyber.gov.au), ACSC Implementing Application Control (cyber.gov.au), Microsoft Learn Essential Eight Application Control (learn.microsoft.com/en-us/compliance/anz/e8-app-control).