ASD Essential 8 Maturity Level 2 and 3: A Practical 2026 Roadmap for Australian CISOs

The Australian Signals Directorate updated the Essential Eight Maturity Model in late 2023, and the Federal Court used it as a reasonable-steps benchmark in Australian Information Commissioner v Australian Clinical Labs Limited (No 2) [2025] FCA 1224, the 8 October 2025 decision that produced the first ever Privacy Act civil penalty of A$5.8 million. Non-corporate Commonwealth entities have been bound to Maturity Level 2 under the Protective Security Policy Framework since July 2022, and tender panels, insurers and APRA letters now treat ML2 as the floor for anyone touching Commonwealth, super or critical infrastructure work.

The complication is that the maturity model is no longer a tick-box. ML2 now demands phishing-resistant MFA and centralised event logging, ML3 demands hardware-enforced application control and tighter patching windows for internet-facing services, and the OAIC has shown in the ACL case that it will treat assessment delay and notification delay as separate s 13G contraventions. CISOs are being asked to attest controls that their MSPs cannot evidence and their boards cannot read. This roadmap walks through which maturity level Australian regulators, insurers and Commonwealth tenders actually require in 2026, what ML2 and ML3 look like control-by-control, how to sequence a 90-day uplift, what audit evidence the ACSC and your assessor expect to see, and what a per-control uplift programme actually looks like for a mid-sized Australian organisation.

Every Australian CISO conversation starts in the wrong place: pick a target level before mapping which controls the business actually consumes. The ACSC defines four levels (ML0 through ML3), with ML0 reserved for organisations with material weaknesses across most of the eight mitigations. ML1 protects against adversaries using widely available commodity tradecraft, ML2 protects against adversaries willing to invest more time and tooling, and ML3 protects against adversaries who are adaptive and target a specific organisation.

Non-corporate Commonwealth entities have been mandated to ML2 under the Protective Security Policy Framework since July 2022. Commonwealth tender panels and the defence industry supply chain now treat ML2 as the floor, with ML3 expected for systems handling PROTECTED data or above. State government procurement increasingly references the Essential Eight as the technical baseline.

APRA does not mandate the Essential Eight in CPS 234, but the June 2025 letter from Deputy Chair Margaret Cole to RSE Board chairs cited phishing-resistant MFA, an Essential Eight ML2 requirement, as the new baseline after credential-stuffing attacks on AustralianSuper, Rest, Insignia and UniSuper. Cyber insurers writing in the Australian market routinely price ML2 attestation into renewal terms. The pragmatic 2026 split: if you sell to Commonwealth or state government, hold sensitive personal data under APP 11.1, or operate a SOCI responsible entity, target ML2 across all eight mitigations within 12 months and ML3 on the four highest-priority controls (MFA, restrict admin privileges, patch applications, patch OS) within 24 months. Anything less and your reasonable-steps defence under s 13G of the Privacy Act looks thin against the ACL precedent.

The single hardest control to operationalise, and the one assessors probe first. At ML2, application control must be implemented on workstations and internet-facing servers, restrict the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set, and use Microsoft's recommended block rules or the ACSC's published rules.

ML3 adds non-internet-facing servers to the scope, requires hardware-enforced application control where it is supported (Windows Defender Application Control with HVCI, or equivalent), and demands that allow-list rule sets be validated annually. Drivers must be allow-listed; Microsoft's recommended driver block rules must be implemented at ML2 and above.

Audit evidence the ACSC and your assessor will ask for: the allow-listing tool inventory (AppLocker policy XML, WDAC policy binaries, or third-party tooling such as Airlock Digital, ThreatLocker or VMware Carbon Black), the rule set itself, change-control records showing rule additions are reviewed, event logs (Event ID 8002/8003 for AppLocker, 3076/3077 for WDAC) shipped to a central SIEM, and a deny-event sample from the last quarter. Common failure modes Australian assessors flag: allow-listing in audit-only mode for years (does not count as implemented), excluding the C:\ProgramData and user profile paths (creates an LOLBin highway), and signing-certificate based rules that are too permissive. Budget six to nine months for a clean rollout on a 1,500-seat estate. Validate the allow-list under real attacker tradecraft before you attest, so the deny events you ship to the SIEM reflect controls that have actually been tested.

The two patching controls produce more failed assessments than any other pair. ML2 requires patching, updating or otherwise mitigating internet-facing services and online services within 48 hours of exploit availability, and other applications within one month. ML3 tightens the same window for internet-facing services to 48 hours from vulnerability disclosure (not just exploit availability) and requires that an automated method of asset discovery is used at least fortnightly.

