TL;DR: Essential 8 maturity level 2 requires every control from ML1 plus tighter, broader versions of all eight strategies. The three largest additions are phishing-resistant MFA for all users accessing internet-facing services, application control extended to internet-facing servers, and centralised collection and protection of event logs. Most Australian SMBs already at ML1 take 6 to 12 months to reach ML2, with the MFA upgrade and logging infrastructure the longest workstreams.
This guide covers ML2 in depth. If you are still deciding which level you need, start with Essential 8 maturity levels explained: ML1 vs ML2 vs ML3 for how the three levels compare.
What is Essential 8 maturity level 2?
Essential 8 maturity level 2 (ML2) is the second target level in the ASD's Essential Eight Maturity Model. Per the Australian Cyber Security Centre (ACSC), ML2 is designed to defend against adversaries with a modest step-up in capability from the opportunistic attackers that ML1 targets. These actors are willing to invest more time in a specific target and in the effectiveness of their tools. [1]
The levels are cumulative. To hold ML2 for any given strategy, an organisation must meet every ML1 requirement for that strategy plus the additional ML2 requirements. Skipping ahead is not permitted under the ACSC framework.
ML2 is the minimum level specified by many Australian government and defence-adjacent contracts. If you are unsure which level your obligations require, the Essential 8 compliance overview covers how the framework is structured and how contract requirements typically map to the three target levels.
The core principle: wider scope and stronger controls
ML2 introduces genuine new requirements across several strategies. Three themes recur.
Scope expands. Controls that applied to workstations at ML1 are extended to internet-facing servers and a broader set of services at ML2.
Authentication strengthens. Standard MFA methods that satisfy ML1 are not sufficient at ML2. Phishing-resistant authentication becomes mandatory for all users accessing internet-facing services.
Detection becomes real. ML1 can be met with correctly-configured controls and no central visibility. ML2 requires event logs to be collected, protected and retained in a centralised store.
If you are planning the ML1-to-ML2 roadmap, the Essential 8 ML1 checklist is a useful baseline to measure your current gap from.
ML2 requirements across the eight strategies
1. Patch applications
At ML1, applications with exploitable vulnerabilities must be patched within 48 hours of a working exploit becoming public, or within one month for other updates. At ML2, the ACSC adds a requirement to use an automated vulnerability scanner at least fortnightly to identify missing patches. The scope of applications in scope also broadens, and security vulnerabilities in online services must be mitigated within 48 hours of becoming known. [1]
The practical ML2 gap for most organisations is coverage, not speed. Many teams patch internet-facing apps promptly but do not scan the full estate consistently.
2. Patch operating systems
The core timelines are similar at ML1 and ML2, but ML2 requires internet-facing operating systems with known exploitable vulnerabilities to be patched within 48 hours of the exploit becoming public, in place of the standard 2-week window. Non-internet-facing workstations and servers must be patched within one month. The ACSC is also clear that "patching" includes deploying compensating controls where a vendor patch is not yet available. [1]
3. Configure Microsoft Office macro settings
At ML1, macros are blocked for users who do not need them and macros downloaded from the internet are disabled for everyone. At ML2, permitted macros must originate from a trusted location or carry a digital signature from a trusted publisher. Users must not be able to change their own macro settings, and those settings must be centrally managed and consistently enforced. [1] Microsoft Learn maps the relevant Intune and Group Policy settings to each maturity level. [3]
4. User application hardening
ML2 extends the ML1 browser and plugin controls with additional requirements: Internet Explorer 11 must be disabled or removed; PowerShell 2.0 must be removed from systems where it is not required; PowerShell must be configured to use Constrained Language Mode; PDF software must be configured to not process OLE objects; and Microsoft Office must be configured to prevent OLE package content from executing. [1]
The PowerShell Constrained Language Mode requirement is the most frequently overlooked item during M365-focused assessments in Australian organisations.
5. Restrict administrative privileges
At ML1, privileged access is validated against job requirements and admin accounts are used only for admin tasks. At ML2, the ACSC requires separate admin accounts that are distinct from standard user accounts, with those admin accounts prohibited from accessing the internet, email or web browsing. For cloud services, time-limited on-demand administration is expected for privileged access where technically feasible, and privileged access to systems must be authenticated using MFA. [1]
The separation of admin and standard accounts is the requirement most commonly incomplete in organisations that report ML1 compliance for this strategy.
6. Application control
At ML1, application control applies to workstations, preventing execution of unapproved executables, software libraries, scripts and similar files. At ML2, application control must cover all internet-facing servers as well as workstations. Microsoft's recommended application control policy must be deployed, DLL controls must be in place, and event logs for prevented executions must be centrally collected, protected from modification and retained for at least 12 months. [1] The ASD Blueprint for Secure Cloud documents the WDAC configuration aligned to each maturity level. [2]
7. Multi-factor authentication
MFA is where the gap between ML1 and ML2 is most visible. At ML1, any MFA method is accepted for remote access and privileged users. At ML2, the ACSC requires phishing-resistant MFA for all users of internet-facing services, all remote access connections and all privileged accounts. Phishing-resistant methods include FIDO2 security keys, device-bound passkeys, Windows Hello for Business backed by a hardware trusted platform module (TPM), and certificate-based authentication. Standard TOTP authenticator codes and SMS OTPs do not qualify because they can be captured by a real-time phishing proxy. [1]
For a full breakdown of which methods satisfy each level and how to enforce them in Microsoft 365, see the Essential 8 MFA requirements guide.
8. Regular backups
At ML1, important data, software and configuration settings are backed up daily, retained for at least 3 months and stored separately from the systems they protect. At ML2, the ACSC adds that backups must be tested at least annually to confirm data can be restored. Restoration procedures must be documented, and test results must be retained as evidence of compliance. [1] The testing requirement is the most commonly missed ML2 backup control: many organisations back up data correctly but have never confirmed the backup restores successfully.
What "consistent application" means at ML2
The ACSC uses the phrase "consistently applied" throughout the maturity model. This has a specific meaning: a control that applies to 90% of workstations is not consistently applied. A control active on most internet-facing servers but not all is not consistently applied.
A frequent assessment failure involves organisations that deployed a control to their main device estate but excluded a small number of legacy machines or a specific server group. Under the ACSC framework, that is not ML2. The rating for that strategy does not advance until the control scope covers every in-scope system.
Before targeting ML2, it is worth auditing your current controls for coverage gaps, not only for configuration correctness.
The most common ML2 gaps in Australian organisations
Across Essential 8 assessments of Australian M365 environments, three gaps appear most often.
Phishing-resistant MFA. Most organisations running M365 have some form of MFA in place. Far fewer have moved to FIDO2 hardware keys or certificate-based authentication for all user accounts. Device compatibility, hardware procurement logistics and staff change management are the usual blockers, not technical complexity.
Admin account separation. IT staff routinely use a single account for both day-to-day work and administrative tasks. Establishing distinct admin accounts that cannot access email or the internet requires policy enforcement and often a culture shift before a technology one.
Centralised event log collection. Application control and MFA controls may be correctly configured on endpoints, but their logs frequently sit on individual devices instead of a centralised, tamper-protected store. Without central retention, the ACSC log requirements at ML2 are not met, even if the underlying controls are active.
How long does it take to move from ML1 to ML2?
For an Australian SMB already at ML1, 6 to 12 months is a realistic estimate. The phishing-resistant MFA rollout is typically the longest workstream: it involves procuring hardware tokens or enabling Windows Hello for Business across all enrolled devices, plus staff communication and helpdesk preparation.
Many of the configuration changes for macros, user application hardening and admin account separation can be deployed through Intune or Group Policy in days. The timeline bottleneck is nearly always people and process changes, not technical configuration.
How CYBERWHITE helps you close the ML2 gap
CYBERWHITE scans your Microsoft 365 environment and maps your current position against the ACSC requirements for each of the eight strategies, at ML1, ML2 and ML3. The scan identifies specific controls missing at ML2, not a summary score, so you know exactly which requirements are open before beginning remediation work.
Where a gap can be closed through Microsoft Graph, AutoFix can deploy the configuration change with your approval before anything is modified in production. The CARS adaptive risk scoring algorithm prioritises the gaps with the highest impact on your overall maturity rating, so you address the most valuable items first instead of working through a flat list.
CYBERWHITE is Australian owned and operated (ABN 31 598 198 475) and a DSI Licensed Commercial Holder of SMB1001. It is not a substitute for a formal ACSC assessment or IRAP evaluation. To understand what is included at each plan, visit pricing. To run your first gap scan, start with the Essential 8 maturity assessment.
Frequently asked questions
What is Essential 8 maturity level 2?
Essential 8 maturity level 2 (ML2) is the second target level in the ASD's Essential Eight Maturity Model. The ACSC designed it to defend against adversaries willing to invest more time and more effective tools than the opportunistic attackers ML1 addresses. ML2 requires every ML1 control plus additional requirements including phishing-resistant MFA for all users of internet-facing services, application control on internet-facing servers, centralised event log collection and stricter macro and administrative privilege controls.
What does ML2 add over ML1 for multi-factor authentication?
At ML1, any MFA method is accepted for remote access and privileged users. At ML2, the ACSC requires phishing-resistant MFA for all users of internet-facing services, all remote access connections and all privileged accounts. Phishing-resistant methods include FIDO2 security keys, passkeys, Windows Hello for Business backed by a hardware TPM and certificate-based authentication. Standard TOTP authenticator codes and SMS OTPs do not qualify at ML2.
Is ML2 mandatory for Australian government contracts?
It depends on the specific contract, agency or tender. Many Australian government and defence-adjacent contracts specify a minimum maturity level, and a number require ML2. Check your contract or agency guidance directly. Where no level is stated, ML1 is the common baseline, with ML2 the expected next step as risk profile or client requirements increase.
What is phishing-resistant MFA?
Phishing-resistant MFA refers to authentication methods that cannot be captured or relayed by a real-time phishing attack. The ACSC requires these methods at ML2. Examples include FIDO2 security keys, device-bound passkeys and Windows Hello for Business backed by a hardware TPM. Standard TOTP codes from authenticator apps and SMS OTPs do not qualify because an attacker running a proxy phishing page can intercept them in real time.
Where can I assess my Essential 8 ML2 gap?
CYBERWHITE's Essential 8 maturity assessment scans your Microsoft 365 environment and maps your current position against each of the eight strategies at ML1, ML2 and ML3. It flags the specific controls missing at ML2 so you can see your actual gap before starting remediation, instead of working from a generic checklist.
Sources: [1] ACSC Essential Eight Maturity Model (November 2023) - cyber.gov.au [2] ASD Blueprint for Secure Cloud - blueprint.asd.gov.au [3] Microsoft Learn: Essential Eight Configure Microsoft Office Macro Settings - learn.microsoft.com