Maturity Level 3 is not ML2 with extras — it's a fundamentally different class of implementation.
The ASD Essential Eight Maturity Model defines four levels — ML0 through ML3 — each calibrated to a different adversary profile. ML1 handles commodity threats: mass phishing, widely available exploit kits, opportunistic ransomware. ML2 handles adversaries who invest effort — they harvest credentials, move laterally, and target specific organisations. ML3 is designed for highly adaptive adversaries who develop custom tooling, exploit zero-day vulnerabilities, and invest significant resources to bypass security controls.
The architectural shift at ML3 is scope expansion. Controls that ML2 applies to internet-facing or high-risk assets, ML3 applies everywhere. Patching windows that ML2 measures in weeks, ML3 compresses to 48 hours. MFA that ML2 requires for online services and workstations, ML3 extends to data repositories. Application control that ML2 applies to workstations and internet-facing servers, ML3 applies to every server in your environment.
The November 2023 update to the Essential Eight Maturity Model expanded ML3 from roughly 29 discrete requirements to 69. Organisations that believed they were approaching ML3 under the previous model may find themselves significantly further away under the current one.
What ML3 is designed for: Organisations operating in high-threat environments where sophisticated, well-resourced adversaries — including state-sponsored actors — represent a credible and ongoing risk. Critical infrastructure providers, defence industry participants, organisations processing national security information, and financial institutions with significant nation-state exposure.
What ML3 is not: A gold standard that every organisation should aspire to. A well-implemented ML2 provides genuine, measurable protection for most Australian businesses. Pursuing ML3 without the threat profile to justify it diverts resources from controls that would deliver more actual security value.
Even the mandated ML2 baseline is beyond most government agencies — and the data tells you why ML3 is a different conversation entirely.
Before discussing what ML3 requires, it's worth understanding the current state of Essential Eight adoption in Australia. The data comes from Commonwealth Cyber Security Posture reports (published by ASD) and Australian National Audit Office (ANAO) performance audits.
Commonwealth Government compliance
The percentage of non-corporate Commonwealth entities achieving ML2 across all eight strategies has been volatile: 25% in 2023, dropping to 15% in 2024 when the November 2023 update hardened requirements, then recovering to 22% in 2025. The drop from 25% to 15% is particularly revealing — a stricter definition of the same maturity level caused a third of previously-compliant agencies to fall below the bar, without any change to their actual security posture.
59% of Commonwealth entities report that legacy IT impedes their ability to implement the Essential Eight. Only 35% of entities report at least half of their observed incidents to ASD — a compliance requirement they're already failing at ML2.
The self-assessment accuracy gap
ANAO performance audits have consistently found a significant gap between self-assessed and independently verified compliance. Across four audits spanning 2013–2022, 60% of agencies self-assessed as compliant while only 29% were independently verified. In one 2019–20 audit, only 1 of 18 federal agencies had achieved ML3.
This accuracy gap matters for any organisation considering ML3. If government agencies with dedicated assessment programmes are consistently overestimating their maturity, private sector organisations conducting self-assessments are almost certainly doing the same.
The threat context
ASD's 2024–25 Annual Cyber Threat Report records over 1,200 cyber security incidents (up 11%), a 111% rise in critical infrastructure notifications, and average self-reported costs of $56,600 per incident for small businesses. Victorian Government analysis found that 84% of reported cyber incidents could have been prevented or significantly minimised by implementing at least one Essential Eight control.
ML2 vs ML3 — a side-by-side comparison of what changes and why it matters.
The pattern across all eight strategies is consistent: ML3 extends scope, tightens timelines, and introduces advanced architectural controls entirely absent from ML2.
| Control dimension | ML2 requirement | ML3 requirement |
|---|---|---|
| Critical patch — applications | Within 2 weeks | Within 48 hours |
| Critical patch — OS (non-internet-facing) | Within 1 month | Within 48 hours |
| Driver and firmware patching | Not required | 48 hours for critical vulnerabilities |
| Application control scope | Workstations + internet-facing servers | All servers (including non-internet-facing) |
| MFA scope | Online services + workstations | + Data repositories |
| Admin privilege controls | Jump servers, annual revalidation | + SAWs, JIT admin, Credential Guard, HVCI, LSA Protection |
| Backup modification access | Backup admins only | Break glass accounts only |
| Event log analysis scope | Internet-facing servers | All workstations and servers |
| OS version requirement | Vendor-supported | Latest or N-1 release only |
| PowerShell | Module and script block logging | + Constrained Language Mode enforced |
| Office macro signatures | Signed macros only | V3 digital signatures only |
The effort multiplier is not linear. Moving from ML1 to ML2 is a significant project. Moving from ML2 to ML3 is a transformation programme. The scope expansion alone — from "internet-facing and high-risk" to "everything" — means every exception, every legacy system, and every edge case tolerated at ML2 becomes a compliance gap at ML3.
What each of the eight strategies requires at ML3 — and where organisations get stuck.
Not a restatement of ASD's requirements document. A practitioner assessment of what each strategy actually demands in implementation, where the common blockers lie, and what catches organisations that thought they were ready.
Application control must be enforced on all servers — not just workstations and internet-facing servers. Drivers must be included. All execution events must be centrally logged. Windows Defender Application Control (WDAC) required — AppLocker not acceptable.
Extending to non-internet-facing servers means contending with every line-of-business application, every scheduled task, and every legacy script. WDAC policies must account for driver signing, introducing hardware vendor dependencies. The logging requirement generates significant SIEM volume.
Legacy applications with unsigned executables. These require vendor engagement (slow), custom signing (risky), or managed installer rules (complex). Often the most critical business applications are the ones that break first.
Critical patches for office productivity suites, browsers, email clients, PDF software, and security products must be applied within 48 hours when a vendor assesses as critical or when a working exploit exists.
A 48-hour window leaves no room for standard testing. The test-in-dev, deploy-to-staging, validate, push-to-production cycle collapses. Either patch untested (breakage risk) or invest in automated testing pipelines that can validate in hours (expensive).
Change Advisory Board processes designed for weekly or fortnightly cycles. Achieving 48-hour patching requires either pre-approved emergency change processes or a fundamental redesign of change management.
Only V3 digital signatures are acceptable — V1 and V2 must be prevented. Write access to Trusted Locations is restricted to privileged users responsible for checking macros for malicious content.
Many organisations have years of business-critical macros signed with older formats. Migrating to V3 requires re-signing every macro, which first requires auditing every macro for malicious or unintended content.
Unsigned or V1/V2-signed macros embedded in critical business processes with no documented owner. Finding and remediating these is detective work, not an IT project.
.NET Framework 3.5 and PowerShell 2.0 must be disabled. PowerShell Constrained Language Mode must be enforced. PowerShell and command-line logging must be centrally collected and analysed across all workstations and servers.
PowerShell CLM breaks a significant number of legitimate administrative scripts. IT teams that rely on PowerShell for automation — which is most IT teams — will find their existing tooling stops working.
Administrative automation built on unrestricted PowerShell. The team responsible for implementing the control is often the team most affected by it.
Widely regarded as the most challenging strategy at ML3. Requires Secure Admin Workstations (SAWs) for all administrative activities, Just-in-Time (JIT) administration across systems, and enabling Memory Integrity (HVCI), LSA Protection, Credential Guard, and Remote Credential Guard.
SAWs are dedicated machines used exclusively for admin tasks — no email, no web browsing. For a team of 10 admins, that's 10 additional hardened machines. JIT requires PAM tooling. The Credential Guard suite introduces driver compatibility issues.
Cost. A SAW programme for a mid-sized organisation runs into six figures before accounting for the PAM platform, operational overhead, and productivity impact on administrators managing two separate workstations.
48-hour critical patching extends to all workstations and non-internet-facing servers. Drivers and firmware must be scanned fortnightly with critical patches applied within 48 hours. Organisations must run the latest or previous (N-1) OS release.
Firmware patching is operationally complex — BIOS/UEFI updates require restart cycles affecting production systems. The N-1 requirement means OS upgrades cannot be deferred.
The N-1 OS requirement. Organisations with hardware or applications certified only for specific OS versions face a choice between Essential Eight compliance and operational compatibility.
Phishing-resistant MFA extends to data repositories — databases, file shares, SharePoint libraries, cloud storage. Phishing-resistant means cryptographically bound: FIDO2 security keys, Windows Hello for Business, or smart cards. SMS and push notifications are not acceptable.
Many SaaS applications do not support FIDO2 natively. Hardware token logistics — procuring, distributing, managing FIDO2 keys across a workforce — is a non-trivial operational programme.
Legacy application integration. The application that stores your most sensitive data is often the one with the weakest authentication options.
Only break glass accounts — not regular backup administrators — can modify or delete backups. Break glass accounts must have unique, long, unpredictable passphrases, stored securely, and tested regularly.
Requires backup solutions with granular RBAC capable of separating "create/restore" from "modify/delete." Not all enterprise backup platforms offer this natively.
Backup platform limitations. If your current backup solution doesn't support the required access segregation, ML3 may require a platform migration — a project in itself.
The five ML3 controls that cause the most implementation friction — ranked by practitioner experience.
Not all ML3 requirements are equally difficult. Based on assessment and implementation experience across Australian organisations, these are the five that consistently cause the most friction and the most project delays.
SAWs require dedicated hardware, network segmentation, and complete separation of administrative and productivity activities. JIT requires PAM tooling, workflow automation, and cultural change across IT operations. Together they represent the single largest cost and complexity item in any ML3 programme. Expect six-figure investment for a mid-sized organisation, plus ongoing operational overhead.
At ML2, 48-hour patching applies to internet-facing systems — a manageable subset. At ML3, it applies to everything. Your change management process, testing pipeline, deployment tooling, and on-call roster all need to accommodate emergency patching at a pace most organisations have never sustained.
The scope extension to data repositories exposes every authentication gap in your environment. Applications you never considered "online services" suddenly need FIDO2 support. Hardware token procurement and logistics for every user, replacement programmes, and helpdesk training create an operational programme running in parallel with the technical implementation.
Server workloads are more diverse and less predictable than workstation workloads. Database servers, application servers, CI/CD infrastructure, and utility servers all run different software stacks that must be allowlisted. WDAC policy management across a heterogeneous server estate requires dedicated tooling and ongoing governance. A single misconfigured policy can take a production server offline.
Not because the configuration is complex — it isn't — but because the impact on operational workflows is immediate and widespread. Administrative scripts break. Deployment tools fail. Monitoring agents malfunction. Every team managing Windows infrastructure is affected. The remediation involves rewriting scripts, implementing exemptions, or restructuring how administrative automation works.
Do you actually need Essential Eight Maturity Level 3?
This is the question that most Essential Eight guides avoid — because the answer, for most organisations, is no.
ML3 is designed for highly adaptive, well-resourced adversaries who develop custom tooling, exploit zero-day vulnerabilities, and invest significant effort to compromise specific targets. That describes nation-state actors, sophisticated criminal syndicates targeting high-value organisations, and advanced persistent threats directed at critical infrastructure.
- ✓You process, store, or transmit national security information
- ✓You're a DISP member handling classified material
- ✓You operate critical infrastructure where compromise has national-level consequences
- ✓You're an APRA-regulated entity with a threat profile including state-sponsored actors
- ✓Your organisation has been specifically targeted by sophisticated adversaries with evidence
- ✓Customers or regulators explicitly require ML3 as a contractual condition
- ✕Your primary threats are commodity ransomware, phishing, and opportunistic attacks
- ✕You haven't achieved a well-implemented, independently verified ML2 yet
- ✕Your organisation lacks budget for SAWs, PAM tooling, and dedicated security operations
- ✕Your legacy environment has significant technical debt that ML2 would already address
- ✕No customer, regulator, or contractual requirement specifies ML3
The honest advice: A well-implemented ML2 — genuinely implemented, not just documented — provides strong protection for the vast majority of Australian organisations. If your ML2 has gaps, exceptions, or areas of self-assessed compliance that haven't been independently verified, those gaps represent more real-world risk than the absence of ML3 controls. Fix ML2 first. Then assess whether the threat environment warrants ML3.
A poorly implemented ML3 is less secure than a well-implemented ML2. Maturity level is not a score — it's a measure of consistent, verifiable control implementation across your environment.
The seven patterns that delay or devalue Essential Eight ML3 programmes.
These patterns appear consistently across assessments — in organisations of every size and every sector.
- ✕ Pursuing ML3 before ML2 is solid
Organisations that target ML3 while their ML2 has known gaps are building on sand. The November 2023 update demonstrated this — when requirements were hardened, a third of previously-compliant agencies dropped below ML2. Ensure ML2 is independently verified, not just self-assessed, before committing to ML3.
- ✕ Overestimating current maturity
ANAO data shows 60% of agencies self-assessed as compliant while only 29% were independently verified. If you haven't had your Essential Eight maturity independently assessed by someone without a stake in the outcome, your actual maturity is likely lower than you believe.
- ✕ Treating it as a technology project
ML3 requires technology, but also process redesign (48-hour patching), cultural change (administrators using SAWs), governance reform (break glass procedures), and sustained executive commitment (multi-year funding). Organisations that frame ML3 as "deploy these tools" consistently underestimate the effort by 50% or more.
- ✕ Ignoring the lowest strategy
An organisation's overall Essential Eight maturity equals its lowest-performing strategy. Achieving ML3 on seven strategies and ML1 on one means overall maturity is ML1. Yet organisations routinely over-invest in strategies they're already good at while neglecting the difficult ones.
- ✕ Underestimating legacy system impact
59% of Commonwealth entities report that legacy IT impedes Essential Eight implementation. At ML3, legacy systems aren't just an inconvenience — they're a compliance blocker. Applications that can't support WDAC, servers that can't run current OS versions, systems that can't enforce phishing-resistant MFA — each requires remediation, replacement, or an exception that weakens your overall posture.
- ✕ Inadequate SIEM and logging capacity
ML3 requires centralised collection and timely analysis of event logs from all workstations and servers. The log volume at ML3 scope is an order of magnitude greater than at ML2. Organisations that didn't right-size their SIEM infrastructure face either massive cost overruns or compliance gaps in their logging strategy.
- ✕ No ongoing programme ownership
Essential Eight compliance is not a project with an end date. ML3 requires continuous process execution — 48-hour patching cycles, ongoing privilege revalidation, regular break glass testing, continuous event log analysis. Without a dedicated programme owner and sufficient BAU resource, ML3 compliance degrades within months of achievement.
Essential Eight + ISO 27001 + APRA CPS 234 — how they fit together.
Australian organisations in regulated environments frequently navigate multiple overlapping frameworks. Understanding how they complement each other — rather than treating each as an independent compliance exercise — avoids duplication and maximises security value.
The Essential Eight is prescriptive and technically focused — eight mitigation strategies with measurable maturity levels. ISO 27001 is a risk-based ISMS covering governance, people, processes, and technology across 93 controls.
The most effective approach is to implement the Essential Eight as the technical baseline while using ISO 27001 for the governance and management framework. The Essential Eight tells you what technical controls to implement. ISO 27001 tells you how to manage those controls within a documented, auditable management system.
An organisation with Essential Eight ML3 but no ISMS has strong technical controls but no management framework. An organisation with ISO 27001 but weak Essential Eight maturity has a well-documented system managing inadequate controls. Both are incomplete.
CPS 234 is mandatory for all APRA-regulated entities and requires information security capabilities commensurate with threats. It does not explicitly reference the Essential Eight, but its principles align closely — access control, incident management, and testing.
In practice, financial institutions commonly use the Essential Eight as the technical implementation framework for demonstrating CPS 234 compliance. CPS 234 adds governance elements the Essential Eight lacks: board-level accountability, third-party risk management, and 72-hour incident notification to APRA.
For APRA-regulated entities, the question is not "Essential Eight or CPS 234?" — it's how to implement both efficiently.
Regulatory mandates by sector
| Sector / Jurisdiction | Essential Eight obligation |
|---|---|
| Federal Government (NCEs) | ML2 mandatory under Protective Security Policy Framework |
| Defence industry (DISP) | ML2 mandatory (uplifted from Top 4 in October 2024) |
| NSW Government | ML1 minimum under NSW Cyber Security Policy |
| Queensland Government | Essential Eight mandatory under IS18, maturity targets based on risk |
| Critical infrastructure (SOCI Act) | Must adopt recognised cybersecurity framework — Essential Eight is one option |
| APRA-regulated entities | Not explicitly mandated — but most commonly adopted technical framework for CPS 234 compliance |
What the Cliffside approach to Essential Eight assessment and uplift actually looks like.
We hold ISO/IEC 27001:2022 certification ourselves. We assess Essential Eight maturity for Australian organisations across government, financial services, and critical infrastructure. We understand the difference between documented compliance and genuine implementation — because we've seen both, assessed both, and helped organisations move from one to the other.
Our approach starts with the Lighthouse Assessment — a comprehensive, multi-specialist evaluation of your current Essential Eight maturity against ASD's requirements. The output is an independently verified maturity rating for each of the eight strategies, a prioritised gap analysis, and an honest assessment of what ML3 will require for your specific environment — including whether ML3 is the right target.
We'll tell you honestly:
- →Your verified maturity level for each strategy — not what you hope it is, what it actually is
- →Whether ML3 is appropriate for your threat profile, or whether a robust ML2 delivers more value
- →Which strategies will cause the most friction in your environment and why
- →Realistic timeline and resource estimates based on your specific legacy systems and budget
- →How Essential Eight uplift integrates with your existing ISO 27001 or APRA CPS 234 programmes
- →Where your self-assessed maturity differs from independently verified maturity — and what that means
If the honest answer is "you need to fix ML2 before you talk about ML3," we'll say that. If the honest answer is "ML3 isn't justified for your threat profile and here's a better use of that budget," we'll say that too.