Essential Eight Maturity Model: How to Progress From Level 1 to Level 2

Reaching Maturity Level 1 across the Essential Eight is an achievement. The controls are in place, staff are broadly aware, and the organisation can demonstrate that baseline security hygiene exists. The mistake many organisations make after Level 1 certification is underestimating how much more Level 2 demands. Level 2 is not a marginal increment. It introduces automation requirements, stricter timeframes, and enforced technical controls where Level 1 often accepted policy-based assurance.

We work with Australian organisations progressing from Level 1 to Level 2 regularly. The common thread is that the gap looks manageable from a distance and proves harder once the detailed requirements are read carefully. This article covers what changes for each control and where to focus effort first.

Patching: From Best Effort to Defined Timeframes

At Maturity Level 1, organisations are expected to patch applications and operating systems within a reasonable time. At Level 2, that becomes defined timeframes: critical vulnerabilities in internet-facing services must be patched within 48 hours, and non-critical vulnerabilities across all assets within two weeks. Many organisations at Level 1 have informal patching processes. Level 2 requires that those processes are automated and that evidence of patch completion can be produced against specific CVEs and patch dates.

The remediation work is not just process change. It involves deploying or configuring vulnerability scanning across the full asset inventory and ensuring that the scan outputs are linked to a tracked patching workflow. Organisations frequently discover at this point that their asset register is incomplete. Level 2 assessment requires that the scanned environment matches the documented environment. Closing the gap between those two things is often the most time-consuming piece of the Level 2 uplift programme.

Application Control: From Policy to Enforcement

Maturity Level 1 for application control requires that an application control policy exists and that it is applied to standard user workstations. Level 2 requires that application control is applied consistently across all workstations and servers and that the implementation specifically prevents execution of unapproved software from user-writable directories. That distinction matters. Many Level 1 implementations allow standard users to install from defined package sources. Level 2 blocks execution from temp directories, downloads folders, and user profiles.

The uplift work typically involves reviewing your application control ruleset and identifying the directories that are currently excluded from control. Developer machines and build servers are common exception points. At Level 2, those exceptions must be logged, approved, and time-limited rather than standing open. Organisations also discover that some legacy line-of-business applications execute from paths that application control blocks. Remediating those requires vendor engagement or application repackaging, both of which take time to schedule.

Restricting Administrative Privileges: From Role Review to Technical Enforcement

At Level 1, restricting administrative privileges requires that privileged access is reviewed, that accounts are assigned on the basis of least privilege, and that administrative accounts are not used for general email and browsing. At Level 2, the standard requires that the restriction on email and browsing for privileged accounts is technically enforced, not just policy-stated. That is a material change. Level 1 allows you to say that admins should not browse the web from privileged accounts. Level 2 requires that they cannot.

Implementing this typically means deploying separate workstations or enforcing restrictions through your endpoint management platform. Organisations in the public sector often have one workstation per user and a policy against using privileged accounts for browsing. The Level 2 requirement means that policy enforcement needs to be automated. The configuration work is straightforward once scoped, but it can affect operational workflows significantly. Engaging staff early reduces friction at deployment.

Multi-Factor Authentication and Backup Restoration

MFA at Level 1 applies to internet-facing services for most users. At Level 2, it applies to all internet-facing services without exception and to all privileged access. Organisations often have one or two legacy systems that are excluded from MFA at Level 1. The Level 2 uplift requires those systems to be brought into scope or formally decommissioned. Conditional access policy configuration, identity provider audit logs, and a full system inventory with MFA status against each system are the expected evidence artefacts.

For backups, Level 2 adds the requirement that restoration is tested and that the test result is documented. Many organisations at Level 1 can show that backups completed. Fewer can show that a restoration test was performed and that the outcome was recorded with the data recovered confirmed as usable. Scheduling an annual restoration test and retaining the output as evidence is a simple change in process but needs to be planned and executed before an assessment is due. To discuss your Essential Eight Level 2 uplift programme, contact Cyberlinx at info@cyberlinx.com.au.