The Essential Eight is the ACSC's prioritised set of mitigation strategies, drawn from its broader Strategies to Mitigate Cyber Security Incidents. It is not a certification standard – it is a maturity model (Levels 0 to 3) that measures how well an organisation resists the cyber attacks it is most likely to face. Maturity Level 0 means the strategy is not implemented; Levels 1, 2 and 3 represent progressively stronger, more resilient implementations aligned to increasingly capable adversaries.
Why maturity levels matterLink to this section
Government buyers, insurers, and prime contractors increasingly ask for Essential Eight alignment, and it is mandatory for non-corporate Commonwealth entities. Maturity Level 1 is a sensible baseline for most organisations; Levels 2 and 3 add rigour around scanning frequency, phishing-resistant MFA, privileged access, hardening, and backup protection. The model expects you to reach a consistent level across all eight strategies before claiming it – a single weak strategy caps your overall maturity. Attempting Level 3 everywhere on day one usually fails, so we sequence uplift by risk and operational capacity.
Microsoft-centric, but broadly usefulLink to this section
The strategies were written with a Microsoft Windows environment in mind, but the underlying principles – patch fast, restrict admin, enforce strong MFA, control what executes, and keep tested backups – apply to any stack. We map each strategy to your actual tooling (Intune, SCCM, Jamf, third-party patchers, your identity provider) and produce evidence packs suitable for an ACSC-style or IRAP assessment.
How the Essential Eight relates to IRAP and the ISMLink to this section
The Essential Eight is a focused baseline that also sits inside the ACSC Information Security Manual (ISM) – the comprehensive control catalogue that an IRAP-endorsed assessor evaluates a system against (for example, to handle government data up to PROTECTED). Put simply: meeting the Essential Eight is necessary groundwork for, but not the whole of, an IRAP assessment. If your goal is to host or process government workloads, the Essential Eight is the right first step and the ISM is the destination – we support both.
Our approach to upliftLink to this section
We benchmark your current maturity against all eight strategies, identify the two that reduce the most real-world risk for you, and run focused 30-day sprints until each reaches the target level before moving on. Throughout, we build the logging, reporting, and evidence habits that let you demonstrate maturity – not just claim it. The table below sets out what each strategy requires at Maturity Levels 1, 2 and 3, and how we help you get there.
The Essential Eight by maturity level
Patch applications
| Maturity | What the level requires | How we help |
|---|---|---|
| ML1 | Patch or mitigate internet-facing services within two weeks (within 48 hours where an exploit exists), and other applications within one month; use a vulnerability scanner and remove unsupported applications. | We stand up a vulnerability-scanning and patch programme with clear SLAs, an exception register for legacy apps, and a remediation dashboard, so you hit the timeframes and can prove it. |
| ML2 | Scan more frequently (at least fortnightly for general applications), keep internet-facing patch windows tight, and patch office productivity, browsers, email and PDF software within two weeks. | We tune scan cadence and automate patch deployment through your existing tooling (Intune, SCCM, or third-party patchers), reducing manual effort while shrinking exposure windows. |
| ML3 | Scan internet-facing services daily, patch within 48 hours when an exploit exists, and remove unsupported applications promptly. | We help you reach near-continuous patch assurance with automated detection-to-remediation workflows and evidence suitable for an ACSC-style assessment. |
Patch operating systems
| Maturity | What the level requires | How we help |
|---|---|---|
| ML1 | Patch internet-facing operating systems within two weeks (48 hours where an exploit exists) and other operating systems within one month; use a vulnerability scanner and run only supported versions. | We build an OS patch baseline across workstations, servers and network devices, with a lifecycle plan to retire end-of-support systems before they become findings. |
| ML2 | Scan operating systems more frequently and patch within two weeks; replace operating systems no longer supported by the vendor. | We automate OS patching and reporting, and produce a tracked roadmap to migrate or replace unsupported platforms with minimal disruption. |
| ML3 | Patch internet-facing operating systems within 48 hours when an exploit exists, run the latest or preceding release, and remove unsupported operating systems including on network devices. | We extend patch rigour to firmware and network devices and implement the monitoring needed to sustain Level 3 over time. |
Multi-factor authentication
| Maturity | What the level requires | How we help |
|---|---|---|
| ML1 | Enforce MFA for users authenticating to the organisation's internet-facing services and to third-party internet-facing services that handle the organisation's sensitive data. | We roll out MFA across your internet-facing and SaaS logins, prioritising the systems that hold sensitive data, with a smooth enrolment experience for staff. |
| ML2 | Extend MFA to privileged users and important data repositories, use phishing-resistant methods, and log MFA events. | We deploy phishing-resistant MFA (passkeys, FIDO2, or certificate-based) for admins and key systems, and wire authentication logging into your monitoring. |
| ML3 | Use phishing-resistant MFA for all users of internet-facing and important services, make it verifier impersonation resistant, and protect privileged access. | We standardise phishing-resistant MFA everywhere it counts and validate coverage so no privileged or internet-facing path is left on weaker factors. |
Restrict administrative privileges
| Maturity | What the level requires | How we help |
|---|---|---|
| ML1 | Validate requests for privileged access; prevent privileged accounts from accessing the internet, email and web services; separate privileged and unprivileged operating environments. | We rationalise who holds admin rights, split admin and day-to-day accounts, and document an approval process for granting privileged access. |
| ML2 | Revalidate privileged access regularly, disable it after 12 months or 45 days of inactivity, restrict admin accounts from the internet, and perform admin tasks from secured environments. | We implement just-in-time and time-bound admin access with automated review and revocation, plus jump hosts or Privileged Access Workstations for sensitive tasks. |
| ML3 | Use just-in-time administration, hardened Privileged Access Workstations, and credential-protection technologies; log and monitor all privileged activity. | We design a full privileged-access architecture – PAWs, credential guard, session logging – and feed it into your SIEM for continuous oversight. |
Application control
| Maturity | What the level requires | How we help |
|---|---|---|
| ML1 | Apply application control on workstations to restrict execution of executables, libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an approved set in user profile and temporary folders. | We begin allow-listing in the highest-risk paths, profile your real software estate to avoid breaking workflows, and move you from audit to enforcement safely. |
| ML2 | Extend application control to internet-facing servers, cover additional execution types, and log allowed and blocked execution events. | We broaden the policy to servers and drivers, and connect allow/block telemetry to your monitoring so attempts are visible. |
| ML3 | Apply application control across all workstations and servers, implement Microsoft's recommended application and driver block rules, validate rulesets annually, and centrally store and monitor logs. | We deploy the ACSC and Microsoft recommended block rules, set up annual ruleset validation, and centralise protected logging for assessment evidence. |
Restrict Microsoft Office macros
| Maturity | What the level requires | How we help |
|---|---|---|
| ML1 | Disable macros for users without a business need, block macros in files from the internet, scan macros with antivirus, and prevent users from changing macro settings. | We identify legitimate macro use, block internet-sourced macros via policy, and lock the settings so users can't weaken them. |
| ML2 | Enforce the macro controls so settings cannot be bypassed, and log macro execution events. | We harden macro configuration across Intune/GPO, document approved exceptions, and add macro execution logging. |
| ML3 | Allow only macros from Trusted Locations with limited write access or those digitally signed by a trusted publisher, run macros in a sandboxed or scanned context, and centrally monitor logs. | We implement signed-macro and Trusted Location models with code-signing governance, and feed macro telemetry into central monitoring. |
User application hardening
| Maturity | What the level requires | How we help |
|---|---|---|
| ML1 | Configure web browsers so they do not process Java or web advertisements from the internet, disable or remove Internet Explorer 11, and prevent users from changing browser security settings. | We push hardened browser baselines via policy, remove legacy components, and lock settings so the hardening sticks. |
| ML2 | Harden Microsoft Office and PDF software against exploitation, restrict PowerShell, and enable PowerShell and command-line process-creation logging. | We apply ACSC and vendor hardening guides to Office and PDF readers, constrain PowerShell, and turn on the logging assessors expect. |
| ML3 | Disable or remove legacy .NET and Windows PowerShell 2.0, enforce PowerShell Constrained Language Mode, and centrally store and monitor the resulting logs. | We remove legacy runtimes, enforce Constrained Language Mode, and centralise protected logging to complete the hardening picture. |
Regular backups
| Maturity | What the level requires | How we help |
|---|---|---|
| ML1 | Back up important data, software and configuration in line with business continuity requirements, keep backups resilient, and prevent unprivileged accounts from modifying or deleting backups. | We design a backup strategy aligned to your recovery objectives, with immutable or access-controlled storage so backups survive an incident. |
| ML2 | Synchronise backups to enable restoration to a common point, and prevent unprivileged accounts from accessing or altering backups, with privileged access restricted to backup administrators. | We tighten backup access controls and retention, and verify restoration to a consistent recovery point. |
| ML3 | Test restoration as part of disaster-recovery exercises, and prevent all unprivileged accounts and most privileged accounts from accessing, modifying or deleting backups. | We run documented restoration tests within your DR programme and enforce strict, audited backup access so recovery is proven, not assumed. |