Reaching Essential Eight Maturity Level 3: Prove the Controls Never Lapse

Maturity Level 3 is where the Essential Eight stops asking what you deployed and starts asking how well you run it. Almost every ML3 clause has a recurring process attached to it. The assessment will look for the process records as much as the configuration.

This article is adapted from the S5 whitepaper Reaching Essential Eight Maturity Level 3 (vendor-agnostic edition, v1.8). It covers what ML3 demands, what clears the bar, and a 90-day path from an assessed ML2 baseline.

---

Designed against adaptive adversaries

Maturity Level 3 is the level ASD’s Australian Cyber Security Centre defines against adaptive adversaries: actors much less reliant on public tools, able to exploit weaknesses in your posture such as older software or inadequate logging, willing to invest effort in circumventing your specific controls, and willing and able to destroy all data including backups.

The ML3 requirements answer that threat model directly: execution controls extended to every server and to drivers, credentials protected in hardware and in memory, telemetry from every machine class read continuously, and backups locked down even from the people who administer them.

ML3 is the right target for organisations whose compromise would be a serious event: entities serving government or critical-infrastructure supply chains, regulated finance and healthcare, operators of significant assets, and any organisation whose insurer or largest customer has started asking for independent Essential Eight assessment. It is also the level where the program becomes a discipline rather than a project.

The Essential Eight measures controls, not products, and more than one credible stack clears the ML3 bar. This series names platform features where the maturity model or the native platform requires them, and recommends no third-party products.

Six themes that run through the ML3 requirements

No machine is out of scope. Application control now covers non-internet-facing servers as well as workstations and internet-facing servers, is applied to all locations, and adds driver restriction on top of Microsoft’s recommended application blocklist with the vulnerable driver blocklist. The estate is covered or it is not.

The patch regime becomes prescriptive about currency. Driver and firmware vulnerabilities join the scan-and-patch rhythm at their own 48-hour and one-month windows. Workstation and internal-server operating systems inherit the 48-hour rule for exploited or vendor-critical vulnerabilities. The 48-hour rule reaches the office suite and browser categories themselves. Supported operating systems must be at the latest or previous release. Patched but ancient no longer passes.

The admin model becomes the centre of gravity. Secure Admin Workstations, just-in-time administration and memory-protection features (memory integrity, Local Security Authority protection, Credential Guard and Remote Credential Guard) layer on top of the ML2 jump-server and credential-management model. Privileged access is additionally limited to only what is required, per user and per service.

Identity covers the data itself. At ML3, MFA extends to users of data repositories, and it must be phishing-resistant there too. Customer authentication moves from offered a phishing-resistant option to phishing-resistant outright. Telemetry obligations widen from internet-facing servers to every machine class: non-internet-facing servers and workstations are now analysed in a timely manner as well.

Macros are trusted or they do not run. The ML3 macro clauses replace blanket blocking with a signing and sandboxing regime: macros execute only from a sandbox, a Trusted Location, or when digitally signed by a trusted publisher, under a managed process with malicious-code checking, restricted write access to Trusted Locations, V3-signature-only trust, and an annually validated publisher list.

Backups lock even the backup administrators. Retention-period modification and deletion is prevented at the storage layer, including for backup administrators.

What ML3 costs that ML2 does not

Less than the headlines suggest, if you came up through ML2 with the carry-forward decisions made deliberately. The dominant new costs are architectural (secure admin workstation fleet, repository-level MFA coverage, retention-locked backup stores), operational (the analysis rota now covers every machine class, and the signing and validation rituals need owners), and evidentiary (an ML3 assessment samples across all three machine classes and expects the process records as well as the policy exports).

Organisations that designed toward ML3 during ML2 typically find this level a completion rather than a rebuild. Organisations that treated ML2 as the end state will find the last twenty percent disproportionately heavy, which is exactly the argument for choosing the target level as a risk decision at the start and designing toward the top of the model either way.

What the baseline means at ML3

