Essential Eight Maturity Level 2: The Real ML1 to ML2 Uplift Explained

Two things happened this year that changed the Essential Eight conversation, and they point in opposite directions.

In June, the Enhanced CIRMP Rules made Essential Eight Maturity Level 2 a statutory expectation for nine classes of critical infrastructure asset, with a deadline around June 2028. Separately, government buyers and enterprise customers have been steadily lifting their own supplier expectations from Level 1 to Level 2.

Also in June, ASD opened a consultation on evolving the Essential Eight into a broader body of guidance called the Essentials series, beginning with a chapter titled "Essentials for enterprise IT". Consultation closed on 12 July 2026. Reporting around the announcement indicated the Essential Eight would begin to be deprecated in roughly 12 months and retired in roughly 24.

So organisations are being asked to invest in reaching Level 2 on a model that may not exist in its current form by the time they get there. We get asked about this most weeks. It is a fair question and it deserves a straight answer before any of the control detail.

Should you keep going? Yes, and here is why

The indicative dates are indicative. The 12 and 24 month figures came through media coverage of the consultation, not a gazetted instrument or a published ASD transition plan. Treat them as direction of travel, not a schedule you can plan against. As at the end of August 2026, the November 2023 Essential Eight Maturity Model remains the operative standard and the thing your assessor will assess you against.

The controls are not going anywhere. ASD has signalled strong alignment between the Essentials series and existing Essential Eight controls and investments. The new guidance is expected to draw from the Information Security Manual and organise mitigations by domain, with further chapters flagged for cloud and operational technology. Patching, MFA, application control, admin restriction and backups are not about to become unnecessary. The measure may be re-expressed. The work will not be wasted.

Your obligations do not pause for a consultation. If you are a responsible entity under the Enhanced CIRMP Rules, section 8A(3) names Essential Eight Maturity Level 2 as one of the ways to satisfy the cyber hazard requirement, and the clock runs to roughly June 2028 regardless of what ASD publishes in the meantime. The same applies to contractual commitments you have already made to customers or to government buyers.

One thing to do differently. Document your controls as outcomes, not just as maturity level scores. "We block macros originating from the internet and prevent macros from making Win32 API calls" survives a framework change. "We are ML2" does not necessarily map cleanly onto whatever replaces the maturity ladder. This is good practice anyway, and it makes your evidence portable.

With that settled, here is what the uplift actually involves.

The rule that catches people first

ASD's position is that the Essential Eight is implemented and assessed as a package. You do not reach Maturity Level 2 by getting four strategies to Level 2 and leaving four at Level 1. Your maturity is the lowest level you meet across all eight.

This matters commercially, because it is very common to see organisations invest heavily in the two or three strategies their tooling makes easy, report progress to the board on those, and stall on the rest. Your assessment result is determined by whichever strategy you neglected.

Plan the uplift as one programme with eight workstreams, not eight projects.

What actually changes, strategy by strategy

Here is the delta from Maturity Level 1 to Maturity Level 2. Some of it is smaller than people expect. Some of it is a genuine infrastructure project.

Patch applications

What is added at ML2: the scope extends beyond the core application set (office suites, browsers and extensions, email clients, PDF software, security products) to all other applications. Fortnightly vulnerability scanning and a one-month patch window apply to that broader set.

The timeframes and scanning frequencies for internet-facing services and core applications do not change from Level 1.

Where the work is: building and maintaining an accurate application inventory. Most organisations do not have one, and you cannot scan or patch what you have not enumerated. This is the strategy where assessments most often fail on evidence rather than on capability.

Patch operating systems

What is added at ML2: effectively nothing. The scanning frequencies and patch timeframes at Level 2 are identical to Level 1. Daily scanning for internet-facing servers and network devices, fortnightly for everything else. Forty-eight hours for critical vulnerabilities on internet-facing servers, two weeks otherwise, one month for workstations.

The tightening happens at Level 3, which brings workstations to a 48-hour window for critical vulnerabilities, adds driver and firmware patching timeframes, and requires you to run the latest or previous release of your operating systems.

This surprises people, and it is worth knowing before you budget. If you genuinely meet Level 1 here, you already meet Level 2. The difficulty is sustaining the Level 1 cadence consistently, not implementing something new.

Multi-factor authentication

What is added at ML2: this is one of the two big ones.

MFA extends from online services to systems, covering both privileged and unprivileged users. More significantly, the MFA must be phishing-resistant. ASD's guidance for Level 2 requires that all MFA used is either something users have and something users know, or something users have that is unlocked by something users know or are.

In practice that means FIDO2 security keys, device-bound passkeys, hardware-backed certificates or smartcards, or Windows Hello for Business with a hardware TPM. SMS codes, email one-time passwords, voice callbacks and standard push notifications do not qualify.

Level 2 also requires all successful and unsuccessful MFA events to be centrally logged, with event logs from internet-facing servers analysed in a timely manner.

Where the work is: this is a hardware procurement, enrolment and support project, not a policy change. Budget for the tokens, for the enrolment effort across your whole user base, for the break-glass and lost-token processes, and for the applications that will not support modern authentication and need to be dealt with some other way.

Restrict administrative privileges

What is added at ML2: the other big one, and the one most frequently described incorrectly.

At Level 1 you already need privileged access validated when first requested, separation between privileged and unprivileged operating environments, and privileged accounts blocked from internet, email and web services.

Level 2 adds:

