Reaching Essential Eight Maturity Level 2: From Configuration to Discipline

Where ML1 defends against commodity intrusion, Maturity Level 2 assumes the adversary is trying to defeat your controls on purpose. The controls that sat on workstations extend onto servers. The logging that ML1 did not ask for becomes mandatory. Authentication has to become phishing-resistant.

This article is adapted from the S5 whitepaper Reaching Essential Eight Maturity Level 2 (vendor-agnostic edition, v1.8). It covers what ML2 demands, what clears the bar in any stack, and a 90-day path from an assessed ML1 baseline.

---

Where configuration becomes an operating discipline

Maturity Level 2 is the level ASD’s Australian Cyber Security Centre defines against adversaries with a modest step-up in capability: attackers willing to invest more time in a specific target, to refine their tools, and to actively hunt credentials with phishing and work around weak multi-factor authentication.

ML2 is also where a great many mid-market organisations should be aiming. It is the level that cyber insurers increasingly price against, the level named in more sophisticated supplier questionnaires, and a credible stepping stone for organisations that serve government or critical-infrastructure customers without yet needing ML3. ASD is explicit that the Essential Eight mitigates the majority of commonly encountered cyber threats. The eight strategies are drawn from ASD’s broader Strategies to Mitigate Cyber Security Incidents; each maturity level is designed to sit on top of the one before it.

The Essential Eight measures controls, not products, and more than one credible stack clears the ML2 bar. This series names platform features where the maturity model or the native platform requires them, and recommends no third-party products.

Seven themes that run through the ML2 requirements

The server estate joins in. Application control moves onto internet-facing servers, and the policy that covered user profiles and temporary folders at ML1 now has to cover every other location too.

Logging is no longer optional. At ML2, several strategies (among them application control, restrict administrative privileges, multi-factor authentication and user application hardening) carry central-logging clauses in the model’s own requirement text, and the event logs must be protected from unauthorised modification and deletion. The incident chain attaches to those same strategies at ML2: events analysed in a timely manner to identify incidents, incidents reported to the CISO or a delegate and to ASD, and the incident response plan enacted. If you did not design the log path at ML1, this is the largest single work item in the uplift.

Authentication must become phishing-resistant. ML2 requires phishing-resistant MFA for users of online services and for users of systems, including workstation logon, and requires that customers of your online customer services be offered a phishing-resistant option. The model excludes weaker factors from these clauses; push approvals and SMS-delivered codes are the common examples of what stops qualifying.

Privileged access becomes time-bound and observed. Privileges expire after 12 months unless revalidated and after 45 days of inactivity. Administration runs through jump servers. Credentials for break-glass, local administrator and service accounts must be long, unique and managed. The privileged environment may no longer be virtualised inside the unprivileged one.

The long tail of applications gets covered. ML2 extends scanning and patching to all other applications: at least fortnightly scanning, patched within one month. The third-party patching gap that ML1 lets you defer stops being deferrable.

Backups lose their administrator-shaped hole. From ML2, privileged accounts other than backup administrators cannot access, modify or delete backups.

Macros and user applications tighten. Macro execution is blocked from making Win32 API calls. Office and PDF child-process, executable-content and code-injection blocking, and OLE package activation prevention, join the ML1 browser lockdown. PowerShell and command-line logging go to the central store.

What ML2 costs that ML1 does not

The honest answer for planning purposes: mostly operational, not capital. The platforms that carried your ML1 posture largely carry ML2 too, if they can do four things: extend policy from workstations to servers, export their events to a SIEM, enforce phishing-resistant authentication, and time-box privileged access. The first uplift effort goes into logging architecture and the phishing-resistant key distribution exercise, and the first uplift headcount goes into whoever reads the logs.

Organisations that chose centrally managed policy platforms at ML1, rather than hand-maintained rule sets, feel the difference immediately at this level. The server estate multiplies the rules, and manual maintenance stops scaling.

What the baseline means at ML2

Keyed to the ASD Essential Eight Maturity Model, November 2023 release (the current published model); capability-language paraphrase, not quotation. ML2 is where the Essential Eight stops being a user-level control set and becomes a centrally governed one. The step up from ML1 is not more of the same: the model shifts the emphasis to management of the environment, with central enforcement, wider coverage and faster response times for the highest-risk exposures.

