What Essential Eight Maturity Level 2 means in 2026
Maturity Level 2 is the Australian Signals Directorate (ASD) Essential Eight tier built for adversaries with a modest step-up in capability. These attackers are more selective with their targeting, willing to invest more time on a target, and more capable with their tradecraft. According to the ASD Essential Eight Maturity Model published at cyber.gov.au (current revision) (Australian Cyber Security Centre — Essential Eight Maturity Model, accessed 16 June 2026), Maturity Level 2 is the practical baseline most Australian government suppliers, regulated entities and large-enterprise procurement teams expect their counterparties to meet in 2026. Below Maturity Level 2, the gap between control design and operational reality is the gap an attacker exploits. That gap is what an assessor is paid to find.
This pillar guide is the 2026 evidence pack. It walks every Essential Eight control at Maturity Level 2 in the same three steps: the published ASD requirement; the Information Security Manual (November 2025) control identifiers it maps to (Australian Signals Directorate — Information Security Manual, accessed 16 June 2026); and the evidence artefact an ASD-qualified assessor will sample from your environment. Use it as the working plan for an in-house uplift programme, or as the briefing the executive sponsor reads before signing off on a remediation budget.
Throughout the guide the abbreviation "E8" is deliberately avoided. The phrase is Essential Eight, every time — that is the term the ASD uses, the term used in the Information Security Manual, and the term you will see on assessor reports.
1. Why Maturity Level 2, why now
The 2026 procurement and regulatory pressure
The Essential Eight Maturity Model first appeared in 2017 and was restructured in 2022 to introduce the Maturity Level 0 to 3 scale. According to the Department of Home Affairs Protective Security Policy Framework (PSPF) policy 10, Commonwealth non-corporate entities must implement the Essential Eight at the maturity level appropriate to their risk profile, and ML2 is the published baseline for most. The PSPF reporting cycle for 2025–26, published in mid-2025, formalised this expectation across Commonwealth supplier ecosystems.
State government procurement frameworks have moved in lockstep. New South Wales' Cyber Security Policy v3.0 (2025), Victorian Government Cyber Security Strategy 2024–2030, and Queensland Government Information Security Standard (2024) all reference ASD's Essential Eight as the baseline expectation, with Maturity Level 2 cited as the standard procurement attestation for vendors holding personal information or processing on government infrastructure.
In the private sector, large procurement teams now embed Essential Eight ML2 attestation language into supplier security questionnaires. This is most common across financial services, healthcare and critical infrastructure. According to the Australian Cyber Security Centre Annual Cyber Threat Report 2024–25, supplier-chain compromise was the second most-reported initial-access category in that reporting period, behind only exploitation of public-facing applications. That data has reshaped how customers assess vendor risk, and ML2 attestation has become the shortcut they look for.
What ML2 is built to resist
According to the ASD Essential Eight Maturity Model (current revision), Maturity Level 2 is built to resist adversaries with a modest step-up in capability beyond the opportunistic, smash-and-grab attackers that ML1 targets. ML2 adversaries are more selective, willing to invest more time in reconnaissance, more capable with their tradecraft, and prepared to use social engineering to defeat single-factor authentication. ML2 is not built to resist sophisticated state-sponsored adversaries. That is the remit of Maturity Level 3 and additional controls beyond the Essential Eight.
In practice, ML2 expects organisations to assume an adversary will probe, retry, and run phishing campaigns that defeat basic SMS-based or push-notification multi-factor authentication. That is why ML2 emphasises phishing-resistant MFA for privileged and remote access, application control to block post-phish payload execution, and tight patch windows for internet-facing services.
Where ML2 sits on the maturity scale
- Maturity Level 0 — basic weaknesses; trivial to compromise; not a stable defensive baseline
- Maturity Level 1 — opportunistic adversaries; commodity malware and unpatched legacy applications addressed; the absolute floor for a credible programme
- Maturity Level 2 — selective adversaries; phishing-resistant MFA on privileged accounts; tight patch windows; application control enforced
- Maturity Level 3 — sophisticated and adaptive adversaries; comprehensive logging; centralised event correlation; tested incident response
The ASD's published guidance is clear: organisations should assess every control against the maturity level appropriate to their risk profile, and the overall maturity reported is the lowest across all eight controls. According to the ASD Essential Eight Maturity Model FAQ (cyber.gov.au, current revision), a single control at ML1 caps the whole organisation at ML1, even if the other seven sit at ML2 or ML3.
2. The eight mitigation strategies at ML2 — control-by-control
Every control below follows the same structure: the published ML2 requirement, the Information Security Manual (November 2025) control identifiers most commonly invoked during assessment, and the evidence artefact an ASD-qualified assessor will sample. The Information Security Manual is published at cyber.gov.au and updated quarterly. This guide is aligned to the November 2025 release.
Control 1 — Application control
The ML2 requirement. According to the ASD Essential Eight Maturity Model (current revision), 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, 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 so-called living-off-the-land binaries).
ISM control identifiers (Nov 2025). Application control mapping aligns with the Information Security Manual control identifiers governing software allowlisting, executable and script execution restrictions, and the Microsoft recommended block-rule guidance. Assessors will read the effective policy on a sampled endpoint and compare it to the documented allowlist.
Evidence artefacts. An exported Microsoft AppLocker policy or Windows Defender Application Control (WDAC) policy file; the effective application control policy retrieved from a sampled endpoint using Get-AppLockerPolicy -Effective or the WDAC equivalent; an event log extract showing application control denials over the prior 30 days; a list of approved publishers and signed binaries; and the implementation of Microsoft's recommended block rules. The how-to Application control on Microsoft 365 — AppLocker and WDAC for ML2 covers the technical implementation step-by-step.
Control 2 — Patch applications
The ML2 requirement. According to the ASD Essential Eight Maturity Model (current revision), at Maturity Level 2 patches, updates or vendor mitigations for security vulnerabilities in internet-facing services are applied within two weeks of release, or within 48 hours if an exploit exists. Patches for office productivity suites, web browsers and their extensions, email clients, PDF software, and security products are applied within one month of release. A vulnerability scanner is used at least fortnightly to identify missing patches.
ISM control identifiers (Nov 2025). Patch management mapping aligns with Information Security Manual control identifiers ISM-1690 and ISM-1691 and adjacent identifiers governing vulnerability scanning and the patching of internet-facing and non-internet-facing applications respectively.
Evidence artefacts. Microsoft Intune or Microsoft Endpoint Configuration Manager (MECM) software update compliance reports showing per-device patch state; Microsoft Defender Vulnerability Management or third-party scanner (Tenable Nessus, Qualys) scan results for the prior 12 months; a list of internet-facing services with their patch dates; and an exception register for any patch deferred beyond the timeframe, including business justification and compensating controls. The companion how-to ML2 evidence templates per Essential Eight control includes a printable evidence checklist.
Control 3 — Configure Microsoft Office macro settings
The ML2 requirement. According to the ASD Essential Eight Maturity Model (current revision), at Maturity Level 2 Microsoft Office macros are disabled for users that do not have a demonstrated business requirement. Microsoft Office macros in files originating from the internet are blocked. Macro antivirus scanning is enabled. Microsoft Office macro security settings cannot be changed by users. Only Microsoft Office macros running from within a sandboxed environment, a Trusted Location, or that are digitally signed by a Trusted Publisher are allowed to execute.
ISM control identifiers (Nov 2025). Macro security mapping aligns with the Information Security Manual control identifiers governing macro execution restrictions, internet-origin macro blocking, and antivirus scanning of macro content. ACSC's standalone publication Restricting Microsoft Office Macros (cyber.gov.au, current revision) is the supporting guidance.
Evidence artefacts. Group Policy or Intune configuration profile export showing the macro security settings enforced organisation-wide; an export of approved Trusted Publishers and the certificates used to sign in-house macros; macro execution audit logs from Microsoft 365 Apps; and an exception register listing users with a documented business requirement to run macros and the compensating controls applied.
Control 4 — User application hardening
The ML2 requirement. According to the ASD Essential Eight Maturity Model (current revision), at Maturity Level 2 web browsers do not process Java from the internet, web advertisements are blocked, and Internet Explorer 11 is disabled or removed. Microsoft Office is configured to prevent activation of Object Linking and Embedding packages. Microsoft Office and PDF software are configured to disable Flash content. ACSC and vendor-recommended security configurations are applied. Hardening settings cannot be changed by users.
ISM control identifiers (Nov 2025). User application hardening mapping aligns with the Information Security Manual control identifiers governing web browser hardening, Microsoft Office OLE package handling, Flash content disabling, and Internet Explorer 11 removal.
Evidence artefacts. Group Policy or Intune configuration profile exports showing hardening settings applied; Microsoft Edge and Chrome enterprise policy exports; a list of endpoints with Internet Explorer 11 disabled or removed; and a workstation baseline document referencing ACSC and Microsoft hardening guidance.
Control 5 — Restrict administrative privileges
The ML2 requirement. According to the ASD Essential Eight Maturity Model (current revision), at Maturity Level 2 requests for privileged access to systems, applications and data repositories are validated when first requested. Privileged users use separate privileged and unprivileged operating environments. Unprivileged accounts cannot log on to privileged operating environments. Privileged accounts (excluding privileged service accounts) are prevented from accessing the internet, email and web services. Privileged access events are centrally logged.
ISM control identifiers (Nov 2025). Privileged access mapping aligns with the Information Security Manual control identifiers governing separate privileged accounts, privileged access workstations, restricted internet access for privileged accounts, and centralised privileged-access logging.
Evidence artefacts. A privileged account inventory listing every account with elevated rights, the system it provides access to, and the business owner; evidence of separate privileged and unprivileged accounts per administrator; Entra ID Privileged Identity Management (PIM) configuration exports showing time-bound activation; Conditional Access policy exports blocking privileged accounts from non-managed networks and the open internet; and centralised log exports showing privileged-access events for the prior 12 months. The existing how-to at /blog/essential-eight-control-5-user-privilege-management covers implementation depth.
Control 6 — Patch operating systems
The ML2 requirement. According to the ASD Essential Eight Maturity Model (current revision), at Maturity Level 2 patches, updates or vendor mitigations for security vulnerabilities in operating systems of internet-facing services are applied within two weeks of release, or within 48 hours if an exploit exists. Patches for workstations, servers and network devices are applied within one month of release. A vulnerability scanner is used at least fortnightly. Operating systems that are no longer supported by vendors are replaced.
ISM control identifiers (Nov 2025). Operating system patching mapping aligns with the Information Security Manual control identifiers governing operating system patch timeframes for internet-facing and non-internet-facing infrastructure and the replacement of unsupported operating systems.
Evidence artefacts. Windows Update for Business or Microsoft Endpoint Configuration Manager (MECM) operating system patch compliance reports; a list of internet-facing servers with their patch dates and operating system versions; vulnerability scan reports across the server and workstation fleet; and a hardware refresh schedule for operating systems approaching vendor end-of-support. The existing how-to at /blog/essential-eight-control-6-patch-operating-systems covers implementation depth.
Control 7 — Multi-factor authentication
The ML2 requirement. According to the ASD Essential Eight Maturity Model (current revision), at Maturity Level 2 multi-factor authentication is used by privileged users of systems. Multi-factor authentication is used by users when accessing important data repositories. Multi-factor authentication is used by users when accessing the organisation's internet-facing services. Multi-factor authentication uses either: something users have and something users know; or something users have that is unlocked by something users know or are. SMS, email or voice call MFA methods are not used.
ISM control identifiers (Nov 2025). Multi-factor authentication mapping aligns with the Information Security Manual control identifiers governing phishing-resistant authentication for privileged access, internet-facing services and high-value data repositories.
Evidence artefacts. Microsoft Entra ID authentication methods policy exports; Conditional Access policy exports requiring MFA for the in-scope user groups and applications; sign-in logs showing MFA enforcement for the prior 90 days; a list of internet-facing services and the MFA enforcement method per service; and an exception register for any user, application or service for which MFA cannot be enforced, including compensating controls. The existing how-to at /blog/essential-eight-control-7-mfa-best-practices covers implementation depth.
Control 8 — Regular backups
The ML2 requirement. According to the ASD Essential Eight Maturity Model (current revision), at Maturity Level 2 backups of important data, software and configuration settings are performed and retained in accordance with business continuity requirements. Backups are tested in accordance with business continuity requirements. Unprivileged accounts cannot access backups belonging to other accounts. Unprivileged accounts are prevented from modifying or deleting backups.
ISM control identifiers (Nov 2025). Backup mapping aligns with the Information Security Manual control identifiers governing backup retention, testing of recoverability, and access restrictions on backup repositories.
Evidence artefacts. A documented backup policy showing retention aligned to business continuity requirements; backup job logs from the prior 12 months showing successful execution; restore test logs for the prior 12 months demonstrating that backups are recoverable; access control configuration on backup storage demonstrating that unprivileged accounts cannot read, modify or delete other accounts' backups; and immutability or write-once configuration evidence where applicable. The existing how-to at /blog/regular-backups-recovery-essential-eight covers implementation depth.
3. Remediation sequencing — close the weakest control first
The overall maturity reported is the lowest across all eight controls (per the ASD Essential Eight Maturity Model FAQ, cyber.gov.au, current revision). So the budget question is always the same: which control is your gate? The answer sets the remediation sequence.
The fastest path from ML1 to ML2
For most Australian mid-market organisations starting from a partial ML1 baseline, the typical gating controls are application control (Control 1) and phishing-resistant MFA for privileged accounts and remote access (Control 7). Both are demanding, but they have very different lead times.
-
Phishing-resistant MFA (Control 7) is usually achievable within four to six weeks. The capability is already inside Microsoft Entra ID Premium P1, which is bundled with Microsoft 365 Business Premium and E3. The work is policy authoring, user enrolment, and decommissioning SMS-based methods. Apply Conditional Access policies that require Microsoft Authenticator with number matching or FIDO2 security keys for privileged accounts first, then internet-facing services, then high-value data repositories.
-
Application control (Control 1) is usually a 12 to 16-week rollout for a managed Windows fleet. Discovery and baselining of approved publishers and signed binaries takes 4 to 6 weeks. An audit-mode rollout runs alongside production for another 4 to 6 weeks. Then a managed enforcement rollout proceeds in waves with a rollback path. The application control how-to in this cluster walks the staged AppLocker to WDAC migration.
Patch (Controls 2 and 6) and backup (Control 8) uplift can proceed in parallel and are usually closed within the first six weeks, because the underlying tooling — Microsoft Intune, MECM, Defender Vulnerability Management, Azure Backup or Veeam — is typically already in place. The work is policy tightening and evidence collection.
The longer ML2 to ML3 path
The step from Maturity Level 2 to Maturity Level 3 introduces much more rigour: tighter patch timeframes; mandatory cloud-trust validation for application control on Windows; centralised event correlation and 24×7 monitoring expectations; and tested incident response. The ASD's published guidance positions ML3 as the appropriate tier for organisations handling sensitive or classified information. For most ML2-attaining organisations, ML3 is not the next quarterly objective. It is a 12 to 24-month strategic programme.
4. The assessor expectation — five things ML2 assessments commonly miss
ASD-qualified assessors operating under the ASD Essential Eight Assessment Process Guide (2024) (Australian Cyber Security Centre — Essential Eight Assessment Process Guide, accessed 16 June 2026) consistently flag the same five gaps in 2026 engagements:
-
Application control in audit mode only. Many organisations roll out application control in audit mode for visibility but never advance to enforcement. Audit mode is ML1 evidence at best — ML2 requires effective enforcement on workstations and internet-facing servers, with the Microsoft and ASD recommended block rules applied.
-
Internet-facing patch window slipped to weekly. The 48-hour timeframe when an exploit exists is non-negotiable. Many organisations run monthly internet-facing patch cycles that satisfy ML1 but fail ML2. An out-of-band emergency patch process and a vulnerability scanner running at least fortnightly are both required.
-
MFA still on SMS for some user groups. The ASD's current Maturity Level 2 wording explicitly excludes SMS, email and voice call MFA. Organisations frequently leave SMS as a fallback method for a small group of legacy users — that group caps the overall control at ML1.
-
Privileged accounts have internet access. ML2 requires privileged accounts (excluding privileged service accounts) to be prevented from accessing the internet, email and web services. A privileged user opening a malicious link from their admin workstation negates every other ML2 control. Conditional Access policies and dedicated privileged access workstations are the standard remedy.
-
Backups never restore-tested. ML2 requires backups to be tested in accordance with business continuity requirements. A documented restore plan without a restore test log from the prior 12 months is not evidence — it is documentation.
5. The Information Security Manual is the source of evidence prompts
Throughout this guide, the evidence artefact lists are framed against the Information Security Manual (November 2025 release). The ISM is updated quarterly by the Australian Cyber Security Centre and published at cyber.gov.au alongside the Essential Eight Maturity Model. Every control identifier in your assessor's evidence requests traces back to a published ISM control, and every ISM control traces back to a published security objective.
The ISM translates the policy intent of the Essential Eight into the verifiable technical settings an assessor will sample. When you are unsure whether a configuration meets ML2, the ISM control text is more specific than the Essential Eight Maturity Model text, and assessors read both.
6. Self-assessment cadence and formal assessment
According to the ASD Essential Eight Maturity Model FAQ (cyber.gov.au, current revision), self-assessment is encouraged at a quarterly cadence. Formal assessment by qualified assessors is recommended at least annually for organisations relying on Essential Eight attestation for procurement or regulatory purposes.
The free Essential Eight Maturity Assessment at /essential-eight-maturity is built for the quarterly self-assessment cadence. It runs 15 questions across the eight controls, with the same Maturity Level 0 to 3 thresholds and the same evidence-prompt phrasing the formal Assessment Process Guide uses. It is not a substitute for formal assessment. It is the tool that tells you which control is your gate before the formal assessor arrives.
For formal assessment with evidence-pack support, see /assessments/essential-eight-assessment.
7. The Privacy Act 1988 layer — why ML2 matters beyond procurement
Maturity Level 2 sits inside a wider Australian regulatory frame. According to the Office of the Australian Information Commissioner (OAIC), Australian Privacy Principle 11 (Office of the Australian Information Commissioner — Australian Privacy Principles guidelines, accessed 16 June 2026) requires organisations to take reasonable steps to protect personal information from misuse, interference, loss, unauthorised access, modification or disclosure. The OAIC's Guide to securing personal information (current revision) references both the Essential Eight and the Information Security Manual as practical reference points for what "reasonable steps" looks like in 2026.
A data breach involving personal information triggers the Notifiable Data Breaches scheme (Office of the Australian Information Commissioner — Notifiable Data Breaches scheme, accessed 16 June 2026): assessment within 30 days, then notification to the OAIC and to affected individuals. According to OAIC Notifiable Data Breaches reports across 2024 and 2025, the most common root cause of reportable breaches in Australian organisations remains cyber incidents involving credential compromise, phishing, ransomware and supplier-chain exploitation. Essential Eight Maturity Level 2 is designed to resist every one of these.
Demonstrable Essential Eight ML2 posture is therefore more than a procurement attestation. It is the practical evidence an organisation produces when the OAIC asks whether reasonable steps were in place at the time of an incident. The November 2022 amendments to the Privacy Act (Office of the Australian Information Commissioner — The Privacy Act, accessed 16 June 2026) increased maximum penalties for serious or repeated interferences with privacy, so the regulatory cost of failing to operate at ML2 has grown sharply in the Australian market.
8. Putting it together — your ML2 evidence pack on a page
A workable Essential Eight ML2 evidence pack for an Australian mid-market organisation runs to roughly 35 to 50 artefacts, collected on a quarterly cadence. The pack lives in a dated SharePoint library or shared drive that the security team owns. Put the ISM control identifier in the filename, and the publication date and source URL in the document metadata.
The companion how-to ML2 evidence templates per Essential Eight control provides per-control evidence checklists and a printable index that maps every artefact to the Maturity Model requirement and the ISM control. The companion how-to Application control on Microsoft 365 — AppLocker and WDAC for ML2 walks the technical implementation of the most-failed ML2 control end-to-end.
9. Bringing the programme back to one number
The single most useful number in an Essential Eight programme is your lowest control score. Track it weekly during uplift, monthly during steady-state. Every change to the environment can move that number down a tier: a new application, a new SaaS service, a new supplier. Every formal assessment is a chance to defend that number. Every quarterly self-assessment is a chance to spot the slip before the assessor does.
Score your current Essential Eight maturity against ML2 in five minutes with the free Essential Eight Maturity Assessment — entity-aligned to the ASD published model and the November 2025 Information Security Manual. Then close gaps in priority order before any formal attestation: start with the gating control, sequence the rest by lead time, and rebuild the evidence pack quarterly. For practitioner-led evidence-pack support and a fixed-price remediation roadmap, see the Essential Eight Assessment service.
Related guides in this cluster
Use these companion guides alongside the pillar. Each one goes deeper on a single part of the ML2 programme:
- ML2 evidence templates per Essential Eight control — the practitioner checklist of artefacts an assessor will sample, indexed per control.
- Application control on Microsoft 365 — AppLocker and WDAC for ML2 — end-to-end rollout of the most-failed ML2 control.
- Essential Eight Control 2: Patch Applications — application patching timeframes, Intune and MECM deployment, and evidence.
- Essential Eight Control 6: Patch Operating Systems — Windows, Linux, server and network OS patching to the ML2 timeframes.
- Essential Eight Control 3: Configure Microsoft Office macro settings — Group Policy and Intune macro enforcement, VBA signing and trusted publishers.
- Essential Eight evidence-pack IRAP-format checklist for the Copilot scope — how to structure the pack inside a wider system security plan.
- Essential Eight Maturity Level 2 evidence pack — free download — the companion downloadable checklist, IRAP cross-reference table and sign-off page.
Sources cited
- Australian Signals Directorate — Essential Eight Maturity Model (current revision, cyber.gov.au, checked 24 May 2026)
- Australian Signals Directorate — Essential Eight Maturity Model FAQ (cyber.gov.au, current revision, checked 24 May 2026)
- Australian Cyber Security Centre — Information Security Manual (November 2025 release, cyber.gov.au)
- Australian Signals Directorate — Strategies to Mitigate Cyber Security Incidents (cyber.gov.au, current revision)
- Australian Cyber Security Centre — Restricting Microsoft Office Macros (cyber.gov.au, current revision)
- Australian Cyber Security Centre — Implementing Application Control (cyber.gov.au, current revision)
- Department of Home Affairs — Protective Security Policy Framework, Policy 10 (current cycle)
- Australian Cyber Security Centre — Annual Cyber Threat Report 2024–25
- Office of the Australian Information Commissioner — Guide to securing personal information (current revision)
- Office of the Australian Information Commissioner — Notifiable Data Breaches reports (2024 and 2025)
- Microsoft Learn — Microsoft 365 and the ACSC Essential Eight (learn.microsoft.com, checked 24 May 2026)
Sources referenced in this article: Australian Cyber Security Centre — Essential Eight Maturity Model and Essential Eight Assessment Process Guide; Australian Signals Directorate — Information Security Manual (November 2025 release); Office of the Australian Information Commissioner — Australian Privacy Principles guidelines, The Privacy Act and Notifiable Data Breaches scheme (all accessed 16 June 2026).
