TL;DR: Essential 8 application control is an allow-listing approach that blocks unauthorized code from running on your systems. At ML1 it covers workstations, focusing on user profile and temporary folders. ML2 extends it to internet-facing servers and all file locations, and requires Windows Defender Application Control (WDAC) rather than AppLocker. ML3 adds non-internet-facing servers and driver-level restrictions.
What is Essential 8 application control?
Essential 8 application control prevents unauthorized code from executing on your systems by allowing only approved applications to run. Unlike antivirus, which identifies known malicious signatures, allow-listing denies everything not on an approved list, including unknown or novel malware.
The ACSC includes application control among the Essential Eight strategies because it directly blocks malware execution, even when a payload is new or unknown. The Australian Signals Directorate places it alongside patch management, MFA, and macro configuration as one of the four most effective mitigation strategies in its Strategies to Mitigate Cyber Security Incidents.
Application control does not replace antivirus. The ACSC and Microsoft both treat them as complementary layers: application control stops unauthorized execution, antivirus identifies known-bad files. Running them together provides a stronger defence-in-depth posture.
What file types must application control cover?
ISM control ISM-1657, which applies at all three maturity levels, requires application control to restrict executables, software libraries, scripts, installers, compiled HTML, HTML applications, and control panel applets to an organization-approved set. At ML3, ISM-1658 extends that list to include drivers.
This scope matters in practice. Many organizations configure restrictions for executable (.exe) files and overlook scripts. A PowerShell script or VBScript file running from a user temp folder can cause as much damage as a traditional executable. From ML1 upward, the ACSC requires script execution to be controlled alongside executables. For WDAC users, the Script Enforcement policy rule must be enabled, not disabled, to satisfy ISM-1657.
ML1 requirements for application control
At ML1, application control must be implemented on workstations (ISM-0843) and applied to user profiles and temporary folders (ISM-1870). These are the paths most commonly exploited by commodity malware: the AppData directories where downloaded files land, and the temp folders used by browsers, email clients, and the operating system.
Microsoft's guidance for ML1 recommends blocking, at a minimum:
C:\Windows\Temp\%USERPROFILE%\AppData\Local\(with an exception for the WindowsApps subfolder)%USERPROFILE%\AppData\Roaming\
Microsoft AppLocker can satisfy the ACSC's ML1 requirements. AppLocker supports path, publisher, and hash rules, and it can be deployed through Group Policy or Intune. It is a practical starting point for organizations new to application control that are managing Windows devices through existing tooling.
AppLocker alone is not sufficient for ML2 or ML3.
ML2 requirements for application control
ML2 significantly expands the scope of Essential 8 application control. In addition to everything required at ML1, application control must be extended to internet-facing servers (ISM-1490) and must now cover all file system locations on every managed device, not limited to user profiles and temp folders (ISM-1871). ML2 also adds four further requirements:
- Microsoft's recommended application blocklist must be implemented (ISM-1544)
- All allowed and blocked execution events must be centrally logged (ISM-1660)
- Event logs must be protected from unauthorized modification and deletion (ISM-1815)
- Application control rulesets must be validated at least annually (ISM-1582)
Windows Defender Application Control (WDAC) is required from ML2 onward. Unlike AppLocker, which operates in user mode only, WDAC enforces application control system-wide and supports the kernel-mode enforcement that ISM-1871 demands.
The shift to WDAC is the most common point where organizations underestimate the work required to reach ML2. If your ML1 implementation relies on AppLocker, you need to deploy WDAC before you can satisfy the ML2 requirements.
ML3 requirements for application control
ML3 adds three requirements on top of everything required at ML2. First, application control must be extended to non-internet-facing servers (ISM-1656). Second, driver execution must be restricted to an organization-approved set (ISM-1658). Third, Microsoft's vulnerable driver blocklist must be implemented (ISM-1659).
Driver-level control (ISM-1658) is the most technically demanding addition. WDAC enforces kernel-mode code integrity through Hypervisor-Protected Code Integrity (HVCI), which is enabled by default on Windows 11 2022H2 and later. On older hardware and server operating systems, HVCI requires compatibility verification before enforcement can be applied safely.
ML3 also requires timely analysis of application control event logs from workstations (ISM-0109), internet-facing servers (ISM-1906), and non-internet-facing servers (ISM-1907) to detect security events.
WDAC vs AppLocker: which tool do you need?
For ML1, both AppLocker and WDAC meet the ACSC's requirements. Microsoft's recommendation is WDAC for all maturity levels because it receives ongoing feature development while AppLocker receives security fixes only. That said, Microsoft acknowledges that AppLocker is simpler to deploy initially, making it a reasonable ML1 starting point for organizations with limited implementation resources.
From ML2 onward, WDAC is required. ISM-1871 requires application control across all file system locations, which AppLocker cannot satisfy.
WDAC was introduced with Windows 10. It applies to all users on a device, including administrators, and can be deployed through Microsoft Intune via custom OMA-URI configuration profiles, through Group Policy, or through Configuration Manager. For organizations already using Intune for device management, this is the recommended deployment path.
Organizations running AppLocker can keep it running alongside WDAC. Microsoft supports using AppLocker to complement WDAC for specific user-mode scenarios while WDAC handles system-wide enforcement.
Which rule type should you use?
The ACSC accepts three rule types: cryptographic hash rules, publisher certification rules, and path rules. Publisher rules are the most practical choice for most Australian organizations.
Hash rules are precise but require updating every time an application is patched, since a new version produces a new hash. At scale, this creates maintenance pressure that leads some organizations to delay patches to avoid breaking their allow-list, which directly undermines the Essential 8 patching strategy.
Publisher rules authorize code by its signing certificate rather than by file version. An approved publisher's application is permitted regardless of version number, making patching and updates straightforward to manage.
Path rules are flexible but carry a specific risk in user-controlled directories. The ACSC and Microsoft are both explicit on this point: path rules must not be used for user profile or temp folder locations (ISM-1870) because users have write permissions in those directories and could place unauthorized code at a permitted path. Path rules are acceptable only where NTFS permissions prevent users from modifying the folder contents.
Microsoft's recommendation is publisher rules as the primary approach, with hash rules as a fallback for unsigned applications.
Three mistakes Australian SMBs make with application control
Covering executables but not scripts. ISM-1657 applies from ML1 and requires coverage of scripts, compiled HTML, and HTML applications alongside executables. Many organizations configure their application control tool for .exe files and nothing else. For WDAC, the Script Enforcement policy option must be enabled in your policy. If Disable Script Enforcement is active, PowerShell and VBScript execute without restriction, bypassing your allow-list entirely.
Leaving WDAC in permanent audit mode. WDAC's audit mode logs what would be blocked without preventing execution. Running in audit mode first is the correct approach: deploy the audit policy, review blocked-execution events, add legitimate applications to your policy, then switch to enforce mode. The mistake is treating audit mode as a destination rather than a step. A WDAC policy that never moves to enforce mode provides no protection and does not satisfy the ACSC's requirements.
Assuming AppLocker carries through to ML2. Organizations that reached ML1 with AppLocker sometimes assume ML2 is a minor extension of that work. It is not. ISM-1871 requires application control across all file system locations, which demands WDAC. Discovering this constraint mid-assessment means re-deploying application control from scratch, typically adding months to the project timeline. Plan for WDAC from the outset if ML2 is your target.
How to assess your current application control posture
Mapping your current configuration to the specific ISM controls is the most reliable way to identify gaps before your assessment. The controls to check are ISM-0843, ISM-1490, ISM-1656, ISM-1657, ISM-1658, ISM-1870, and ISM-1871, each scoped to the right system types and coverage levels for your target maturity level.
CYBERWHITE's Essential 8 compliance platform scans your Microsoft 365 environment and maps your current configuration to these ISM controls across all three maturity levels. Where gaps exist, the platform surfaces specific remediation steps. For controls addressable through Microsoft Graph and Intune, AutoFix can deploy WDAC policies for your approval before anything is pushed to devices.
Use the Essential 8 maturity assessment to map your posture across all eight strategies. If you are preparing for ML1 specifically, the Essential 8 ML1 checklist covers application control alongside the other seven controls. For the full picture of how all eight strategies and their requirements change across maturity levels, see Essential 8 maturity levels explained.
To see how automated scanning and guided remediation work together in a live environment, book a demo.
Frequently asked questions
What does Essential 8 application control require at ML1?
At ML1, application control must be implemented on workstations and applied to user profiles and temporary folders. It must restrict executables, software libraries, scripts, installers, compiled HTML, HTML applications, and control panel applets to an organization-approved set (ISM-0843, ISM-1657, ISM-1870). Microsoft AppLocker can satisfy these ML1 requirements.
Does ML2 require WDAC or is AppLocker sufficient?
ML2 requires Windows Defender Application Control. ISM-1871 requires application control across all file system locations on managed devices, not limited to user profiles and temp folders. AppLocker operates in user mode only and cannot satisfy ISM-1871. WDAC must be the primary enforcement tool from ML2 onward.
What is the difference between audit mode and enforce mode in WDAC?
In audit mode, WDAC generates event logs for executions that would be blocked but does not prevent them from running. In enforce mode, unauthorized applications are actively blocked. Audit mode is a deployment step used to identify legitimate applications that need to be added to the allow-list before enforcement begins. Enforce mode is required to satisfy the ACSC's application control requirements.
Can path rules satisfy the ACSC's application control requirements?
Path rules are accepted by the ACSC under specific conditions. File system permissions must prevent users from modifying the contents of any path used in a rule. For user profile and temp folder locations covered by ISM-1870, path rules are not recommended because users have write access in those directories. Publisher rules or hash rules are the safer choice for those locations.
How does Essential 8 application control relate to SMB1001?
SMB1001, the DSI standard for Australian small and medium businesses, includes controls that align with Essential 8 application control. CYBERWHITE, as a DSI Licensed Commercial Holder of SMB1001, assesses both frameworks in the same platform, so organizations can map their application control posture across both standards in one assessment. See the SMB1001 overview for how the two frameworks compare.
Sources
- Australian Cyber Security Centre (ACSC), Essential Eight Maturity Model, cyber.gov.au (ISM March 2025 controls referenced: ISM-0843, ISM-1490, ISM-1544, ISM-1582, ISM-1656, ISM-1657, ISM-1658, ISM-1659, ISM-1660, ISM-1815, ISM-1870, ISM-1871)
- Microsoft Learn, "Essential Eight application control," learn.microsoft.com/en-us/compliance/anz/e8-app-control, updated May 2026
- Australian Signals Directorate (ASD), Strategies to Mitigate Cyber Security Incidents, cyber.gov.au