The ASD published ASD Essentials on 15 October 2026, and its enterprise IT chapter replaces the Essential Eight. Every business that has spent money climbing the maturity ladder is asking the same question: does that work still count? It does, as evidence. It does not count as a rating, and that difference is where most of the transition effort will go.
Below is each Essential Eight strategy mapped to the ASD Essentials principles and actions it feeds, what carries forward and what needs new work. It is built from the ASD’s own transition guide and the Essentials for enterprise IT chapter. For the timeline and background, see our Essential Eight to ASD Essentials tracker.
Every ASD Essentials chapter has three layers. Principles state the security outcome and carry an ISM identifier, such as PRO-13 for identity, credential and access management. Actions say what has to be done, in technology-agnostic terms. Domains say where it applies. The enterprise IT chapter has 28 principles and 58 actions spread across eight domains.
Six of those domains are technical: Boundary services, Identity services, Critical processes and services, Privileged environments, Business systems and User devices. Two are capability domains that run across everything: Governance and culture, and Visibility and response. The ASD groups the technical domains into three priority phases, starting with Boundary services and Identity services, because those are the most common routes in for attackers.
Assessment changes completely. Each action is rated not assessed, not effective, partially effective or fully effective in each domain where it applies. A principle takes the rating of its weakest action, and results are reported domain by domain. There is no single score to put on a tender response any more.
| Essential Eight strategy | ASD Essentials principles | What carries forward | What needs new work |
|---|---|---|---|
| Application control | Trustworthy software (PRO-07); Secure configuration management (PRO-04) | Application control rulesets, approved software lists, blocklists, documented exceptions and application control logs | Software must be supported and verified as well as approved. Admin and management tools need their own approved set and known locations. Exceptions must be risk accepted, time-bound and reviewed. Configuration drift needs detecting. |
| Patch applications and patch operating systems | Vulnerability management (PRO-06); Asset identification (IDE-01); Legacy system management (GOV-14) | Vulnerability scanning, patch deployment, compliance reporting, automated asset discovery and processes for unsupported systems | Treatment timeframes based on exploitation, exposure, criticality and impact, with treatment verified. Asset inventories that cover identities, credentials and data, not just devices and software. A managed risk process for legacy systems you cannot retire yet. ISM and regulatory timeframes still apply. |
| Multi-factor authentication | Identity, credential and access management (PRO-13) | Phishing-resistant MFA configurations, authentication policies, coverage reporting and authentication logs | Phishing-resistant MFA is expected in all six technical domains, not only remote access. Plus five related actions: removing default and unused accounts, storing secrets in approved vaults, scanning for exposed credentials, retiring legacy authentication protocols and unique credentials per account. |
| Restrict administrative privileges | Identity, credential and access management (PRO-13); Least privilege access (PRO-12); Secure administration (PRO-05); Network segmentation and segregation (PRO-18) | Separate admin accounts, privileged access workstations and jump hosts, approval and revalidation processes, privileged credential management and privileged access logs | Time-bound privilege grants, so standing admin access becomes a gap. Every admin action recorded with user, timestamp and target. Least privilege for service and non-person accounts. Limits on lateral movement between and within network segments. |
| Restrict Microsoft Office macros | Trustworthy software (PRO-07); Secure configuration management (PRO-04) | Macro blocking, internet-macro restrictions, macro scanning, locked settings, trusted locations and trusted publishers | Macros become one execution path among many, so equivalent controls are needed for other script and execution mechanisms. Macro settings belong in approved configuration baselines with drift detection. |
| User application hardening | Secure configuration management (PRO-04); Content filtering (PRO-09) | Browser, Office and PDF hardening, PowerShell and command-line logging, and application security settings | Approved, maintained baselines that extend beyond endpoints to every technical domain. Drift detection. Blocking outbound connections to malicious destinations across applications, not just blocking web ads. |
| Regular backups | Regular and proven backups (PRO-10); Least privilege access (PRO-12) | Backup schedules, retention, restrictions on who can modify or delete backups, restore testing and DR exercises | Encrypted storage protected by immutable, offline, logically isolated or equivalent controls. Backup repositories separated from production and user environments. Restore tests that prove recovery time and recovery point objectives. |
| Logging, detection and response (spread across the Essential Eight) | Centralised event logging (DET-01); Cyber security event detection (DET-02); Incident identification (DET-03); Baselined high-risk access activities (DET-04); Detection capability efficacy (DET-05); Incident response, insights and coordination (RES-03 to RES-05) | Central logging of MFA, privileged access, application control and PowerShell events, protected logs, event analysis, escalation processes and incident response plans | A dedicated Visibility and response domain that runs across all phases. Logs normalised and time-synchronised for correlation. Detection of unauthorised change, anomalous sign-ins and suspicious execution. Periodic reviews of detection coverage. Tested response procedures and post-incident reviews. |
One thing the table cannot show: the same action is rated separately in each domain. A patching process that is fully effective for user devices can be partially effective in Identity services if domain controllers and certificate authorities lag behind. The ASD’s own assessment guide uses exactly that example. Enterprise-wide controls need checking domain by domain.
It is gone. The transition guide is blunt that Essential Eight maturity ratings do not translate into ASD Essentials effectiveness ratings, because the two models assess different things. Maturity levels are replaced by priority phases, which set the order of work, and by four-tier action ratings, which measure whether an outcome is being achieved.
Maturity Level Two organisations should find many existing controls feed the early phases: phishing-resistant MFA, patching of internet-facing services, privileged access controls, application control and central logging. The ASD expects common gaps in extending controls to domains that were never covered, in the Governance and culture and Visibility and response domains, and in evidence of sustained effectiveness. If you are a DISP member or government supplier, your ML2 obligation still stands until Defence or the PSPF changes it. Our Maturity Level 2 guide and DISP cyber security page cover the current requirement.
Maturity Level Three organisations can reuse a wider range of controls and evidence, but still will not get automatic fully effective ratings. Credential exposure, supply chain security and the capability domains have no Essential Eight equivalent. Maturity Level One organisations follow the same transition path with more actions needing work.
The change that matters most for budgets is in the transition guide’s recommended pathway: do not start work solely to reach a superseded Essential Eight target, unless a regulator or other obligation still requires it or it still addresses material risk. Map planned work to the new actions first. We had been telling clients to finish their ML2 uplift. For anyone with a DISP, PSPF or contractual ML2 requirement, that still holds. For everyone else, run the plan through a gap analysis before committing more money.
Several principles have no Essential Eight equivalent at all. In the Governance and culture domain: executive and board accountability for cyber security, cyber security resourcing, a risk management methodology, supplier cyber security assurance, executive accountability for artificial intelligence, and legacy system management. Boards that have treated cyber as an IT line item now have assessable responsibilities.
In the technical domains, content filtering (inspecting inbound and outbound content), cyber security awareness training tailored to each role before access is granted, cyber supply chain security (checking the integrity of software and updates before use) and secure system lifecycle (designing systems securely and building them through controlled pipelines) are all new. So is security risk identification: risk assessments that take real attacker techniques into account.
Here is the part we think most businesses will underestimate. The ASD says outsourcing a service does not transfer accountability for its security outcomes, and a domain is not effective just because a provider is responsible for it. If your IT provider runs your environment, you need current evidence from them, not a line in the contract. As an MSP, we think that is the right call: evidence should come out of the service as it runs, not be pieced together at assessment time. Ask your provider how they will evidence the actions they run for you, and if we look after your managed security, ask us too.
The enterprise IT chapter is written for organisations whose scale and complexity need a structured approach. The ASD says smaller businesses can use it where relevant, but the way they achieve the outcomes differs and more of the responsibility sits with service providers and vendors. For a 30-person Perth firm, that means the gap analysis is largely a conversation with whoever manages your IT. SMB1001 is run by CyberCert, not the ASD, and is unaffected by any of this.
Record your transition baseline. Gather your latest Essential Eight assessment, current controls, exception and risk registers, and any planned uplift work. Check that exceptions have not expired and that evidence still reflects how your environment runs today.
Scope priority phase 1 and run the gap analysis. Identify the assets in Boundary services and Identity services, start Governance and culture and Visibility and response alongside them, and classify each applicable action as addressed, partially addressed or not addressed. The ASD’s implementation planning guide sets out the method, and the transition guide lists the actions each strategy feeds.
Talk to us about your transition. We can help you work out where your Essential Eight controls and evidence land in ASD Essentials and plan the remaining work in priority phase order, while keeping your existing obligations covered. Call 1300 EPIC IT or start with our Essential Eight service.
Yes, as evidence. Every Essential Eight strategy maps to at least one ASD Essentials principle, and existing controls, tooling and evidence can be reused where they are current. What does not carry across is the rating: each action has to be assessed in each applicable domain.
It is still valid for any obligation that asks for it, such as DISP, the PSPF or a contract. It does not convert into an ASD Essentials rating, because the new model rates each action by domain instead of giving one maturity level. Treat your current rating as the baseline for your gap analysis.
Application control and macro restrictions map to trustworthy software and secure configuration management. Patching maps to vulnerability management, asset identification and legacy system management. MFA maps to identity, credential and access management. Restricting admin privileges maps to four principles, including secure administration. Backups map to regular and proven backups. The table above gives the detail.
Keep meeting any obligation that requires the Essential Eight. For other planned work, the ASD advises mapping it to the ASD Essentials actions first and only continuing if an obligation requires it or it still addresses material risk. Most in-flight work, such as phishing-resistant MFA and privileged access controls, passes that test easily.
Keep meeting the Essential Eight Maturity Level 2 requirement until Defence changes it, and start mapping your evidence to the ASD Essentials actions now. Our guide to the Essential Eight retirement and DISP covers the obligation in detail.
Principle names and action summaries are drawn from ASD publications. © Commonwealth of Australia 2026, used under CC BY 4.0. The ASD Essentials for enterprise IT chapter remains the authoritative source for action wording.
