Reaching Essential Eight Maturity Level 1: What the Baseline Actually Demands

October 13, 2026

Update, 15 October 2026: ASD has released ASD Essentials, the evolution of the Essential Eight. The Essential Eight remains current during the transition, and everything in this post still applies.

Read what changes →

Most organisations that stall on Essential Eight do not stall on a missing product. They stall on a baseline they have never treated as a program: eight strategies, a named bar, and evidence that can be produced again when someone asks.

This article is adapted from the S5 whitepaper Reaching Essential Eight Maturity Level 1 (vendor-agnostic edition, v2.0). It covers what ML1 actually demands, what clears the bar in any stack, and a 90-day path from a standing start to a posture you can defend.

The baseline every conversation starts at

Maturity Level 1 is the Essential Eight baseline: a defined set of controls that stands between an ordinary business and the ordinary attacks that break into ordinary businesses.

The Australian Signals Directorate’s Australian Cyber Security Centre designed the Essential Eight around the way most compromises actually happen. Not nation-state toolchains, but commodity tradecraft: an unpatched internet-facing system, a stolen password reused once too often, a macro-enabled attachment opened on a Friday afternoon. ML1 targets that adversary specifically.

ASD’s own wording is that the Essential Eight can help mitigate the majority of cyber threats, while being equally clear that it will not mitigate all of them. The eight strategies are drawn from ASD’s broader Strategies to Mitigate Cyber Security Incidents, and each maturity level is designed to sit on top of the one before it.

ML1 is not what it used to be, and that matters. Separated privileged and unprivileged admin environments are a current ML1 requirement. The November 2023 release tightened ML1 patching windows and added the vendor-rated-critical trigger to the 48-hour rule for online services, which had previously keyed on working exploits alone. ML1 is a stronger and more serious baseline than its reputation. It is also the level insurers ask about, the level that shows up in supplier questionnaires, and increasingly the floor named in contracts flowing down from government and critical-infrastructure customers.

The Essential Eight measures controls, not products. More than one credible stack clears the bar. The paper states what each strategy requires, what evidence proves it, and what to look for when evaluating any platform against it. This series names platform features where the maturity model or the native platform requires them, and recommends no third-party products.

Five themes that run through the ML1 requirements

Workstations and browsers first. ML1 aims application control, macro settings and browser hardening at the user estate, where commodity malware lands. Application control is the anchor control on that estate, whatever delivers it.

Internet-facing gets the short leash. Daily scanning and a 48-hour window for exploited or vendor-critical vulnerabilities on online services, from ML1.

Admin separation is no longer optional. Dedicated privileged accounts on separate environments are a current ML1 requirement.

MFA without the acronyms. A second factor on the organisation’s own online services and sensitive third-party ones. Push or app is acceptable here; phishing resistance arrives at ML2.

Backups you have actually restored. A tested recovery to a common point in time in a disaster exercise, and ordinary users fenced off other people’s backups.

What clears the bar, in any stack

The instinct when an assessment comes back with findings is to buy another product. In our experience ML1 is achievable with a short set of capabilities that is already half-familiar: the security controls that matter are policy, patching and separation. Those capabilities carry forward into ML2 and ML3 rather than being replaced on the way up. Over-tooling at this level creates licence sprawl and alert fatigue, both of which make the eventual ML3 assessment harder.

Where a capability has both a native and a third-party route (application control is the clearest), the decision is yours to make on operational grounds, not on logos.

Application control: an audit-first allowlisting capability (native WDAC/AppLocker, or a third-party platform with one); an exception approval workflow; a single allow/deny decision log; EDR alongside, not instead.
Patch applications: a vulnerability scanner with continuous asset discovery; a Windows patch pipeline that admits what it does not cover; a named answer for third-party applications; Apple-native management for macOS.
Office macro settings: centrally locked Microsoft 365 Apps policy; attachment inspection at the mail gateway; an optional secondary macro-blocking path on platforms already deployed.
User application hardening: centrally locked browser policy as the primary control; agent-based filtering or SSE for off-network users; gateway filtering as supporting coverage.
Restrict administrative privileges: separate privileged identities with conditional access; privilege-escalation management to make local-admin removal workable; network segmentation for the admin plane; a vault priced as the later step.
Patch operating systems: the same scanner and inventory; update management per platform, with network devices in the same register.
Multi-factor authentication: the MFA already included with the productivity licence, enabled now; a cross-platform capability where the estate is mixed; a phishing-resistant path confirmed for ML2.
Regular backups: estate-wide backup with a hardened or immutable repository; an offsite object-lock copy; a timed common-point-in-time DR test on the calendar.