Privileged access disabled after 12 months unless revalidated
Privileged access to systems and applications disabled after 45 days of inactivity
The privileged operating environment not virtualised within an unprivileged one
Administrative activities conducted through jump servers
Break-glass accounts, local administrator accounts and service accounts managed with credentials that are unique, unpredictable and at least 30 characters, centrally managed
Privileged access events and privileged account and group management events forwarded to centralised logging, with logs protected from modification and deletion
Timely analysis of internet-facing server events, with the incident response plan enacted and the CISO and ASD notified where a compromise is identified

To be clear about what is not at Level 2, because this is where a lot of published guidance goes wrong: just-in-time administration and Secure Admin Workstations are Level 3 requirements, as are Credential Guard, Local Security Authority protection and memory integrity. If a vendor is selling you privileged access management on the basis that just-in-time elevation is needed for Level 2, that is not correct.

Where the work is: jump servers and the 30-character centrally managed credential requirement. The credential piece usually means LAPS for local administrators, group managed service accounts or a secrets manager for service accounts, and a hard look at every hard-coded credential in your automation. That discovery exercise takes longer than the implementation.

Application control

What is added at ML2:

Coverage extends from user profiles and temporary folders to all other locations on workstations, and to internet-facing servers
Microsoft's recommended application block rules are now required
Rulesets validated at least annually
Allowed and blocked execution events centrally logged and protected

Where the work is: organisations that met Level 1 cheaply with path-based AppLocker rules generally cannot extend that approach to all locations without breaking things. Level 2 usually means moving to a properly designed Windows Defender Application Control deployment, which needs an application discovery phase, a policy in audit mode for a meaningful period, and a change process for new software. Allow six months for a large environment and do not skip the audit-mode phase.

Restrict Microsoft Office macros

What is added at ML2: for users with a demonstrated business requirement to run macros, those macros must additionally be blocked from making Win32 API calls.

That is the whole delta. Everything else, disabling macros for users without a business need, blocking macros in files originating from the internet, macro antivirus scanning and preventing users from changing macro settings, is already required at Level 1.

Where the work is: testing. The setting itself is a policy change. Finding out which line-of-business macros break because of it, and dealing with those, is the actual project. Do it in a pilot group.

User application hardening

What is added at ML2:

Web browsers hardened in accordance with ASD and vendor hardening guidance, applying the most restrictive where they conflict
Microsoft Office blocked from creating child processes, from creating executable content, and from injecting code into other processes, with OLE package activation prevented
PDF software settings locked and blocked from creating child processes
Command line process creation events, PowerShell module logging, script block logging and transcription, captured from workstations and from both internet-facing and non-internet-facing servers

Disabling or removing .NET Framework 3.5 and PowerShell 2.0, and PowerShell Constrained Language Mode, are Level 3 items.

Where the work is: the logging. The hardening settings are group policy work. Standing up PowerShell and command line logging at volume, shipping it somewhere central, protecting it from tampering and actually analysing it is a SIEM project with an ongoing licensing cost. This is the most commonly underestimated line in the whole Level 2 uplift, because it looks like a checkbox and behaves like a platform.

Regular backups

What is added at ML2: privileged accounts, other than backup administrators, cannot access backups belonging to other accounts, and cannot modify or delete backups.

At Level 1 that restriction applies to unprivileged accounts. Level 2 extends it to privileged accounts.

Preventing accounts from accessing their own backups, and preventing backup administrator accounts from modifying or deleting backups during the retention period, are Level 3 requirements. Some published summaries put the own-backup restriction at Level 2. It is not.

Where the work is: genuinely separating the backup administrator role from general system administration, which for a small IT team can be an uncomfortable conversation about who holds what. Immutable or write-once storage helps, and has a licensing cost.

Where the money actually goes

If you are building a business case, four items account for most of the cost and time:

Phishing-resistant MFA rollout. Hardware, enrolment, support processes, legacy application remediation.
Application control across all locations. Discovery, audit mode, policy design, ongoing change management.
Centralised logging. Required across four of the eight strategies at Level 2. Ingestion volume drives licensing, and PowerShell and command line logging is high volume.
Privileged access re-architecture. Jump servers, credential management tooling, and the removal of hard-coded credentials.

The rest is policy, process and testing. Meaningful effort, but not capital.

A sensible sequence

Assess honestly first. Run an assessment against the current model before planning anything. A surprising number of organisations that believe they hold Level 1 do not, usually on application patching scope or on privileged account separation. Fixing a Level 1 gap while building for Level 2 is much cheaper than discovering it during an external assessment.

Then start the long-lead items. Application control discovery and audit mode, and MFA hardware procurement, both have lead times measured in months and neither can be compressed at the end.

Do the logging platform next, because four strategies depend on it and the requirements compound. Build it once, feed it from everywhere.

Leave the policy and testing items until you have capacity, because macros, Office hardening and browser hardening are quick to configure and slow to validate, and validation is easier when the rest of the environment is stable.

Keep the package rule in view. Track all eight together and report the lowest, not the average.

Verify against the source

The Essential Eight Maturity Model is periodically revised, and the Essentials series consultation means further change is coming. This article reflects the November 2023 model as at August 2026, and we have cross-checked the control statements against ASD's own published guidance.

Read the current model text against your own environment before you commit budget. Where a summary and the model disagree, the model wins, and your assessor will work from the model.

Planning a Level 2 uplift?

CyberNinja helps Australian and New Zealand organisations assess their current Essential Eight maturity honestly, build a costed uplift plan, and evidence the outcome for customers, government buyers and regulators. If you are working towards Level 2 and want a clear view of the gap and what it will take, get in touch.

This article is general guidance, not a formal assessment, and reflects the Essential Eight Maturity Model as at August 2026. Maturity level claims should be validated through a qualified assessment. Confirm all control requirements against ASD's current published model.

Sources