For operating systems, ML2 demands 48-hour patching of internet-facing OS instances on exploit availability, one month for workstations and servers, and that operating systems no longer supported by vendors are replaced. ML3 adds the fortnightly automated asset discovery and 48-hour patching on disclosure for internet-facing OS.

Audit evidence: a current asset register from an automated discovery tool (Tenable, Qualys, Rapid7, Microsoft Defender for Endpoint Vulnerability Management), vulnerability scan output produced no more than 14 days old, a patch-deployment report keyed to CVE-ID with timestamps, and a documented exception register for any host outside SLA. The ACSC publishes vulnerability advisories; your evidence pack must show prioritised CVEs closed within the ML window. A common board-level miss: cloud SaaS dependencies. After the June 2025 Qantas Salesforce vishing breach that exposed 5.7 million customer records via the Scattered Lapsus$ Hunters campaign on a Manila call-centre operator, OAIC scrutiny now expects the patching evidence pack to include SaaS configuration baselines (MFA on the OAuth flow, Data Loader restrictions, IP-allow-listed admin); patching is not just an on-prem story.

The two browser and Office controls are the easiest wins on paper and the most often misconfigured in practice. ML2 blocks Microsoft Office macros for users with no demonstrated business requirement, blocks macros in files originating from the internet, blocks Win32 API calls from Office macros, allows only macros from Trusted Locations or digitally signed by a trusted publisher, and logs allowed and blocked macro execution centrally. ML3 adds that the trusted publisher list is verified annually and that Antimalware Scan Interface (AMSI) integration is enforced.

User application hardening at ML2 disables Internet Explorer 11, configures web browsers to block web advertisements, Java from the internet and OLE in Office files, hardens PowerShell with constrained language mode and module/script-block logging, and logs PowerShell execution centrally. ML3 extends hardening to block .NET Framework 3.5 (and below) where not required, enforces Windows PowerShell 2.0 removal, and centrally logs command-line process creation events. Audit evidence: Group Policy or Intune configuration profile exports, ASR rule reports from Defender for Endpoint (specifically the four Office-related ASR rules), AMSI provider registration evidence, sample event logs showing macro block events ingested into SIEM. Two practical traps: legacy finance teams running 20-year-old XLS macros (you will need a Trusted Locations carve-out with explicit business owner sign-off), and consultants on BYOD laptops who bypass managed policy entirely. Both must appear in your exception register before assessment. Phishing simulations that drop a macro-laden payload into the estate are the cleanest way to prove enforcement to a sceptical board.

The two identity controls are where the ACL case, the Medibank proceedings and the APRA RSE letter all converge. ML2 requires that privileged accounts be validated at least every 12 months, prevented from accessing the internet, email and web services, separated from unprivileged accounts, and that just-in-time administration is used. ML3 adds privileged access workstations (PAWs), credential elevation logging, and that unprivileged accounts cannot logon to privileged operating environments.

For MFA, ML2 now requires phishing-resistant MFA, meaning FIDO2 security keys, smart cards, Windows Hello for Business, or equivalent, for users authenticating to important data repositories, internet-facing services, third-party services that process the organisation's sensitive data, and customer-facing services. ML3 mandates phishing-resistant MFA for all privileged user actions and all users of important systems.

Audit evidence: identity provider configuration export (Entra ID Conditional Access policies, Okta authentication policies), enrolment reports showing 100% coverage of in-scope users, FIDO2 or smart card inventory with serial numbers, MFA bypass exception register, privileged access management tool reports (CyberArk, Delinea, BeyondTrust) showing JIT session counts. After the 2024-25 credential-stuffing wave that drove APRA's Deputy Chair to require all RSE Board chairs to self-attest by 31 August 2025, expect every Australian assessor to test for SMS or TOTP as the only MFA factor on customer-facing services and mark it as a finding. The Financial Accountability Regime makes the named Accountable Person personally liable for this control. Pair the rollout with a SOC capability that ingests MFA fatigue and impossible-travel signals; 24x7 monitoring covers the post-2am window where credential attacks cluster.

The control most boards underfund until ransomware lands. ML2 requires that backups of important data, software and configuration settings are performed and retained in accordance with business continuity requirements, that backups are stored in a coordinated and resilient manner (immutable, offline or appropriately air-gapped), that restoration testing occurs at least annually, and that unprivileged accounts cannot access backups belonging to other accounts or modify and delete their own backups.

ML3 adds quarterly restoration testing, the requirement that privileged accounts (except backup administrators) cannot access backups belonging to other accounts, and that backup administrator accounts cannot modify or delete backups during their retention period. Centralised event logging, now an ML2 baseline since the 2023 maturity model update, requires event logs from internet-facing servers, non-internet-facing servers and workstations to be centrally collected, protected from unauthorised modification and deletion, and analysed in a timely manner.

