Essential Eight Maturity Level 3: What ‘Good’ Actually Looks Like

Most Australian organisations I assess are somewhere between Maturity Level One and Maturity Level Two across the Essential Eight strategies. Many have been working toward ML2 for years. When the conversation turns to Maturity Level Three, the response is usually the same: "We know we need to get there, but we are not sure what it actually requires."

This article bridges that gap. It explains what ML3 demands in practice — not the ASD maturity model definitions (which you can read yourself), but what it actually looks like to implement, sustain, and evidence ML3 in a real operational environment. It is based on hundreds of Essential Eight assessments across government, defence industry, and critical infrastructure.

If you are at ML2 and planning your path to ML3, or if you have been told you need ML3 and want to understand the effort involved, this is written for you.

The Fundamental Shift: ML2 to ML3

The jump from ML2 to ML3 is not incremental. It is a qualitative change in how your organisation approaches security. At ML2, you are implementing security controls. At ML3, you are operationalising them — with automation, continuous validation, and evidence that controls are effective over time.

Three themes characterise the ML2-to-ML3 shift:

• Automation over manual process — controls that can be manually satisfied at ML2 must be automated at ML3. Monthly manual patching reviews become automated vulnerability scanning with 48-hour SLAs.
• Centralised logging and monitoring — ML3 requires centralised logging of security-relevant events across almost every strategy. If you cannot prove a control is operating through log evidence, you are not at ML3.
• Scope expansion — ML2 focuses primarily on workstations. ML3 extends controls to servers, requiring application control, hardening, and patching across your entire server estate.

Where Organisations Stall on the ML3 Journey

Based on the assessments I have conducted, these are the strategies and requirements where the ML3 journey consistently breaks down:

1. The 48-Hour Patching Window

Patching internet-facing services within 48 hours of a critical vulnerability being identified is the single most operationally demanding ML3 requirement. It requires automated vulnerability scanning, a pre-approved emergency change process, tested rollback procedures, and sufficient environment redundancy to patch without downtime. Organisations that rely on monthly patch cycles or manual change advisory board approvals cannot meet this cadence.

2. Phishing-Resistant MFA

The shift from any-MFA (ML2) to phishing-resistant MFA (ML3) requires a hardware token rollout. FIDO2 security keys are the most common approach. This means procuring tokens for every user, enrolling them, updating helpdesk procedures for lost tokens, and ensuring all applications in scope support FIDO2. Legacy applications that only support username/password or SMS OTP become blockers.

3. Privileged Access Workstations

ML3's requirement that privileged accounts cannot access the internet, email, or web services effectively mandates Privileged Access Workstations (PAWs) or a tiered administration model. This is an architectural change, not a configuration change. Many organisations have built their entire operational model around admins using a single account for everything. Unpicking that requires role redesign, separate hardware or VDI, and significant change management.

4. Application Control on Servers

ML2 requires application control on workstations. ML3 extends this to servers. Server application control is fundamentally more complex — servers run diverse workloads, third-party applications, scheduled tasks, and automated deployments. Defining and maintaining an application control policy for a server estate without blocking legitimate operations requires extensive baselining and ongoing rule management.