Essential Eight Maturity Level Three: Achieving and Sustaining It

Maturity Level Three is the apex of the Australian Cyber Security Centre’s Essential Eight. It is designed to frustrate adaptive, well-resourced adversaries who are prepared to invest significant effort, tailor their tradecraft to a specific target and exploit weaknesses faster than most organisations can respond. Reaching ML3 is a serious undertaking, and sustaining it is the part that catches organisations out.

If you are weighing whether ML3 is the right target at all, start with our Essential Eight guide and an honest read of your threat profile. ML3 is not a badge to chase for its own sake; it is the correct posture for organisations that genuinely face capable adversaries or hold data whose compromise would be severe.

The adversary ML3 is built to stop

Each maturity level maps to a class of attacker. Maturity Level Three assumes an adversary who is more adaptive and far less reliant on commodity tools. This attacker will actively work around controls, exploit gaps in coverage, target weaknesses in your specific environment and move quickly once inside. They are willing to defeat weaker forms of multi-factor authentication and to exploit any unsupported software you have left running.

That threat model explains every ML3 requirement. The level is not simply a stricter version of ML2; it closes the specific avenues a determined, capable attacker would use, particularly credential relay, execution of unapproved code and dwelling undetected in an environment with poor logging.

Phishing-resistant MFA becomes mandatory

The headline change at ML3 is multi-factor authentication. At Maturity Level Two, standard MFA is acceptable. At Maturity Level Three, MFA must be phishing-resistant. This means authenticators that cannot be defeated by a real-time relay or man-in-the-middle proxy that tricks a user into approving an attacker’s session.

In practice that points to FIDO2 security keys, platform and roaming passkeys, or smartcards. One-time passwords delivered by SMS, or even codes from an authenticator app, are excluded because an attacker operating a reverse proxy can capture and replay them within the validity window. Rolling out phishing-resistant MFA across all users, important data repositories and privileged access is one of the larger pieces of work in an ML3 programme, both technically and in terms of user enrolment and lost-key recovery processes.

Eliminating unsupported software

Maturity Level Three keeps the ML2 patch timeframes and adds an uncompromising requirement: unsupported and end-of-life applications and operating systems must be removed. If a product can no longer receive vendor security updates, it cannot be patched within any timeframe and therefore cannot satisfy the strategy.

This is where legacy line-of-business applications, old database engines and aging network appliances become a board-level issue rather than a technical inconvenience. The remediation options are limited: upgrade, replace, or rigorously isolate behind compensating controls while a migration is planned. Our deep dive on patching applications and operating systems explains how to track exposure and prioritise these retirements.

Application control at its strictest

Application control at ML3 applies to workstations and internet-facing servers, covering executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets across the entire filesystem, not just user-writable folders. Crucially, ML3 requires that allowed and blocked execution events are centrally logged, protected from modification and monitored.

ML3 also expects that Microsoft’s recommended application blocklist of known vulnerable and exploitable drivers and executables is implemented, and that allowlist rulesets are validated at least annually. This combination is what stops an attacker from running tooling they have smuggled onto a host. Building and maintaining a clean allowlist at this scale is demanding, which is why we recommend reading our application control guide before committing to an ML3 timeline.

Macro hardening, logging and backups at the top tier

Microsoft Office macros at ML3 must be blocked unless there is a demonstrated business need, must run only from trusted locations with limited write access or be digitally signed by a trusted publisher, and macros from the internet must be blocked. Antivirus scanning of macros is enabled, users cannot change settings, and execution including failures and blocks is logged. The full configuration is set out in our macro hardening playbook.

Logging reaches its most comprehensive at ML3. Event logs from workstations, servers, internet-facing services and internet-facing applications are centrally collected, retained, protected from modification and deletion, and monitored for signs of compromise with timely detection of cyber security events. Backups are similarly hardened: performed and retained per business requirements, resilient to ransomware, with restoration tested when implemented and at least annually, and with unprivileged and even most privileged accounts unable to modify or delete backups.

Privileged access and user hardening at the top tier

Restricting administrative privileges reaches its strictest form at ML3. Privileged access is granted only after validation, is automatically disabled after twelve months unless revalidated, and is disabled after forty-five days of inactivity. Privileged users operate from a secured administrative environment, and privileged accounts are prevented from accessing the internet, email and web services. Privileged access to systems, applications and data repositories, along with the use of privileged accounts, must be centrally logged and monitored. Jump servers or privileged access workstations, just-in-time access and a hardened credential vault are typically required to meet this.

User application hardening is equally uncompromising. Browsers block Java and web advertisements, Internet Explorer 11 is removed, .NET Framework 3.5 and below is disabled where not needed, PowerShell module logging, script block logging and transcription are enabled, command-line process creation events are logged, and Office and PDF software are locked down against OLE and other risky features. The logging of these hardening measures feeds directly into the detection capability ML3 demands, turning hardening from a purely preventive measure into a source of detection signal.

Detection and response expectations

Although the Essential Eight is fundamentally a prevention framework, Maturity Level Three’s logging and monitoring requirements imply a real detection and response capability. Centrally collected, protected logs are only valuable if someone, or some tooling, is analysing them to detect signs of compromise in a timely manner. In practice this means a SIEM with tuned use cases, alerting that reaches a responder around the clock, and a tested incident response plan. Organisations that deploy the logging but never operationalise the monitoring meet the letter of the requirement while missing its intent, and an experienced assessor will probe exactly that gap.

Sustaining Maturity Level Three is the real challenge

Many organisations can deploy ML3 controls; far fewer keep them at ML3 a year later. Maturity decays through ordinary change. A new application gets an exception. A logging source falls silent after a migration. An allowlist rule is loosened to fix an urgent issue and never tightened again. Left unmanaged, this drift quietly drops the organisation back to ML2 or worse.

Sustaining ML3 therefore depends on operational discipline rather than one-off engineering:

• Continuous monitoring of control health, so a broken logging feed or a disabled policy is detected in hours, not months.
• Strict change control that treats any loosening of application control, MFA or macro policy as a risk decision with an owner and a review date.
• Annual validation of allowlists, restoration tests and privileged access reviews, with evidence retained for assessment.
• Periodic independent reassessment against the current ACSC wording, because the Essential Eight model is itself updated over time.

A realistic path to ML3

The sensible route to Maturity Level Three is to consolidate ML2 across all eight strategies first, then uplift each strategy to ML3 in a planned sequence, leaving the most disruptive items, typically phishing-resistant MFA rollout and legacy software retirement, with the most runway. Report maturity per strategy and resist the temptation to claim ML3 overall until every strategy genuinely meets it.

ML3 is most relevant to government agencies, critical infrastructure and higher-risk private sector organisations. If you need to reach and hold this level, independent assurance matters, because internal teams rarely have time to police their own drift. CISO Advisory can run the gap assessment, build the roadmap and provide ongoing oversight through our virtual CISO service. Call 07 2112 8502 or reach us via the contact page to discuss your target maturity.