In capability terms, an organisation at ML2 has:

• Application control on workstations and internet-facing servers, with Microsoft’s recommended application blocklist, and rules reviewed at least annually.
• Patching driven by fixed windows carried from ML1: 48 hours for vulnerabilities that are critical or have working exploits on online services, two weeks for high-risk application classes and non-critical issues on internet-facing systems, and a defined monthly window for everything else.
• Vulnerability scanning extended to the long tail of applications at least fortnightly, with patches inside one month.
• Execution restricted to an organisation-approved set, so unapproved software cannot run. Driver and firmware vulnerability management is not part of ML2; it arrives at ML3.
• Office macro restrictions enforced centrally, not by user choice: macros from the internet blocked, macro execution blocked from making Win32 API calls, and the policy protected from tamper.
• User application hardening centrally enforced with no user override, covering browsers, PDF readers and Office.
• Phishing-resistant MFA for users of online services and for users of systems, including workstation logon, with a phishing-resistant option offered to customers; weaker factors excluded.
• Backup access closed to every privileged identity except the backup administrators.

The management layer is what auditors probe first at ML2: central enforcement with no user override, evidence that the new timelines are actually being met, and event logging to prove the controls operated.

A 90-day path from ML1 to ML2

The sequence below presumes an ML1 baseline that is assessed, not assumed. It puts the two load-bearing ML2 workstreams (logging architecture and phishing-resistant authentication) first, because everything else generates the evidence they carry.

Days 0 to 30: foundations of evidence and identity. Pick or confirm the SIEM destination. Define the required event classes (application-control allow/deny, PowerShell script-block and module logging, command-line process creation, privileged access and account management, MFA success/failure, and the internet-facing server event streams those clauses point at). Stand up the protected retention path on day one. Pilot phishing-resistant MFA for the admin and privileged cohort first. Re-platform the privileged environment if it is virtualised inside the unprivileged one. Design jump servers and the credential-management decision for break-glass, local admin and service accounts. Deploy application control on internet-facing servers in observe-only mode, and import Microsoft’s recommended blocklist as the floor. Run the quarterly DR exercise against the ML1 standard so the evidence is current at assessment.

Days 30 to 60: extension and enforcement. Application control enforced on internet-facing servers and applied to all locations on workstations, exceptions through the approval workflow, allow/deny stream live in the SIEM. Patch pipeline extended to the long tail of applications: fortnightly scan, one-month window. Office, PDF and browser hardening settings configured centrally, with exceptions documented and time-boxed. Privileged access lifecycle live: revalidation at 12 months, disable at 45 days of inactivity, admin activity routed through jump servers. Macro Win32 API blocking enabled fleet-wide, and the phishing-resistant rollout widened to all staff and to workstation logon, with the customer-facing phishing-resistant option published.

Days 60 to 90: operation, evidence, verification. The incident chain in production: alerting rules mapped to the required event classes, a documented analysis and escalation runbook, the CISO delegate named and contactable, ASD reporting details registered, and the IR plan exercised against one simulated incident end to end.

---

The argument in one sentence

ML2 is won when logging, phishing-resistant authentication and time-bound privileged access are designed as operating discipline, not bolted on after the assessment date.

This is the third in a series adapted from S5’s Essential Eight papers. Earlier articles cover the five-phase journey and Maturity Level 1. Later articles cover Maturity Level 3 and how to select an implementor.

The full whitepaper is available on request. If you are planning the step from ML1 to ML2, start with the log path, the authentication strength you can actually enforce, and whether privileged access still lives inside the unprivileged estate.

In this series

1. The Essential Eight Journey
2. Reaching Essential Eight Maturity Level 1
3. Reaching Essential Eight Maturity Level 2
4. Reaching Essential Eight Maturity Level 3
5. The Essential Eight has a successor. Here’s what changes.
6. Selecting an Essential Eight Implementor
7. From the Essential Eight to ASD Essentials: a practical transition guide

Get the complete Essential Eight whitepaper series

Fill in the form below and we will send through the full six-paper set: the Journey, Maturity Levels 1, 2 and 3, Selecting an Implementor, and the Transition Guide.