Keyed to the ASD Essential Eight Maturity Model, November 2023 release (the current published model); capability-language paraphrase, not quotation. ML3 is designed against adversaries that are well resourced and adaptive, so the theme is consistency: the controls that ML2 applied to the riskiest slice of the estate now apply estate wide, timelines shorten, and the trust placed in any single component is reduced.

In capability terms, an organisation at ML3 has:

• Application control across all servers and workstations, including non-internet-facing ones, with Microsoft’s recommended application blocklist estate-wide and blocked-execution events logged, and with driver allowlisting alongside the application-control policy, the vulnerable driver blocklist consumed automatically.
• The 48-hour critical-patch window applied to every device class, with unsupported software removed and anything not yet removed on a dated, approved exception register.
• Driver and firmware vulnerability management, scanned and patched to their own 48-hour and one-month windows across the estate.
• Macro policy built on conditional trust: sandboxed execution, Trusted Locations, signing by trusted publishers, V3 signatures only, and an annually validated publisher list.
• User application hardening applied estate wide, with .NET Framework 3.5 and Windows PowerShell 2.0 removed and PowerShell in Constrained Language Mode by default.
• Phishing-resistant MFA carried from ML2 and extended: now required for users of data repositories, and mandatory rather than merely offered for customers of online customer services.
• Backups that backup administrators cannot modify or delete during the retention period, enforced at the storage layer.

At ML3 the audit question changes from “are the controls present” to “can you prove they never lapse”: completeness of coverage, evidence for every timeline, and the absence of standing privileges.

A 90-day path from ML2 to ML3

The sequence below presumes an assessed ML2 baseline. It front-loads the two slow-burning structural items (the admin device program and the repository MFA inventory) because everything else attaches to them, and it ends with the evidence pack and the independent assessment, because at ML3 the claim is worth exactly what the artefacts support.

Days 0 to 30: structure and inventory. Secure admin workstation program: hardware decision, build baseline with the memory-protection clauses switched on at build, privileged cohort enrolled first. Just-in-time administration: platform decision and pilot on one system class, with request, approval, time-box and log wired end to end. Data-repository register: every repository of sensitive data, its authentication path, its owner, its logging status. Driver and firmware reporting switched on in the vulnerability platform. Backup retention-lock design: store-level immutability with a compliance-class lock, retention control separated from the backup-admin role. Macro trust-regime design written down before anything is signed.

Days 30 to 60: extension and enforcement. Application control enforced on non-internet-facing servers; driver allowlisting in audit mode with the vulnerable driver blocklist already implemented. The 48-hour windows live for the office-suite category and for internal operating systems. Firmware and driver patch cadence operating fortnightly. Constrained Language Mode and the removal of .NET Framework 3.5 and Windows PowerShell 2.0 rolled through the estate with exceptions time-boxed.

Days 60 to 90: evidence and assessment. Process records assembled: validations, reviews, analyses, exercises. Telemetry analysis covering every machine class. The independent assessment booked against artefacts that already exist, not against a scramble to produce them.

---

The argument in one sentence

ML3 is won when coverage is estate-wide, privileges are temporary, and every timeline has a process record you can produce on demand.

This is the fourth in a series adapted from S5’s Essential Eight papers. Earlier articles cover the five-phase journey and Maturity Levels 1 and 2. The last article covers how to select an implementor.

The full whitepaper is available on request. If ML3 is the bar your customers or insurer now name, start with the admin device program, the repository MFA inventory, and whether backup retention is enforced at the storage layer.

In this series

1. The Essential Eight Journey
2. Reaching Essential Eight Maturity Level 1
3. Reaching Essential Eight Maturity Level 2
4. Reaching Essential Eight Maturity Level 3
5. The Essential Eight has a successor. Here’s what changes.
6. Selecting an Essential Eight Implementor
7. From the Essential Eight to ASD Essentials: a practical transition guide

Get the complete Essential Eight whitepaper series

Fill in the form below and we will send through the full six-paper set: the Journey, Maturity Levels 1, 2 and 3, Selecting an Implementor, and the Transition Guide.