Audit evidence: backup policy document, retention schedule mapped to data classification, immutability configuration (S3 Object Lock, Azure Immutable Blob, Veeam Hardened Repository), restoration test reports with timing and integrity hash, a sample restore from the past 12 months with a witness signature, SIEM ingestion dashboards showing event volumes by source, and a log retention policy mapped to the ISM's required retention for security-relevant events. The Cyber Security Act 2024 ransomware payment reporting obligation that commenced 30 May 2025 (72-hour clock, up to 60 penalty units or approximately A$19,800 for non-compliance) makes restoration testing a board-level concern, not an IT housekeeping task. If you cannot restore within RTO, the pressure to pay rises, and the disclosure obligation snaps in.

The realistic Australian timeline if you are starting at ML1 across the board, with a CISO, two security engineers and an MSP partner. Days 1 to 14: stand up the assessment baseline. Run a self-assessment using the ACSC Essential Eight Assessment Process Guide, score every control at ML0, ML1, ML2 or ML3, and prioritise the gap closest to a regulatory cliff (usually MFA and patch applications). Lock the asset register.

Days 15 to 45: deploy phishing-resistant MFA. Order FIDO2 keys (Yubico, Token2) for privileged users and high-risk staff in week three, configure Entra ID Conditional Access or Okta policy to require a phishing-resistant factor on the four ML2 in-scope categories, run a two-week pilot, then enforce. In parallel, stand up an automated patch pipeline (Intune, WSUS with Patch My PC, or Tanium) for the 48-hour and one-month windows.

Days 46 to 75: roll out application control in audit mode across a pilot ring, harden PowerShell (constrained language mode, transcription logging), tighten Office macro settings via Intune ASR rules, and ship the resulting events to a central SIEM (Microsoft Sentinel, Splunk, Elastic). Validate that backups are immutable and run the first quarterly restore test. Days 76 to 90: enforce application control, close the privileged-account inventory under just-in-time administration (PIM in Entra ID, CyberArk, Delinea), produce the evidence pack mapped to each control statement, and book an independent assessment. The independent assessment is what insurers, tender boards and OAIC investigators want to see; your own self-attestation has lost weight after the ACL judgment. Map every control to a specific APP 11.1 reasonable-steps narrative so the same evidence covers your privacy obligations.

The implied ROI of an Essential Eight ML2 uplift is straightforward when stacked against the active enforcement docket. The Federal Court awarded A$5.8 million against Australian Clinical Labs for a breach affecting 223,000 individuals, allocating A$4.2 million for failure to take reasonable steps under s 13G and APP 11.1, A$0.8 million for delayed assessment, and A$0.8 million for delayed NDB notification.

The OAIC has pleaded one contravention per affected individual in both the Medibank (9.7 million Australians, breach period March 2021 to October 2022) and Optus (approximately 9.5 million customers, 2019 to 2022) proceedings, with a per-contravention maximum of A$2.22 million. APRA has separately imposed a A$250 million additional operational risk capital charge on Medibank, the largest cyber-related prudential charge to date in Australia. From 10 June 2025 the statutory tort for serious invasions of privacy added a standalone cause of action that sits entirely outside the OAIC pathway. The OAIC received A$8.7 million over three years in the 2025 budget for enforcement uplift.

Cost benchmarking for ML2 uplift varies widely with estate size, existing tooling and how much of the work is delivered by an MSP; the disciplined sequence below is what shrinks the bill. Recommended sequence: MFA first (highest impact, lowest tooling cost, directly cited in the APRA letter and the ACL judgment), then patch applications and patch OS (closes the public-exploit window), then admin privileges and event logging (delivers the audit trail), then macros and user application hardening, with application control and backups last because they take longest to operationalise cleanly. Build the evidence pack against the control statements as you go, not at the end; assessors penalise reconstructed evidence. Certbar Security runs ML2 and ML3 uplift programmes for Australian organisations from CERT-In empanelled delivery centres in Surat and Mumbai, with assessors who have mapped the Essential Eight to APP 11.1, CPS 234, SOCI CIRMP and the Cyber Security Act 2024. The offshore delivery model produces a meaningful cost reduction against equivalent onshore consultancies, and a 24x7 SOC coverage window that catches credential-stuffing and MFA-fatigue activity in the post-2am Australian window. If you are running an AI-assisted control such as a copilot agent that touches in-scope data, layer the AI risk review on top of the Essential Eight uplift so the ADM transparency requirement that commences 10 December 2026 lands cleanly. Pair the uplift with ongoing VAPT services to prove the controls hold under adversarial pressure.