Essential Eight · Complete Guide · Updated June 2026
The Essential Eight is Australia's most widely applied cyber security framework, developed by the ASD (Australian Signals Directorate) and maintained by the ACSC. It is designed to protect organisations against the most common and damaging attack techniques observed in real Australian incidents. This guide covers what it is, who needs it, how the maturity model works, each of the eight controls in detail, and exactly how to achieve ML2 — the ASD-recommended baseline.
ASD has announced it will retire the Essential Eight within two years and replace it with the new Essentials series. A consultation on Essentials for enterprise IT closes 12 July 2026. Existing E8 work maps across — don't stop your programme. Read our transition guide →
Table of Contents
Section 1
The Essential Eight is a prioritised set of eight cyber security mitigation strategies developed by the Australian Signals Directorate (ASD) and maintained by the Australian Cyber Security Centre (ACSC). It is not a broad management standard — it is a focused, high-impact baseline designed to protect Australian organisations against the attack techniques that cause the most harm in practice.
The framework originated as the "Top 4" mitigation strategies — application control, patching applications, configuring Microsoft Office macros, and user application hardening. These four controls, when implemented correctly, were found to mitigate the majority of targeted cyber intrusions observed by the ACSC. Over time, as threat actors broadened their techniques, the ASD expanded the set to eight controls by adding: restricting administrative privileges, patching operating systems, multi-factor authentication, and regular backups.
What makes the Essential Eight powerful is that it is grounded in real incident data. The ACSC responds to hundreds of cyber incidents in Australia each year, and the eight controls are a direct product of analysing which defensive measures, had they been in place, would have prevented or contained those incidents. This is not a theoretical framework built from first principles — it reflects what actually works against the techniques that adversaries actually use against Australian targets.
It is important to understand what the Essential Eight is not. It is not a comprehensive information security management framework — that role belongs to ISO 27001 or the ISM (Information Security Manual). The Essential Eight addresses cyber attack prevention and recovery. It does not cover physical security, personnel security, governance structures, risk management processes, or the full scope of a security programme. Organisations that require a complete security management system will typically use the Essential Eight as the technical control baseline within a broader ISO 27001 or PSPF-aligned programme.
The ASD's own analysis estimates that organisations implementing all eight strategies to Maturity Level 2 would mitigate approximately 85% of the most common attack vectors observed in Australian incident response. That 85% figure is the reason the framework attracts so much attention — no other single framework delivers that level of risk reduction for the effort required.
Section 2
The Essential Eight was developed by ASD (Australian Signals Directorate), Australia's signals intelligence and cyber security agency, through its operational arm the ACSC (Australian Cyber Security Centre). The ACSC is responsible for Australia's national cyber incident coordination, threat intelligence, and cyber security guidance. It publishes the annual Australian Cyber Security Centre Annual Cyber Threat Report, which documents the attack techniques, threat actors, and sectors targeted in Australian incidents each year.
The Essential Eight is derived directly from the ACSC's broader publication, Strategies to Mitigate Cyber Security Incidents, which lists 37 prioritised mitigation strategies ranked by their assessed effectiveness. The Essential Eight represents the top eight strategies from this list — the controls that offer the highest risk reduction relative to implementation effort for the widest range of Australian organisations.
In 2018, the Australian Government's Protective Security Policy Framework (PSPF) was updated to mandate Essential Eight compliance for non-corporate Commonwealth entities — effectively all federal government departments and most Commonwealth agencies. This mandate gave the framework significant momentum and established it as the de facto baseline for Australian public sector cyber security. Since then, adoption has spread rapidly into the private sector, driven by cyber insurance requirements, government procurement conditions, and enterprise supply chain due diligence programmes.
The framework is not static. The ASD updates the Essential Eight and its accompanying assessment guidance regularly as threat actors evolve their techniques. Significant updates were made in 2021 (refining the maturity model), 2022 (strengthening MFA requirements in response to credential-based attacks), and 2023-2024 (phishing-resistant MFA becoming the ML3 standard for privileged accounts). Organisations should always reference the current ASD guidance rather than relying on older versions of the framework, which may no longer reflect current ACSC recommendations.
Section 3
The Essential Eight applies more broadly than most organisations realise. While legislative mandates cover a specific subset of entities, commercial and procurement pressures have extended effective requirements across much of the Australian economy.
Non-corporate Commonwealth entities (PSPF)
All federal government departments and most Commonwealth agencies are mandated to achieve Essential Eight ML2 as a baseline under the PSPF. High-risk entities are directed toward ML3. Annual self-assessment reporting to the Australian Government Security Construction and Equipment Committee (ASCSEC) is required.
SOCI Act critical infrastructure operators
Operators of critical infrastructure assets regulated under the Security of Critical Infrastructure Act 2018 — covering electricity, gas, water, communications, banking, superannuation, higher education, health, food, transport, and defence industry — are subject to risk management programme requirements that reference the Essential Eight as a baseline technical control set. Sector-specific rules vary, but the Essential Eight is the most commonly cited starting point for SOCI compliance.
Defence Industry Security Programme (DISP)
Organisations seeking DISP membership to supply the Australian Department of Defence are effectively required to demonstrate Essential Eight ML2. The DISP assessment criteria align closely with the Essential Eight maturity model, and ML2 is the practical standard for DISP entry at most membership levels. Defence prime contractors increasingly cascade this requirement to subcontractors through their own supply chain programmes.
Cyber insurance
Australian cyber insurers have significantly tightened underwriting requirements since 2020. ML2 evidence is increasingly required as a condition of coverage — not just for premium reduction. Self-attestation is no longer sufficient for most insurers above a threshold premium; assessor-produced or tool-generated evidence packs are now the standard. Organisations that cannot demonstrate ML2 implementation face policy exclusions, sub-limits, or coverage refusal for ransomware and business email compromise claims.
Government procurement panels
Federal, state, and territory government procurement frameworks increasingly require supplier security baselines. The NSW Government, WA Government, Queensland Government, and Victorian Government all include cyber security baseline requirements in their whole-of-government panel arrangements. The Essential Eight ML2 is the most commonly specified baseline for technology and professional services suppliers.
Enterprise supply chain due diligence (TPRM)
Large Australian enterprises — banks, utilities, telecommunications operators, and insurers — run third-party risk management (TPRM) programmes that assess the cyber security maturity of their suppliers and service providers. The Essential Eight has become the most commonly referenced baseline in Australian TPRM questionnaires. Suppliers that cannot demonstrate Essential Eight compliance face increased scrutiny, onboarding delays, or disqualification from preferred supplier arrangements.
ASX-listed company supplier panels
Many ASX 200 companies screen suppliers on Essential Eight compliance as part of vendor onboarding and annual recertification. Board-level reporting on cyber supply chain risk has increased following ASIC guidance on directors' duties and cyber risk disclosure obligations, making supplier cyber security a governance issue rather than purely an IT matter.
Section 4
The Essential Eight uses a four-level maturity model — ML0 through ML3 — to assess how consistently and robustly each control is implemented. Understanding what each level actually means in practice is critical, because many organisations misclassify their maturity by conflating policy existence with control implementation.
ML0 means the organisation has no meaningful alignment with the intent of the mitigation strategy. Controls are ad hoc, informal, or non-existent. There is no documented policy, no consistent enforcement, and no evidence that the control has been considered in a systematic way.
ML0 is more common than organisations admit, particularly for application control, MFA on legacy systems, and privileged access management. The gap between "we intend to implement this" and "this control is implemented to ASD intent" defines the difference between ML0 and ML2.
ML1 means controls exist but are not implemented consistently, have significant gaps, and evidence is weak or anecdotal. ML1 is the minimum for some insurance purposes but is increasingly insufficient for procurement and insurer requirements.
What "partly aligned" looks like in practice for each control:
ML2 means controls are implemented to ASD intent, tested against ASD-specific criteria, and evidenced. This is the ASD-recommended baseline for most Australian organisations, and the level required by insurers, procurement panels, and enterprise due diligence programmes.
What ML2 evidence looks like for each control:
ML3 represents the most stringent implementation of each control, with stricter requirements designed for high-risk environments. ML3 is appropriate for Commonwealth entities, defence industry organisations, critical infrastructure operators, and organisations facing persistent nation-state threat actors.
Key ML3 requirements that go beyond ML2:
| Control | ML1 | ML2 | ML3 |
|---|---|---|---|
| MFA | MFA on some services, not enforced for all users | MFA for all users on all internet-facing services; no legacy auth | Phishing-resistant MFA (FIDO2/WHfB) for all privileged accounts |
| Application Control | Applied to some endpoints; significant gaps in coverage | Enforced fleet-wide; documented exception register; quarterly review | Covers all user-mode code including scripts; no exceptions without formal approval |
| Patch Applications | Patching occurs but outside ASD timeframes; no tracking | Critical patches applied within 14 days; evidenced via DVM report | Internet-facing services patched within 48 hours of critical patch release |
| Admin Privileges | Standard users lack admin rights on most machines; shared accounts present | All privileged role assignments time-limited via PIM; no permanent GA accounts | No persistent privileges; PAWs required; full audit trail for all privileged actions |
Section 5
Each control addresses a distinct attack vector and has specific implementation requirements at each maturity level. Here is what each control actually prevents, what ML2 requires, how it is delivered in a Microsoft 365 environment, and where organisations most commonly fall short.
Control 1
What it prevents: Malicious executables, ransomware installers, and unapproved software from running on endpoints and servers. Application control is the primary defence against malware that relies on running arbitrary code — including the majority of ransomware attack chains.
ML2 requirement: Application control enforced on all workstations and servers using an allowlist approach — only approved executables, libraries, and scripts are permitted to run. A documented exception register must exist, with formal approval for all exceptions and evidence of quarterly review.
M365 / Intune delivery: Windows Defender Application Control (WDAC) is the preferred implementation for modern Windows environments — it is kernel-enforced and cannot be bypassed by local administrators. AppLocker is an acceptable alternative for older environments. Both are deployed and managed via Intune policy. WDAC policies should be built in audit mode first to identify exceptions before enforcement.
Common gap: Application control deployed to workstations but not servers. Many organisations also leave significant gaps by allowlisting entire directory paths (e.g., C:\Users) rather than specific publisher certificates or file hashes, which defeats the purpose of the control.
Control 2
What it prevents: Exploitation of known vulnerabilities in third-party applications — browsers, PDF readers, productivity tools, Java runtimes, and any other user-installed or vendor-managed software. Unpatched applications are among the most frequently exploited entry points in Australian incidents, particularly for initial access.
ML2 requirement: Applications with a CVSS score of 9.0 or higher must be patched or mitigated within 48 hours. Other critical patches must be applied within 14 days. Applications that are unsupported (no longer receiving security updates) must be removed or isolated. Evidence requires a vulnerability scan report showing patch compliance rates, not just an assertion that patching is occurring.
M365 / Intune delivery: Microsoft Defender Vulnerability Management (DVM) provides asset discovery, vulnerability identification, and patch compliance reporting. Intune enforces patch deployment for applications in MDM scope. Third-party software managed outside Intune — legacy on-premises applications, non-MDM devices — requires separate tooling such as Qualys, Rapid7, or similar.
Common gap: Applications outside MDM scope. Many organisations patch the managed fleet effectively but have legacy servers, OT systems, or contractor-owned devices that are not enrolled in Intune and therefore not visible to DVM. The vulnerability management programme must cover the full asset inventory, not just MDM-enrolled devices.
Control 3
What it prevents: Macro-based malware delivered via email attachments. Despite being a decades-old attack vector, malicious Office macros remain one of the most common initial access techniques in Australian phishing campaigns. A single user opening a macro-enabled document from a phishing email can initiate a full ransomware deployment chain.
ML2 requirement: Macros downloaded from the internet (identified by the Mark of the Web attribute) must be blocked for all users. Macros from trusted locations (internally sourced, digitally signed documents) may be permitted. No individual user should be able to override the macro policy. ML2 also requires that the policy covers all Office applications — Word, Excel, PowerPoint, Outlook, and Access.
M365 / Intune delivery: Macro settings are configured via Intune ADMX administrative templates for Office 365 Apps. Defender Attack Surface Reduction (ASR) rules provide an additional layer — specifically the "Block Office applications from creating executable content" and "Block Office macros from calling Win32 APIs" rules. Both the Intune policy and ASR rules should be deployed together for defence-in-depth.
Common gap: Policy exists in configuration but is not enforced because the ADMX template was not deployed correctly via Intune, or because legacy GPO settings conflict with Intune policy. Evidence at ML2 must show that the policy is actually applied on endpoints — not just configured in the Intune admin centre.
Control 4
What it prevents: Exploitation through the attack surface exposed by browsers, PDF readers, Microsoft Office, and other user-facing applications. Web browsers in particular offer enormous attack surface — browser extensions can exfiltrate credentials and data, while unblocked content (Flash, Java browser plugins, web advertisements) have historically been major malware delivery vectors.
ML2 requirement: Web browsers must be configured to block Flash (now universally deprecated), Java web plugins, web advertisements from untrusted sources, and unapproved browser extensions. Microsoft Office must be hardened to disable ActiveX and OLE package activation from the internet. PDF reader settings must be hardened to disable JavaScript execution and external content loading. All settings must be applied consistently across the fleet.
M365 / Intune delivery: Edge browser settings are managed via Intune administrative templates and the Edge security baseline. Microsoft 365 Apps hardening settings are deployed via Intune ADMX policies and the Office security baseline. The ASD publishes specific hardening guides for Edge, Office, and Adobe Acrobat which document the exact policy settings required at each maturity level.
Common gap: Hardening settings deployed to a pilot ring during initial implementation but never rolled out to the full production fleet. Many organisations also fail to block browser extensions effectively, either because the extension policy is set to "warn" rather than "block", or because users have a secondary browser (Chrome, Firefox) that is not under Intune policy.
Control 5
What it prevents: Privilege escalation — the technique by which an attacker who has gained initial access to a low-privilege account elevates to administrator or domain administrator, enabling them to move laterally across the network, access all data, and deploy ransomware or other destructive tools. The majority of large-scale Australian data breaches involved privilege escalation as a key step in the attack chain.
ML2 requirement: Privileged accounts must be used only for privileged tasks — no web browsing, email, or general productivity from privileged accounts. Privileged role assignments must be time-limited, not permanent. All privileged role requests, approvals, and activations must be logged. The number of global administrators must be minimised (ASD guidance suggests no more than five for most organisations). Regular review of privileged access assignments is required.
M365 / Intune delivery: Microsoft Entra Privileged Identity Management (PIM) provides just-in-time privileged access for Entra ID and Microsoft 365 roles. PIM activation requests require business justification and optional approval workflow. All activations are logged in the Entra audit log. For on-premises Active Directory, Microsoft Identity Manager (MIM) PAM or a third-party PAM solution is required to achieve equivalent controls.
Common gap: PIM deployed for Entra roles but not for on-premises Active Directory privileged groups (Domain Admins, Schema Admins). Many organisations also leave service accounts with excessive privileges — service accounts used for automation or integrations often accumulate unnecessary permissions over time and are rarely reviewed.
Control 6
What it prevents: Exploitation of known OS vulnerabilities used for privilege escalation, lateral movement, and initial access. OS-level vulnerabilities — particularly in the Windows kernel, Remote Desktop Protocol, SMB, and print spooler — have been exploited in some of the most significant Australian incidents of recent years. The EternalBlue exploit (underlying WannaCry and NotPetya) remains a live risk in organisations with unpatched legacy Windows systems.
ML2 requirement: Operating systems with a CVSS score of 9.0 or higher must be patched or mitigated within 48 hours. Other critical OS patches must be applied within 14 days. Unsupported operating systems (Windows 7, Windows Server 2008, end-of-life Linux distributions) must not be in use, or must be isolated behind compensating controls with a documented risk acceptance and remediation plan. Evidence requires patch compliance reporting — not just confirmation that patching is configured.
M365 / Intune delivery: Windows Update for Business (WUfB) policies in Intune control OS patch deployment rings and deferral periods. Intune compliance policies report device patch status. Microsoft Defender Vulnerability Management provides OS vulnerability tracking and patch compliance dashboards. Windows Server patching requires WSUS, Azure Update Manager, or direct WUfB configuration for server workloads.
Common gap: Legacy devices not enrolled in Intune — older workstations, servers running end-of-life OS versions, OT/IoT devices, and BYOD endpoints. Many organisations have accurate patch compliance for their managed fleet but have no visibility of unmanaged or semi-managed assets. A complete asset inventory is a prerequisite for demonstrable OS patch compliance.
Control 7
What it prevents: Credential-based attacks — phishing, credential stuffing, password spraying, and adversary-in-the-middle attacks. MFA is the single control with the highest impact across the broadest range of attack scenarios. The ACSC's annual threat report consistently identifies compromised credentials as the most common initial access vector in Australian incidents, and MFA is the most effective preventive control against credential compromise.
ML2 requirement: MFA must be enforced for all users accessing all internet-facing services — not just remote access or VPN. This includes Microsoft 365, business applications, cloud platforms (AWS, Azure, GCP), and any other services accessible from the internet. Legacy authentication protocols that bypass MFA (SMTP AUTH, IMAP, POP3, Basic Auth) must be blocked. Sign-in logs must be retained and reviewed. ML2 accepts any form of MFA — SMS, TOTP authenticator apps, or hardware keys.
M365 / Intune delivery: Microsoft Entra Conditional Access policies enforce MFA for all users on all cloud app sign-ins. Block legacy authentication Conditional Access policies prevent legacy protocol bypass. Microsoft Authenticator app (TOTP or push notification) satisfies ML2 MFA requirements. Sign-in logs are retained in Entra ID and can be forwarded to Microsoft Sentinel for SIEM alerting and reporting.
Common gap: MFA enabled but not enforced — "enabled" means the user can set it up; "enforced" via Conditional Access means they cannot sign in without it. Many organisations also have service accounts and break-glass accounts without MFA, or legacy authentication protocols still permitted for specific integrations that create bypasses. The evidence pack must demonstrate enforcement, not just enablement.
Control 8
What it prevents: Permanent data loss from ransomware encryption, accidental deletion, storage failure, and destructive malware. Backups are the last line of defence — if all other controls fail and an attacker encrypts or destroys data, a clean, tested, isolated backup is what determines whether the organisation recovers in days or never. The ACSC has documented cases where organisations paid significant ransoms because their backup environment was also encrypted.
ML2 requirement: Backups must cover all business-critical data and systems. Backups must be stored in a way that is inaccessible to the primary environment — an attacker who compromises the production environment must not be able to reach and encrypt the backups. Immutable backup copies (cannot be deleted or modified for a defined retention period) are required. Backup restoration must be tested at least quarterly, with documented results. Backups must be encrypted.
M365 / Intune delivery: Microsoft 365 does not include enterprise backup — the native recycle bin and version history are not backup solutions, and Microsoft's terms explicitly state that data protection is the customer's responsibility. Third-party M365 backup tools are required: Veeam Backup for Microsoft 365, AvePoint Cloud Backup, HYCU for Microsoft 365, and Keepit are the most common platforms used in Australian environments. These tools provide immutable, encrypted, off-tenant backup copies of Exchange, SharePoint, OneDrive, and Teams data.
Common gap: This is the one Essential Eight control that always requires third-party tooling and additional licensing cost — many organisations defer it. It is also the control that takes longest to fully implement and evidence (backup coverage assessment, immutability configuration, restoration testing, coverage reporting) — which is why organisations that start with backups late often fail to complete the evidence pack on time.
Section 6
The Essential Eight and ISO 27001 are the two most frequently cited security frameworks in Australian commercial and government contexts. Understanding their differences — and their overlap — is essential for planning an efficient compliance programme.
Approximately 60% of ISO 27001 Annex A controls have direct or partial overlap with the Essential Eight mitigation strategies. The technical controls in ISO 27001 Annex A — particularly those covering access management (A.9), cryptography (A.10), physical and environmental security (A.11), operations security (A.12), and communications security (A.13) — map closely to the Essential Eight's eight controls.
When running Essential Eight and ISO 27001 as a combined engagement — assessing against both frameworks simultaneously, designing controls to satisfy both sets of requirements, and producing a single evidence pack — organisations typically achieve 30-40% cost savings compared to running them as separate sequential engagements. The Essential Eight provides the technical control baseline; ISO 27001 provides the governance framework, risk management process, and formal certification. Together they address the full range of Australian and international compliance requirements.
Decision guide: If your primary goal is Australian government compliance, insurance, or domestic procurement — start with the Essential Eight. If your goal is international enterprise sales or global SaaS customers — prioritise ISO 27001. If you need both, run them as a combined programme from the outset.
Section 7
The pathway from current state to evidenced ML2 follows a consistent four-phase structure. For organisations on Microsoft 365 E5, the 12-16 week timeline below is achievable — 80-85% of ML2 is deliverable through M365 native tooling and requires configuration uplift, not greenfield tooling deployment.
01
Weeks 1–3
Establish current maturity baseline against ASD assessment criteria for all eight controls. This is not a high-level review — each control is assessed against the specific ML2 evidence requirements published by the ASD. Gap analysis produces a prioritised remediation plan, including which controls are close to ML2 (quick wins) and which require significant uplift. The assessment phase also includes asset inventory verification — you cannot evidence patch compliance without knowing what you have.
02
Weeks 4–6
Design each control implementation to meet ASD intent at ML2. This phase covers: Intune policy design (configuration profiles, compliance policies, ADMX templates), Conditional Access policy architecture, PIM configuration, WDAC policy design (publisher-based or hash-based rules), backup platform selection and architecture, and exception management process design. Pilot deployment rings are defined. The exception register template is created. Every configuration decision is documented before implementation begins.
03
Weeks 7–12
Controls are deployed in audit mode first — application control, ASR rules, and macro policies run in report-only mode to identify what would be blocked before enforcement is enabled. After audit mode review (typically 1-2 weeks per control), enforcement is rolled out through deployment rings: pilot group first, then broad production. Conditional Access policies follow a similar pattern — report-only before enforcement. Backup tooling is deployed and initial backup jobs are configured and verified. Evidence is collected at each step — configuration exports, compliance reports, audit logs.
04
Weeks 13–16
The evidence pack is assembled against ASD criteria for each control. Evidence includes: Intune compliance policy exports with device compliance reports, Conditional Access policy configurations with sign-in log samples, PIM activation and approval logs, Defender Vulnerability Management patch compliance reports, backup coverage and restoration test records, WDAC policy exports with event log samples, and the documented exception register. The evidence pack is QA reviewed against current ASD assessment guidance before submission to insurers, procurement panels, or external assessors.
The 12-16 week timeline assumes a Microsoft 365 E5 (or E3 + Security add-on) environment with modern management (Intune MDM enrolled devices). E5 provides Defender for Endpoint, Defender for Office 365, Entra ID P2 (for PIM), and Defender Vulnerability Management — the tooling that delivers 80-85% of ML2 natively.
Organisations on M365 E3 without the Security add-on will require additional licensing (Entra ID P2 is required for PIM; Defender for Endpoint P2 is required for vulnerability management). Legacy on-premises environments, hybrid configurations with significant on-premises Active Directory, and environments with large numbers of unmanaged or non-Windows devices will take longer.
The Regular Backups control (Control 8) always requires third-party tooling — Veeam Backup for Microsoft 365, AvePoint Cloud Backup, HYCU, or Keepit — and procurement, deployment, and initial backup completion add 2-4 weeks that cannot be compressed. Start the backup tooling procurement in Phase 1, not Phase 3.
Section 8
Most Essential Eight implementation failures follow predictable patterns. Avoiding these mistakes is the difference between a defensible ML2 evidence pack and a failed assessment.
The most common and costly mistake. The ASD's assessment criteria are designed to test whether controls are implemented to intent — not whether a policy document exists. Assessors look for enforcement evidence, not policy text. Organisations that configure controls to "pass" a checklist without genuinely implementing them to ASD intent will fail an external assessment and will not have the actual security protection the framework is designed to provide.
Application control, user application hardening settings, and Conditional Access policies are often deployed to a pilot group of 10-20 users, monitored for a few weeks, and then left there. The pilot phase is designed to identify issues before broad deployment — not to substitute for it. ML2 requires fleet-wide enforcement. Evidence must show the policy is applied to all users and devices, not a representative sample.
For cyber insurance purposes and government procurement, self-attestation is no longer sufficient. Insurers now require evidence packs that demonstrate control implementation — configuration exports, compliance reports, audit logs — not just a signed declaration. Organisations that self-attest without assembling a defensible evidence pack face problems when a claim occurs or a procurement panel requests verification.
ML1 is "partly aligned" — controls exist but are not consistently implemented. Many organisations achieve ML1 naturally through basic IT hygiene and then stop, believing they have met the framework requirements. ML1 is insufficient for cyber insurance (most insurers require ML2 evidence), government procurement (ML2 is the standard baseline), and enterprise TPRM programmes. ML1 provides partial protection but not at the level the ASD considers the minimum effective baseline.
The Regular Backups control is consistently left until last — often because it requires third-party tooling procurement and budget approval. This creates a bottleneck: procurement, vendor onboarding, deployment, initial backup completion, and restoration testing cannot be compressed below 4-6 weeks. Organisations that start backup implementation in the final weeks of an ML2 programme cannot complete the evidence pack on time. Backup tooling procurement must begin in Phase 1.
Every Essential Eight control will have legitimate exceptions — an application that cannot run under application control, a legacy device that cannot support MFA, a system that cannot be patched within the ASD timeframe for operational reasons. Exceptions are acceptable at ML2 as long as they are formally documented, risk-accepted, and subject to a remediation plan. Undocumented exceptions are evidence of ML0, not ML2. An exception register is a required component of the evidence pack.
Having a password policy document is not the same as enforcing password requirements via Entra ID configuration. Having a macro policy statement is not the same as deploying the Intune ADMX template that enforces macro restrictions on endpoints. Having a backup policy is not the same as having immutable, tested backups. ML2 is assessed against evidence of implementation — configuration exports, compliance reports, and audit logs — not policy documentation.
Essential Eight maturity degrades over time without active maintenance. New devices are enrolled without all compliance policies applied. Application control exceptions accumulate without review. MFA enforcement is weakened for specific user groups. Patch compliance drifts as device management gaps emerge. Research and operational experience shows approximately 30% of controls regress within 6 months without continuous monitoring. ML2 requires ongoing evidence — continuous monitoring plus quarterly evidence reviews and annual independent reassessment.
Section 9
The fastest way to understand where your organisation actually sits against the Essential Eight is to look at the data. Here are three concrete starting points you can take this week.
01
Our automated posture scan checks your Microsoft 365 environment against the key Essential Eight ML2 criteria — Conditional Access enforcement, MFA coverage, legacy authentication status, Intune compliance policy configuration, privileged role assignments, and audit log retention. It takes 15 minutes to run and produces a prioritised gap report against ML1 and ML2 criteria. No tools to install — it works through a read-only Microsoft Graph API connection.
Run the free posture scan02
Our Essential Eight ML2 checklist maps every ASD assessment criterion to a specific configuration check in Microsoft 365 — including the exact Intune policy setting, Conditional Access configuration, Entra PIM setting, or Defender configuration required. The checklist is organised by control and maturity level, with evidence collection instructions for each check. It is the starting point for both self-assessment and evidence pack assembly.
Download the checklist03
A 30-minute call gives you a realistic current-state maturity estimate and a clear ML2 pathway — including timeline, effort, and any licensing gaps. We run through the posture scan results with you, identify your three highest-priority controls, and outline what a structured ML2 uplift programme would look like for your environment. There is no obligation and no sales pitch — just a practical assessment of where you stand and what it takes to get to ML2.
Book a 30-min scoping callFAQ
The questions we are most commonly asked about the Essential Eight, compliance timelines, costs, and evidence requirements.
Not legislatively mandated for most private sector organisations. However it is effectively required by: cyber insurers (ML2 evidence increasingly required for coverage, not just premium reduction), SOCI Act critical infrastructure operators, federal and state government procurement panels, and enterprise customers running TPRM programmes. The commercial pressure is now significant enough that "voluntary" is a somewhat misleading characterisation for any organisation that sells to government or large enterprise.
12-16 weeks for most Australian mid-market organisations on Microsoft 365 E5. This is significantly shorter than the 6-month timelines many consultancies quote, because 80-85% of ML2 is achievable through M365 native tooling — the work is configuration uplift, not greenfield deployment. E3 environments without the Security add-on, significant on-premises legacy infrastructure, or large numbers of unmanaged devices will take longer. The Regular Backups control (requiring third-party tooling) should begin procurement in week one.
Assessment only (2-3 weeks, producing a gap report and evidence requirements summary): $8,000–$18,000 fixed-price. ML2 uplift programme (full design, implementation, evidence pack assembly): $22,000–$120,000 depending on organisation size, existing maturity, environment complexity, and whether legacy on-premises infrastructure is in scope. Combined Essential Eight ML2 + ISO 27001 engagements typically cost 30-40% less than running them as separate programmes. All Compliance365 engagements are fixed-price — no hourly billing surprises.
For M365 E5 organisations, approximately 80-85% of ML2 is achievable with tools you already have — Intune, Entra ID P2 (PIM), Defender for Endpoint (Vulnerability Management), Defender for Office 365, and Conditional Access. The one control that always requires third-party tooling is Regular Backups — Microsoft 365 does not include enterprise backup functionality, and third-party backup platforms (Veeam, AvePoint, HYCU, Keepit) are required to meet the immutability and restoration testing requirements at ML2. For E3 environments, Entra ID P2 and Defender for Endpoint P2 licensing may be required.
The Essential Eight is an Australian-specific, prescriptive framework targeting the most common attack vectors — it is the baseline for government, insurance, and procurement compliance in Australia. ISO 27001 is an international standard with a broader risk-based scope covering governance, risk management, and all aspects of information security management — it is required for US, UK, and European enterprise procurement and for SaaS companies selling to global enterprise customers. About 60% of the relevant ISO 27001 Annex A controls overlap with the Essential Eight, making combined engagements 30-40% more cost-efficient than running them separately.
ASD publishes specific evidence requirements for each control at each maturity level in its Essential Eight Assessment Process Guide. Evidence must demonstrate implementation, not just policy intent. A typical ML2 evidence pack includes: Intune compliance policy exports with device compliance reports, Conditional Access policy configurations with sign-in log samples showing MFA enforcement, Entra PIM activation and approval logs, Defender Vulnerability Management patch compliance reports (showing 100% of critical patches applied within timeframes), backup coverage reports and restoration test records, WDAC policy exports with event log samples, and a documented exception register. Evidence must be current — not more than 12 months old for most controls.
The PSPF (Protective Security Policy Framework) is the Australian Government's overarching policy framework for protective security in the Commonwealth. Policy 10 of the PSPF mandates that non-corporate Commonwealth entities — federal government departments and most Commonwealth agencies — implement the Essential Eight to ML2 as a baseline, with ML3 directed for entities handling PROTECTED-level information or facing elevated threat. Entities report their Essential Eight maturity annually. State and territory government agencies have their own frameworks (e.g., NSW Cyber Security Policy, Victorian Protective Data Security Framework) but most align to the PSPF and Essential Eight as the reference baseline.
The ACSC (Australian Cyber Security Centre) is the operational cyber security arm of ASD (Australian Signals Directorate). The ACSC develops and maintains the Essential Eight framework, publishes the annual Australian Cyber Threat Report, operates the ACSC Partnership Programme (which provides threat intelligence sharing to registered organisations), and coordinates national cyber incident response. The Essential Eight is based directly on ACSC intelligence about the attack techniques most commonly used against Australian organisations — it is updated when threat actor behaviour changes significantly, which is why organisations should always check they are using the current version of the framework.
Yes, and self-assessment is a legitimate starting point for understanding your current maturity. The ASD publishes a detailed assessment process guide that specifies exactly how to assess each control at each maturity level. However, self-assessment has a well-documented accuracy problem — the most common error is assessing whether a policy or control exists rather than whether it is implemented to ASD intent across the full environment. For cyber insurance purposes, insurer-grade evidence produced by a qualified assessor is increasingly required, not a self-attestation. For government procurement, assessor-verified evidence is standard. Self-assessment is useful for gap identification; external assessment produces defensible evidence.
ASD recommends annual reassessment as a minimum. In practice, control drift occurs continuously — new devices are enrolled, software is updated, staff change, and exceptions accumulate. Approximately 30% of controls regress measurably within 6 months of initial ML2 achievement without continuous monitoring. Organisations at ML2 should operate continuous monitoring (Defender Vulnerability Management dashboards, Intune compliance reporting, Conditional Access sign-in monitoring, Sentinel alerts for MFA bypass attempts) supplemented by quarterly internal evidence reviews and annual independent reassessment. Think of Essential Eight maturity as something you maintain, not something you achieve once.
Run our free automated posture scan to get a data-driven baseline against ML1 and ML2 criteria in 15 minutes — or book a 30-minute call to walk through the results, identify your highest-priority gaps, and get a realistic pathway to ML2 with a fixed-price estimate.
Hi! I’m the Compliance365 AI. I can help you work out which security or privacy framework you need, explain what’s involved, and answer questions about ISO 27001, SOC 2, Essential Eight, and more.
What can I help you with today?
Messages are sent to our AI assistant (Claude, by Anthropic) to generate a reply — not stored as part of your account and not used to train AI models.
