The Australian Cyber Security Centre’s Essential Eight is deliberately tiered, and Maturity Level Two is where most organisations discover the framework has real teeth. Maturity Level One can often be reached by tidying up existing tooling. Maturity Level Two demands automation, evidence and consistency across every one of the eight mitigation strategies. It is the step that separates intent from operational reality, and it is the one we see underestimated most often.
If you are still mapping the basics, our plain-English guide to the Essential Eight is the best place to start before reading on. This article assumes you already understand the eight strategies and the maturity model, and focuses on what ML2 actually requires.
What Maturity Level Two is designed to stop
Each maturity level is defined by the sophistication of the adversary it is meant to mitigate, not by how much effort the organisation puts in. Maturity Level One is aimed at adversaries using widely available, commodity tradecraft who will move on to easier targets. Maturity Level Two is aimed at adversaries willing to invest a little more time and to tailor their approach to a specific target.
In practice that adversary will attempt to steal and reuse credentials, will exploit known vulnerabilities before you have patched them, and will use modest evasion techniques to avoid noisy detection. The controls at ML2 are calibrated to remove the easy footholds that this kind of attacker relies on. That is why the level emphasises faster patching, broader multi-factor authentication, real logging and verified backups, rather than simply doing the same controls a bit better.
The patch timeframes tighten significantly
The single biggest shock for most teams is the patching cadence. At Maturity Level Two the ACSC expects:
- 48 hours to patch or mitigate critical vulnerabilities in internet-facing services, online applications such as web browsers and email clients, and other internet-facing software when a working exploit exists.
- Two weeks to patch other applications and operating systems on workstations, servers and network devices where no exploit is yet circulating.
- More frequent vulnerability scanning using an automated scanner with an up-to-date vulnerability database, run at least fortnightly for most assets and daily for internet-facing services.
These timeframes apply to two separate Essential Eight strategies: patch applications and patch operating systems. Meeting them by hand is effectively impossible at scale, which is why ML2 forces organisations into automated patch deployment and reporting. Our detailed walkthrough of meeting the Essential Eight patch timeframes covers the tooling and exception process in depth.
Multi-factor authentication expands its reach
At Maturity Level One, MFA is required for users accessing internet-facing services and for privileged actions. At Maturity Level Two the scope widens. MFA is required for all users of internet-facing services, for users accessing important data repositories, and for privileged users of systems. It must use something the user has in addition to something they know or are, and the authentication events must be logged.
The common gap here is not technical, it is coverage. Organisations roll MFA out to email and the VPN, declare victory, and overlook the finance system, the document management platform or the legacy line-of-business application holding sensitive records. ML2 will not accept partial coverage. Note that phishing-resistant MFA, such as FIDO2 security keys or passkeys, is not mandatory until Maturity Level Three, but adopting it early at ML2 saves rework later.
Restricting administrative privileges becomes structural
Admin privilege restriction at ML2 moves from policy to architecture. Privileged accounts must be validated when first requested and revalidated periodically. Privileged users must use separate, unprivileged accounts for everyday tasks such as email and web browsing, and privileged accounts must be prevented from accessing the internet, email and web services directly. Privileged access to systems and applications must also be logged.
This usually means standing up dedicated administrative workstations or a privileged access workstation model, plus a credential vault. It is one of the more disruptive changes culturally, because it removes the convenience of a single all-powerful account that many IT teams have relied on for years.
Application control and macro hardening get stricter
Application control at Maturity Level Two must be applied to workstations, and the allowed set is no longer just executables. It extends to software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets in standard user profile and temporary folders. Allowed and blocked execution events should be logged. For a structured rollout approach, see our practical guide to application control.
Microsoft Office macros also tighten. At ML2, macros are blocked for users with no business requirement, macros from the internet are blocked, macro antivirus scanning is enabled, and users cannot change macro security settings. Macro execution events are logged. Many organisations are surprised that “we disabled macros” is not enough on its own; the configuration must be enforced through policy and evidenced. Our macro hardening playbook sets out the exact settings.
Logging and backups become verifiable, not theoretical
Two requirements quietly trip up otherwise well-prepared organisations. The first is logging. ML2 requires that event logs from internet-facing services and from internal systems are centrally collected, protected against unauthorised modification and deletion, and actively monitored for signs of compromise. Logging locally on each box does not satisfy this; the logs must be aggregated and someone must be looking at them.
The second is backups. At ML2, backups of important data, software and configuration must be performed and retained in line with business continuity requirements, stored in a way that is resilient to ransomware, and tested through restoration at least once when first implemented and then annually thereafter. Unprivileged accounts must be unable to access or modify backups belonging to other accounts. The discipline being tested is restoration, not just the existence of a backup job.
Application hardening and disabling untrusted code
User application hardening also steps up at Maturity Level Two. Web browsers must be configured to block or disable Java from the internet and to block web advertisements, Internet Explorer 11 must be disabled or removed, and browser security settings must be locked so users cannot weaken them. Microsoft Office must be configured to prevent activation of OLE packages, and PDF software hardened so it cannot run unnecessary code. These settings, like the macro controls, must be enforced centrally and protected from user change, and the relevant events should be logged.
The reason this matters at ML2 is that the more capable adversary the level targets will probe for exactly these weaknesses, using browser plugins, OLE objects and document features as execution paths when application control alone does not catch them. Treating application hardening as a defence-in-depth layer rather than an afterthought is part of what distinguishes a genuine ML2 posture from a checklist one.
The governance and cost reality of ML2
It is worth being candid that Maturity Level Two is as much an organisational change as a technical one. Several of its requirements, separate privileged accounts, locked-down macro and hardening settings, automated patch deployment, change the way IT and end users work day to day. That generates friction, and friction without executive backing tends to produce exceptions that erode the controls.
The organisations that succeed treat ML2 as a funded programme with a named owner, a budget for tooling such as a patch automation platform and a SIEM or log aggregation service, and visible support from leadership. They also accept ongoing operational cost: logging needs monitoring, patches need testing, and allowlists and exceptions need maintenance. Underestimating this run cost is the single most common reason an organisation reaches ML2 on paper and then slips back within a year.
How to approach the climb to Maturity Level Two
The organisations that reach ML2 smoothly treat it as a programme rather than a project, and they tend to follow a similar sequence:
- Run an honest gap assessment against all eight strategies, measured against the actual ML2 wording rather than a generic summary. Partial credit is not awarded.
- Fix the foundations first. Centralised logging, automated patching and a credential vault underpin several strategies at once, so they deliver the most leverage.
- Stage application control and macro changes in audit or monitoring mode before enforcing, to avoid breaking legitimate business workflows.
- Prove the backups with a documented restoration test, and keep the evidence.
- Maintain the evidence trail. ML2 is assessed on demonstrable, repeatable controls, so screenshots, policy documents and logs matter as much as the technical configuration.
Measuring and reporting your maturity honestly
Maturity under the Essential Eight is assessed and reported per strategy, not as a single overall score, and the ACSC recommends reaching a target level across all eight strategies before claiming it. This matters because the temptation at ML2 is to over-report. An organisation that has automated patching and broad MFA but logs only locally is not at ML2 overall, however strong those two strategies are.
Honest reporting also serves you internally. A per-strategy heat map gives leadership a clear, fundable picture of where the gaps are, and it stands up to external scrutiny from a customer’s due diligence, an insurer or a regulator. Inflated self-assessments tend to unravel exactly when the stakes are highest, such as after an incident.
Maturity Level Two is achievable for almost any Australian organisation, but it rewards planning and punishes shortcuts. If you would like an independent assessment of where you sit and a realistic roadmap to ML2, CISO Advisory can help. Our virtual CISO service is built to drive exactly this kind of uplift, and you can reach us any time on 07 2112 8502 or through our contact page.
Frequently asked questions
What is the main difference between Maturity Level One and Two?
ML1 mitigates adversaries using commodity, opportunistic techniques. ML2 targets adversaries who invest more effort and are more selective, often using credential theft and basic evasion. The jump means tighter patch windows, stronger MFA, centralised logging and verified backups rather than the lighter, partial controls accepted at ML1.
How fast must we patch at Maturity Level Two?
For internet-facing services and applications with known exploits, critical vulnerabilities are patched within 48 hours. Other applications and operating systems are patched within two weeks. Vulnerability scanning frequency also increases, so ML2 requires automation rather than manual, periodic patching cycles to stay compliant.
Does Maturity Level Two require phishing-resistant MFA?
Not strictly. Phishing-resistant MFA becomes mandatory at Maturity Level Three. At ML2, MFA must be applied more broadly, including to important data repositories, and must use something users have plus something they know or are. It must also be logged, but it need not yet be phishing-resistant.
Is logging really part of Maturity Level Two?
Yes. ML2 requires that event logs from internet-facing services, plus key system and security events, are centrally collected, protected from modification and monitored for signs of compromise. This is one of the most commonly missed requirements, because many organisations log locally but never aggregate or actually review the data.
How long does it take to reach Maturity Level Two?
For a mid-sized organisation starting from ad-hoc controls, six to twelve months is realistic once tooling and governance are in place. The pace depends mostly on legacy applications, change-management maturity and whether application control and centralised logging already exist. Rushing it usually produces gaps that an assessment exposes.
Need this handled for your organisation?
Confidential and no obligation. We respond the same business day — on-site same day / next business day, or remote, Australia-wide. Prefer to talk now? Call us 24/7 on 07 2112 8502.