Essential Eight Maturity Level 3: What It Actually Takes
A practical breakdown of what reaching Essential Eight ML3 requires — common pitfalls, realistic timelines, and what most organisations underestimate.
The gap between ML2 and ML3 is bigger than it looks
Most organisations that have reached Essential Eight Maturity Level 2 assume ML3 is a natural next step — just tighten a few controls and move on. In practice, the jump from ML2 to ML3 is the hardest transition in the maturity model. It demands architectural changes, operational discipline, and a level of monitoring that many organisations have never implemented.
ML2 is about having the right controls in place. ML3 is about proving those controls work consistently, detecting when they fail, and responding to adversary techniques that are specifically designed to bypass them.
Where organisations get stuck
Application control
At ML2, application control means whitelisting on workstations. At ML3, it extends to all servers, including internet-facing services. The challenge isn’t the technology — it’s the operational overhead. Every application update, every legitimate script, every scheduled task needs to be accounted for. Organisations without a mature change management process will struggle here.
The common mistake: deploying application control in audit mode and never switching to enforcement because the exception list keeps growing. If the exception list is unmanageable, the underlying application inventory is incomplete.
Patching within 48 hours
ML3 requires patching internet-facing services within 48 hours of a critical vulnerability being identified. Not 48 hours from when the vendor releases a patch — 48 hours from when the vulnerability is known to be exploited or when a working exploit exists.
This means organisations need a vulnerability intelligence capability, not just a patch management tool. Someone needs to be watching for actively exploited vulnerabilities and triggering an emergency patching process outside the normal cycle.
For most SMEs, this is the single hardest ML3 requirement to sustain operationally.
Multi-factor authentication
ML3 MFA requirements go beyond “turn on MFA for all users.” The requirement specifies phishing-resistant MFA — FIDO2 security keys or platform authenticators. SMS and app-based push notifications don’t meet the bar.
This has hardware cost implications (security keys for every user) and user experience implications (training, lost key processes, fallback procedures). Plan for a 3-6 month rollout with a dedicated change management effort.
Logging and monitoring
This is where ML3 separates serious security programs from checkbox exercises. ML3 requires centralised logging, log protection (so adversaries can’t tamper with evidence), and monitoring for signs of compromise. Logs need to be retained and actually reviewed — not just collected.
Organisations need to define what “monitoring” means in their context. A SIEM collecting logs that nobody reviews is an expensive compliance artifact, not a security control.
Realistic timelines
For an organisation that has genuinely achieved ML2 — not just ticked the boxes, but has working controls — a realistic timeline to ML3 is 12-18 months. That assumes:
- Dedicated project resourcing (not “the IT team will handle it alongside BAU”)
- Executive sponsorship with real budget authority
- An existing asset inventory that is reasonably accurate
- Willingness to accept operational friction during the transition
Organisations that try to compress this into a 6-month sprint typically end up with controls that work on paper but fail under scrutiny — or worse, fail during an actual incident.
What to do before starting
Before committing to an ML3 program, run an honest assessment against your current ML2 controls. Not a self-assessment — get someone independent to validate that your ML2 implementation is solid. Common findings:
- Application control is deployed but has broad exceptions that effectively bypass it
- Patching metrics look good on average but miss critical patches in the 48-hour window
- MFA is enabled but falls back to SMS for “special” accounts
- Admin accounts are separated on paper but share credentials or have standing access that should be just-in-time
Fix these gaps first. An ML3 program built on a weak ML2 foundation will consume twice the budget and deliver half the result.
The payoff
ML3 is hard, but it’s hard for a reason. The controls at this level genuinely reduce the attack surface against sophisticated adversaries — not just opportunistic attackers. Organisations that achieve ML3 have a meaningfully different security posture from those that stop at ML2.
The Australian Signals Directorate designed the maturity model this way deliberately. ML3 represents the level at which an organisation can defend against tradecraft that is specifically tailored to bypass their environment. That’s a high bar, and it should be.
The question isn’t whether ML3 is worth pursuing. It’s whether the organisation is ready to commit the resources and accept the operational changes required to get there — and stay there.