Answer first
To meet Essential Eight Maturity Level 2 on a Microsoft 365 managed Windows fleet, deploy AppLocker (or Windows Defender Application Control) on workstations and internet-facing servers, configured to restrict execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set. Apply the Microsoft and Australian Signals Directorate (ASD) recommended block rules. Move from audit mode to managed enforcement in waves over 14 to 16 weeks. The free Essential Eight Maturity Assessment will tell you whether this is your current gating control.
1. What ML2 requires for application control
According to the ASD Essential Eight Maturity Model (Australian Cyber Security Centre — Essential Eight maturity model, accessed 16 June 2026) (current revision, published at cyber.gov.au), at Maturity Level 2 application control is implemented on workstations and internet-facing servers and is configured to restrict the execution of executables, software libraries (DLLs), scripts (Windows Script Host, PowerShell, batch files), installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set. Microsoft's recommended block rules and the ASD's recommended block rules are implemented to prevent the execution of vulnerable Microsoft-signed binaries that attackers exploit to bypass application control.
The control is not satisfied by signing-only restrictions, by Smart App Control, or by Microsoft Defender Application Guard in isolation. ML2 requires an enforced allowlist policy, sampled from a live endpoint, with the Microsoft and ASD recommended block rules applied. Audit mode is acceptable for ML1 visibility but does not satisfy ML2.
Where this fits: application control is one of eight controls in the broader ML2 programme. The pillar guide Essential Eight Maturity Level 2 — the 2026 evidence pack covers all eight controls and the remediation sequencing this rollout slots into.
Supporting publication: Australian Cyber Security Centre — Implementing Application Control (cyber.gov.au, current revision).
2. Choosing between AppLocker and Windows Defender Application Control
Microsoft 365 managed Windows fleets have two built-in application control technologies. According to Microsoft Learn (learn.microsoft.com, current revision), both are supported for enterprise use, but Microsoft's published direction is to invest in Windows Defender Application Control for new deployments.
AppLocker is the older, simpler technology. It enforces in user mode, is managed through Group Policy or Intune, and is well understood by Windows administrators. Compatibility with line-of-business applications is generally good. AppLocker can be configured per-rule-collection for executables, Windows Installer files, scripts, packaged apps and DLLs.
Windows Defender Application Control (WDAC) enforces below the user mode boundary, resists tampering by users with administrative rights, and supports policy signing for stronger tamper resistance. WDAC supports the Intelligent Security Graph (ISG) integration for known-good binary reputation, supports Managed Installer to allowlist software installed through approved deployment tools, and can be deployed through Intune, MECM, or signed CIP policy files.
The pragmatic path. Most Australian mid-market organisations should deploy AppLocker first to reach Maturity Level 2, then migrate to Windows Defender Application Control during the move toward Maturity Level 3. The AppLocker baseline informs the WDAC policy, materially reducing the WDAC rollout effort.
3. Stage 1 — Discovery and baselining (weeks 1 to 6)
Application control fails when it blocks software the business legitimately needs. Discovery is the work that prevents that failure.
Software inventory. Use Microsoft Defender for Endpoint Software inventory (security.microsoft.com → Vulnerability Management → Software inventory) or Microsoft Intune Discovered apps to build a list of every application across the fleet, with installation count and publisher. Cross-reference against the application register the patch management programme maintains for Control 2.
Publisher baseline. From the software inventory, extract the list of code-signing publishers. Microsoft, Adobe, Google, Mozilla and a handful of approved Australian vendors typically account for the large majority of the binary footprint. Document each approved publisher with the certificate thumbprint, business owner, and expiry date.
File hash exceptions. For unsigned or in-house line-of-business applications, plan to allowlist by file hash. Document the hash, the application, the business owner, the version, and the review cadence. Hash-based rules require update whenever the binary changes — schedule the review cadence to align with the application's patch frequency.
Path exceptions. Avoid path-based rules on user-writable paths (under C:\Users\, %APPDATA%). Restrict path rules to administrator-protected paths only — typically C:\Program Files\ and C:\Program Files (x86)\. Path-based rules on user-writable directories are a well-documented application-control bypass technique and disqualify the control at ML2.
4. Stage 2 — Audit mode rollout (weeks 7 to 10)
Audit mode applies the policy but logs denials rather than blocking execution. It is the safest way to discover what your draft policy is going to break before it breaks production.
Author the AppLocker policy. From a representative reference workstation, generate baseline rules using Get-AppLockerFileInformation -Directory 'C:\Program Files\' -Recurse -FileType Exe,Dll,Script | New-AppLockerPolicy -RuleType Publisher,Hash -User Everyone -RuleNamePrefix 'Baseline'. Inspect the output XML and remove anything that should not be allowlisted.
Apply the Microsoft recommended block rules. Microsoft publishes a Microsoft recommended block rules list (Microsoft Learn, current revision) that blocks vulnerable Microsoft-signed binaries used in living-off-the-land attacks. Merge the published block rules into your AppLocker policy as deny rules with priority above the publisher allow rules.
Apply the ASD recommended block rules. ACSC Implementing Application Control (cyber.gov.au, current revision) references the ASD recommended block rules. Apply these alongside the Microsoft block rules.
Deploy in audit mode through Intune. In the Microsoft Intune admin centre, navigate to Endpoint security → Attack surface reduction → Create policy → Windows → App and browser isolation → AppLocker. Set rule enforcement to Audit only. Assign to a small pilot group first, then expand to the full fleet.
Monitor the AppLocker event log. AppLocker events are logged under Applications and Services Logs → Microsoft → Windows → AppLocker. Channels: EXE and DLL (Event IDs 8002 allowed, 8003 audited, 8004 blocked), MSI and Script (8005, 8006, 8007). Forward these to Microsoft Sentinel or Microsoft Defender for Endpoint advanced hunting for centralised review.
Refine the policy. Review audit events weekly. For each audited denial, decide: add an allowlist rule (legitimate software), leave as an enforcement-time denial (unwanted software), or quarantine and investigate (unknown software). Loop until audit events drop to a manageable steady-state — typically 4 to 6 weeks.
5. Stage 3 — Managed enforcement rollout (weeks 11 to 14)
When audit-mode noise has dropped to a manageable steady-state, advance to enforcement in waves with a rollback path.
Wave structure.
- Wave 1 (week 11): IT and security team workstations. These users can self-troubleshoot and provide rapid feedback.
- Wave 2 (week 12): Internet-facing servers. These have a narrower software footprint than workstations and are also the highest-risk surface, so it is appropriate to prioritise them for enforcement.
- Wave 3 (week 13): Business-as-usual workstations in the first business unit, with engaged executive sponsor and active service desk awareness.
- Wave 4 (week 14): Remaining workstation fleet.
Switch the Intune AppLocker policy from Audit to Enforce. In the Intune AppLocker policy, change the rule enforcement to Enforce rules. Re-deploy and confirm the policy applies on a sampled endpoint with Get-AppLockerPolicy -Effective -Xml.
Rollback path. Maintain an Intune AppLocker policy in audit-only mode applied to a Break glass group. Move an endpoint to the break-glass group via Entra ID group membership change if enforcement causes a business impact while the issue is investigated. Document the break-glass procedure with named approvers.
Service desk readiness. Application control denials present to end users as silent failure — the application closes or never launches. Pre-brief the service desk with a triage script: capture the endpoint name, the application name, the AppLocker event ID, decide allow-and-add-rule or deny-and-investigate, and log the decision in the policy change record.
6. Stage 4 — Evidence collection (week 15 onward)
ML2 requires evidence sampled from live systems, not just policy documents. Collect the following:
- AppLocker policy export. From the Intune admin centre, export the AppLocker policy XML. Store with a versioned filename.
- Effective policy from a sampled workstation. On a representative endpoint, run
Get-AppLockerPolicy -Effective -Xml | Out-File -FilePath C:\AuditEvidence\applocker-effective-policy-WS01-20260524.xml. Repeat for at least one workstation per location and one internet-facing server. - Denial event log extract for the prior 30 days. From Microsoft Sentinel or the Defender for Endpoint advanced hunting console, export AppLocker denial events for the prior 30 days. The export demonstrates that enforcement is actively running.
- Microsoft and ASD recommended block-rule evidence. Export the block-rule policy fragment with version date.
- Allowlist of approved publishers. Export the publisher list with certificate thumbprints and business owner.
The companion how-to ML2 evidence templates per Essential Eight control provides the full per-control artefact index.
7. Migrating to Windows Defender Application Control
Once AppLocker enforcement is stable and the evidence pack is in place, migrate to Windows Defender Application Control as the strategic platform — particularly for organisations targeting Maturity Level 3 in the next 12 to 18 months.
Author the WDAC policy. Use the Microsoft WDAC Wizard (downloadable from learn.microsoft.com) or the New-CIPolicy PowerShell cmdlet to author a base policy from a reference workstation. The AppLocker baseline is the input — the publisher and hash rules translate directly into WDAC equivalents.
Enable Intelligent Security Graph integration. WDAC supports automatic allowlisting of binaries with known-good reputation from the Microsoft Intelligent Security Graph (ISG). For most Australian organisations this materially reduces the maintenance burden on the allowlist while preserving ML2 enforcement.
Enable Managed Installer. Designate Microsoft Intune or MECM as the Managed Installer in the WDAC policy. Software deployed through the managed installer is automatically allowlisted, removing the need to author per-application rules for software that comes through the central deployment pipeline.
Sign the policy. For tamper resistance, sign the WDAC policy with a code-signing certificate. A signed WDAC policy cannot be modified or removed without the signing certificate, even by users with administrative rights. This is one of the WDAC capabilities that AppLocker cannot provide and is part of the Maturity Level 3 expectation.
Deploy through Intune. Microsoft Intune supports WDAC policy deployment as a custom OMA-URI configuration or through the Endpoint security → Attack surface reduction policy types. Deploy in audit mode first, repeat the audit-to-enforce cycle, then decommission the AppLocker policy.
8. Common pitfalls
Allowlisting user-writable paths. Path rules on %APPDATA%, %LOCALAPPDATA% or C:\Users\ paths defeat application control because users can write malware to those paths. Restrict path rules to administrator-protected directories.
Excluding domain administrators. Some legacy guidance suggests excluding administrators from AppLocker enforcement to ease troubleshooting. According to the ASD Essential Eight Maturity Model (current revision), at Maturity Level 2 application control applies to all users. The Microsoft and ASD recommended block rules exist specifically because attackers compromise privileged accounts; excluding administrators undermines the control.
Forgetting servers. ML2 explicitly requires application control on internet-facing servers. Many AppLocker rollouts focus on workstations and leave servers out of scope. The internet-facing server fleet is the highest-priority enforcement target — and is usually smaller and easier to baseline than the workstation fleet.
Not refreshing the allowlist when applications update. Hash-based rules require maintenance whenever the binary changes. Document the refresh cadence per application and link it to the patch management programme so the patch review cycle triggers the allowlist refresh.
9. When to call for support
If the application control rollout uncovers a large unmanaged-software footprint, or if line-of-business application compatibility issues materially slow the rollout, that is a signal that the broader endpoint management baseline needs uplift before application control can stabilise. The Essential Eight is not a checklist of standalone controls — it is a layered programme, and Control 1 depends on a managed endpoint baseline being in place.
Score your current Essential Eight posture against ML2 in five minutes with the free Essential Eight Maturity Assessment. If application control is your gating control, the assessment will say so — and the Essential Eight Assessment service can provide practitioner-led rollout support.
Sources cited
- Australian Signals Directorate — Essential Eight Maturity Model (current revision, cyber.gov.au, checked 24 May 2026)
- Australian Cyber Security Centre — Implementing Application Control (cyber.gov.au, current revision)
- Australian Cyber Security Centre — Information Security Manual (ACSC — Information Security Manual, accessed 16 June 2026) (November 2025 release, cyber.gov.au)
- Microsoft Learn — Windows Defender Application Control (learn.microsoft.com, checked 24 May 2026)
- Microsoft Learn — Microsoft recommended block rules (learn.microsoft.com, checked 24 May 2026)
- Microsoft Learn — AppLocker overview (learn.microsoft.com, checked 24 May 2026)
- Microsoft Learn — Microsoft 365 and the ACSC Essential Eight (Microsoft Learn — ACSC Essential Eight (ANZ) overview, accessed 16 June 2026) (learn.microsoft.com, checked 24 May 2026)
Sources referenced in this article: ASD Essential Eight Maturity Model, ACSC Information Security Manual, Microsoft Learn — Microsoft 365 and the ACSC Essential Eight, ACSC Implementing Application Control, Microsoft Learn — Windows Defender Application Control, Microsoft Learn — Microsoft recommended block rules, Microsoft Learn — AppLocker overview.