Plan the SIEM destination at ML1 even though central logging is an ML2 clause. Confirm export paths for application control, vulnerability scanning, endpoint and gateway telemetry now, so the log path is not the largest work item in the next uplift.

The hard parts, control by control

Application control. The hard part is not the product. It is learning mode that never ends, and exceptions that become a second allowlist. Look for a learning or audit-first mode that observes real usage, and an approval workflow so a broken install routes to a decision with an owner.

Patching. Daily scanning of online services and a 48-hour window for exploited or vendor-critical issues is a process, not a dashboard. The pipeline has to admit what it does not cover: third-party applications, macOS, network devices. A named owner for each gap is the control.

Macros and browsers. Centrally locked policy beats a user setting. Attachment inspection at the mail gateway is supporting coverage, not the primary control.

Admin privileges. Dedicated privileged accounts on a separate environment is a current ML1 requirement. Day-to-day accounts stripped of local admin, with an approval-based elevation path, is how the rest of the estate stays usable.

MFA. Enable what the productivity licence already includes. Confirm up front that the same licence can do phishing-resistant methods (FIDO2 security keys, passkeys) later, so ML2 is a configuration change rather than a rip-and-replace. Admin and remote-access paths on your gateway or VPN sit in the intent of this strategy even where the letter of the control names online services.

Backups. The tested-restore clause is the difference between a backup product and a recovery capability. A green dashboard is not a restore. Restoring a single server is a first step, not the test: ML1 asks for data, applications and settings back to a common point in time, in a DR exercise, with the clock running. Put that date in the diary and write down how long it took.

A 90-day path from standing start to ML1

This is the sequence we run. It is deliberately not the order of the strategies in the framework. It puts the controls that stop the most likely intrusion paths in first, and it ends with evidence, because an ML1 posture you cannot demonstrate is an ML1 posture a customer, insurer or auditor will discount.

Weeks 1 to 5: quick wins and separation. Automated asset inventory stood up, with fortnightly discovery as the cadence of record. MFA enabled for the organisation’s online services and the third-party services that hold sensitive data, starting with admins and finance. Dedicated privileged accounts created; day-to-day accounts stripped of local admin, with an approval-based elevation path. Application control deployed in learning or audit-only mode across workstations. Macro settings locked by policy, and browser hardening pushed to all workstations. Backup scope agreed against business criticality, and a restore test of one server run for real, with the time noted. Privileged environment separation designed and procured.

Weeks 4 to 9: patching discipline and control. Vulnerability management operating to the ML1 rhythm: daily online-service scanning, weekly for the office suite categories, 48 hours for exploited or vendor-critical online-service vulnerabilities, two weeks for the rest. Application control moved from learning to enforced mode for user profiles and temporary folders, with exceptions handled through the approval workflow rather than ad-hoc allowances.

Weeks 8 to 13: evidence and the DR test. The full common-point-in-time disaster recovery exercise lands here. Configuration exports, coverage reports and the restore timings become the evidence pack. Partial states stay in the register as partials. Nothing is recorded as a pass that cannot be produced on demand.

The argument in one sentence

ML1 is won by treating eight strategies as a program with owners, a named bar, and evidence that repeats. Choose capabilities once, with the end of the model in mind, rather than buying in panic after a questionnaire deadline.

This is the second in a series adapted from S5’s Essential Eight papers. The first covered the five-phase journey. Later articles cover Maturity Levels 2 and 3, control by control, and how to select an implementor.

The full whitepaper is available on request. If you are standing up an ML1 program, or working out why the one you have is not moving, start with scope, ownership, the target level, and what a first assessment should cover.

In this series

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.