ASD Essential Eight to Maturity Level 3: A Practical Path

What Maturity Level 3 actually demands across the eight strategies, why the ML2-to-ML3 step is hardest, and a sequencing approach that works.

The Essential Eight looks deceptively simple: eight mitigation strategies, four maturity levels, one assessment model. The difficulty is concentrated in one place — the step from Maturity Level 2 to Maturity Level 3, where the model stops rewarding tooling and starts demanding operational discipline. This is a practical view of that step.

What ML3 is actually for

ASD’s maturity model is threat-anchored: each level targets increasingly capable adversary tradecraft, with ML3 aimed at actors who are more adaptive and selective in their targeting. That framing matters for scoping. ML3 is the right target when your threat model includes capable, persistent adversaries — typical for government, critical infrastructure and high-value enterprise environments. It is not automatically the right target for every organisation; an honest threat assessment comes first.

The eight, and where ML3 bites

Across application control, patching applications, configuring Microsoft Office macro settings, user application hardening, restricting administrative privileges, patching operating systems, multi-factor authentication and regular backups, the ML3 step consistently demands the same three things:

1. Coverage without exceptions. Controls that were “workstations mostly” at lower maturity must extend across the fleet — servers included for application control, and the long tail of legacy systems that resisted earlier waves.
2. Speed. Patching obligations tighten sharply where exploits exist for internet-facing services — the timeframes at higher maturity are measured in hours and days, not patch cycles. Meeting them is an operations problem, not a scanner purchase.
3. Resistance to capable attackers. MFA must be phishing-resistant; privileged access must be tightly governed and separated; backups must survive an adversary who holds privileged credentials; logging and monitoring must be centralised and protected from tampering.

The pattern: ML1 and ML2 can be substantially bought. ML3 must be operated.

The gaps that stall ML2→ML3 programs

Independent assessments keep finding the same blockers: application control that quietly excludes servers; a legacy application that keeps macro or hardening exceptions alive; administrative privilege that is “restricted” on paper but re-granted permanently in practice; backup regimes that have never been tested against a privileged-attacker scenario; and patching pipelines that cannot hit exploit-driven timeframes for the systems that matter most.

A sequencing approach that works

• Assess honestly first. A rigorous current-state assessment against the ML3 requirements — including the exceptions register — is worth more than a year of assumed progress. Self-assessment optimism is the number-one cause of failed uplift programs.
• Attack the exceptions, not the average. ML3 is defined by your worst-covered systems. Ring-fence, remediate or retire the legacy estate that holds the exception list open.
• Fix privileged access and backups early. They are the controls that decide whether an intrusion becomes a catastrophe, and they take the longest to operationalise.
• Build the evidence as you go. ML3 must be demonstrable — coverage data, timeframe metrics, test results — not asserted.

Key takeaways

• ML3 targets adaptive adversaries; choose it because your threat model warrants it.
• The ML2→ML3 step is about coverage, speed and adversary-resistance — operational discipline more than product.
• Exceptions define your maturity level; the legacy estate is the real project.
• Assess honestly, evidence continuously.

Use our ML3 Readiness Checklist to structure a self-assessment, see where the Essential Eight sits in the wider compliance landscape, or commission an independent Essential Eight assessment.