TL;DR: Essential 8 application control restricts which executables, scripts, installers and libraries can run on your systems by using a strict allowlist. At Maturity Level 1 (ML1), it applies to user-writable locations on workstations. At ML2 it extends to internet-facing servers with event logging. At ML3 it covers all servers, and the ASD recommends Windows Defender Application Control (WDAC) as the implementation technology. The most common failure is confusing antivirus with application control: they address different problems and both are required.
What is application control under the Essential 8?
Application control is one of the eight mitigation strategies published by the Australian Signals Directorate (ASD) via the Australian Cyber Security Centre (ACSC) at cyber.gov.au. The ACSC lists it among the controls with the highest return on investment for reducing the impact of cyber incidents.
The principle is an allowlist: only software that has been explicitly approved can execute on a system. Everything else is blocked, regardless of whether a signature exists for it. This makes the control effective against novel malware, fileless attacks and unsigned scripts, which antivirus and endpoint detection tools are not designed to stop by themselves.
Antivirus and application control are distinct controls under the ACSC model. Antivirus identifies known-bad files and blocks them. Application control permits only known-good software. A system with antivirus but no application control does not satisfy the application control requirement at any maturity level. Understanding this is the starting point for any accurate Essential 8 assessment.
For how application control fits alongside the other seven mitigation strategies, our Essential 8 compliance guide walks through the complete framework and what each strategy is designed to prevent.
What file types must application control cover?
The ACSC model is explicit about scope. Application control is not limited to .exe files. According to the ASD's Essential Eight Maturity Model, the following file types must all be restricted to an approved set:
- Executables (.exe, .com)
- Software libraries (.dll, .ocx)
- Scripts (PowerShell, batch, Windows Script Host, JavaScript)
- Installers (.msi, .msp)
- Compiled HTML (.chm)
- HTML applications (.hta)
- Control panel applets (.cpl)
- Drivers
This breadth is intentional. Modern attack chains rarely rely on .exe files dropped directly by the attacker. Scripts, HTML applications and software libraries are the delivery mechanism for the majority of commodity malware that ML1 is designed to stop. A policy that only targets executables leaves most of that attack surface open.
Essential 8 application control at ML1: workstations and user-writable locations
At ML1, the ACSC requires application control on workstations. The focus is on locations where users can write files, because these are the locations where malware most commonly lands after being delivered via email or browser download.
Per the ACSC, application control must be applied to user profiles and temporary folders used by the operating system, web browsers and email clients. On a Windows workstation, the locations that must be covered include:
- User profile directories (%USERPROFILE%)
- Temporary folders (%TEMP%, %TMP%)
- Downloads folders
- Temporary locations used by email clients and web browsers
A file dropped into these locations can be downloaded, but it cannot be executed without an administrator first approving it.
The ACSC permits three types of rules at ML1: publisher certificate rules, path rules and hash rules. Publisher rules trust software signed by a specific publisher certificate, which makes them practical for managing commercial off-the-shelf software because the rule does not need updating each time the vendor releases a patch. Hash rules identify a specific file by its cryptographic hash and are the most precise option, but require updating whenever a file changes. Path rules trust software at a specific folder path and are the weakest option: if the approved path is also writable by users, the rule can be bypassed by placing malicious files there.
For a full control-by-control walkthrough of what passes ML1 across all eight strategies, see our Essential 8 ML1 checklist.
Essential 8 application control at ML2: internet-facing servers and event logging
ML2 adds two requirements on top of ML1. First, application control extends from workstations to internet-facing servers. A web application, email gateway or remote access system without application control fails at ML2, regardless of how comprehensively workstations are covered.
Second, the ACSC requires that application control events are logged. Logs must capture allowed and blocked executions. At ML2, those logs must be reviewed for signs of compromise, and they must be protected from unauthorised modification and deletion. An organisation whose policies are correctly configured but whose logs are not being collected or reviewed does not satisfy the ML2 requirements.
This logging requirement is frequently underestimated. It is not sufficient to have the application control policy active. Evidence that logs exist, flow to a central location and are reviewed is what an assessor checks at ML2. Our Essential 8 maturity levels guide covers what changes at each level across all eight strategies.
Essential 8 application control at ML3: all servers and WDAC
ML3 extends the server scope from internet-facing to all servers. An internal file server, domain controller, database server or line-of-business application server all fall within scope at ML3.
The ASD's current Essential Eight Maturity Model also specifies that at ML3, application control should be implemented using Microsoft's recommended application control solution. Microsoft's recommended solution is Windows Defender Application Control (WDAC). For organisations targeting ML3 in a Windows environment, this means evaluating whether existing tooling, which may be AppLocker or a third-party product, aligns with the ASD expectation.
WDAC vs AppLocker: which one satisfies Essential 8?
Both WDAC and AppLocker can deliver application control for Essential 8, but they operate differently and carry different security boundaries.
AppLocker is the older technology. It is enforced in user mode, meaning it operates at the application layer rather than the operating system kernel. A user with local administrator rights can potentially bypass AppLocker by modifying policies or using alternate execution methods. AppLocker is also not available on Windows Home editions.
WDAC is enforced at the kernel level, making it significantly harder to circumvent even with administrator rights. Microsoft Learn's Essential Eight application control documentation identifies WDAC as the recommended solution for Essential 8 compliance. WDAC policies can be deployed in audit mode to log what is currently executing before switching to enforce mode, which makes staged rollout practical without risking disruption to business operations.
For most Australian SMBs running Windows 10/11 or Windows Server 2016 and later, WDAC is the right choice. AppLocker may be used to satisfy ML1 and ML2 requirements, but WDAC aligns with ASD guidance and is the safer option from an assessment standpoint at all levels.
How to implement application control with Microsoft Intune
For organisations running Microsoft 365, Microsoft Intune is the primary deployment mechanism for WDAC policies. Intune supports WDAC through the App Control for Business feature under Endpoint Security.
The recommended deployment sequence is:
- Create a WDAC policy in audit mode to capture what software is currently running in your environment
- Review audit logs to build an allowlist of legitimate publishers, applications and paths
- Convert the policy to enforce mode once the allowlist is validated against the current software inventory
- Deploy via Intune to targeted device groups, starting with a pilot group of workstations before rolling to all devices
- Extend to internet-facing servers in a separate controlled deployment step (required for ML2)
- Monitor App Control events through Microsoft Intune and Microsoft Defender XDR
Microsoft Learn's Essential Eight application control guidance includes the specific Intune policy configuration steps and describes how to create base policies using the WDAC Policy Wizard, along with supplemental policies for line-of-business applications that need per-org rules.
Skipping the audit phase is the single biggest mistake in Intune-based WDAC deployments. Moving directly to enforce mode blocks any software not already in the policy, including legitimate tools that were never formally documented.
What trips Australian SMBs up with application control
Several patterns appear repeatedly in Essential 8 assessments of Australian small and medium businesses:
Treating antivirus as application control. This is the most common failure at ML1. The ACSC model tests antivirus and application control as separate controls. A mature EDR product does not substitute for an allowlist-based application control policy.
Path rules pointing to user-writable folders. A path rule that permits execution from %APPDATA%, a shared drive or a Downloads subfolder defeats the purpose of application control. Attackers who can write to an allowed path can execute from it. The ACSC's implementing application control guidance specifically warns against this pattern.
Covering executables but not scripts. A policy that blocks .exe files but leaves PowerShell, Windows Script Host and HTML applications unrestricted still allows most commodity attack chains to run. The file type scope in the ACSC model is broad because modern malware delivery avoids traditional executables.
No coverage on internet-facing servers. Workstation-only coverage satisfies ML1 but not ML2. Remote desktop servers, cloud-hosted web applications and email gateways all fall within scope at ML2. Organisations running Azure-hosted workloads often miss this.
Application control logs not reviewed. The logging and monitoring component at ML2 is a control in its own right. Policies correctly deployed but with no log review process do not satisfy ML2 requirements.
How application control maps to SMB1001
For Australian businesses pursuing both Essential 8 and SMB1001, application control under Essential 8 overlaps with malicious code prevention controls within SMB1001. CYBERWHITE is a DSI Licensed Commercial Holder of the SMB1001 standard (ABN 31 598 198 475), and the platform assesses both frameworks in a single assessment run.
The practical benefit is that the application control work done for Essential 8 ML1 directly contributes to the relevant SMB1001 controls, reducing the effort needed to address both frameworks separately. For more on the SMB1001 tier structure and how it relates to Essential 8, our SMB1001 compliance overview covers the path from Bronze through to Gold.
How CYBERWHITE assesses and remediates application control gaps
CYBERWHITE's Essential 8 scanner reads your Microsoft 365 and Intune configuration and assesses your current application control posture against ML1, ML2 and ML3. It checks whether a WDAC or AppLocker policy exists, whether it covers the required file types and user-writable locations, and whether event logging is active and feeding into a monitoring workflow.
Where gaps are identified, CYBERWHITE's AutoFix engine can deploy WDAC policies through Microsoft Graph and Intune, with an approval step before any policy is applied and rollback available if needed. CARS adaptive risk scoring prioritises the gaps that carry the highest risk for your specific environment, rather than presenting a flat checklist of every control.
Check your current application control posture with our free Essential 8 maturity self-assessment, or see pricing for assessment and AutoFix plan details.
Frequently asked questions
What is Essential 8 application control?
Essential 8 application control is an allowlist-based mitigation strategy defined by the ACSC that restricts which executables, scripts, installers, software libraries and other code can run on your systems. Only software on the approved list can execute. Everything else is blocked, including novel malware with no antivirus signature.
What file types does Essential 8 application control cover?
Per the ASD's Essential Eight Maturity Model, application control must cover executables, software libraries (.dll, .ocx), scripts (PowerShell, batch, WSH, JavaScript), installers (.msi, .msp), compiled HTML (.chm), HTML applications (.hta), control panel applets (.cpl) and drivers. Blocking .exe files alone does not satisfy the requirement.
What locations does application control need to cover at ML1?
At ML1, the ACSC requires application control on workstations targeting user-writable locations: user profile directories (%USERPROFILE%), temporary folders (%TEMP%, %TMP%), Downloads folders, and temporary locations used by web browsers and email clients. These are the locations where malware most commonly arrives.
Is antivirus the same as application control?
No. Antivirus detects and blocks known-malicious files based on signatures. Application control works on an allowlist: only pre-approved software can execute, regardless of whether it is known to be malicious or not. The ACSC model tests these as separate controls. Antivirus does not satisfy the application control requirement.
Does ML2 require application control on servers?
Yes. At ML2, the ACSC extends application control to internet-facing servers, in addition to workstations. ML2 also requires that application control event logs are generated, protected from unauthorised modification and reviewed for signs of compromise.
Does ML3 require WDAC specifically?
The ASD's current Essential Eight Maturity Model specifies that ML3 requires Microsoft's recommended application control solution, which is Windows Defender Application Control (WDAC). AppLocker may satisfy ML1 and ML2 requirements, but WDAC is the ASD-recommended tool for ML3 in a Windows environment.
What is the difference between WDAC and AppLocker?
WDAC is enforced at the kernel level, making it significantly harder to bypass even for a user with local administrator rights. AppLocker is enforced in user mode and can be circumvented by a local administrator. Microsoft Learn's Essential Eight application control documentation identifies WDAC as the preferred implementation for Essential 8 compliance.
Can Microsoft Intune deploy WDAC for Essential 8?
Yes. Microsoft Intune supports WDAC deployment through the App Control for Business feature under Endpoint Security. The recommended approach is to start in audit mode to capture the current software baseline, then move to enforce mode after validating the allowlist. This avoids blocking legitimate software unexpectedly.
What are the most common application control failures in Australian SMBs?
The most frequent failures are: treating antivirus as a substitute for application control; using path-based rules that point to user-writable locations; covering only .exe files and missing scripts and software libraries; not extending coverage to internet-facing servers (an ML2 gap); and not reviewing application control event logs, which is a requirement in its own right at ML2.
How does Essential 8 application control relate to SMB1001?
Application control under Essential 8 maps to malicious code prevention controls within the SMB1001 standard. CYBERWHITE, as a DSI Licensed Commercial Holder of SMB1001, assesses both frameworks simultaneously, so the work done to satisfy Essential 8 application control requirements directly contributes to the corresponding SMB1001 controls.
Which rule type is most secure: publisher, path or hash?
Hash rules are the most precise, identifying a specific file by its cryptographic hash. Publisher certificate rules are the most practical for commercial software because they do not require updating with each vendor release. Path rules are the weakest because if the permitted path is also writable by users, the rule can be bypassed. The ACSC recommends avoiding path rules in user-writable locations.