ASD has moved past the Essential Eight. Your controls still count
On 15 October 2026 the Australian Signals Directorate published the ASD Essentials, a framework it describes as an evolution of the Essential Eight and, in its own FAQ, as a replacement for it. The Essentials does not use maturity levels. It assesses governance, which the Essential Eight maturity model did not, and it brings logging, detection and response together in a Visibility and response domain. ASD has set no retirement date, no transition deadline and no mandate. Existing Essential Eight work carries forward, but ASD says it is assessed differently. This brief reads all 18 documents in the release and keeps what ASD said apart from what people will assume it said.
Josh | Published 19 October 2026
Three chapters built on the same three layers
The release has three chapters, for enterprise IT, cloud and operational technology, and ASD says more environment chapters can be added later.
ASD describes the series as "a framework that provides organisations with a consistent approach to cyber security across different technology environments". Every chapter uses the same three layers. Principles describe the outcome to achieve, actions describe what needs to be done to achieve it, and domains describe the business functions and assets the actions apply to. ASD says the principles are drawn from the cyber security principles in its Information Security Manual, and it maps actions to MITRE ATT&CK techniques where appropriate.
The chapters share a structure, not a rule set. All three use the same eight domain names, but each chapter selects its own principles, actions and priority phases. The enterprise IT chapter is the one that maps back to the Essential Eight. It has 28 principles and 58 actions across eight domains. Two are capability domains that run across the whole program, Governance and culture, and Visibility and response. The other six are technical domains, Boundary services, Identity services, Critical processes and services, Privileged environments, Business systems and User devices. The OT chapter describes all eight but maps its actions to only five technical domains, leaving out User devices.
An action is not a control in this framework. ASD says organisations implement actions "through controls that are appropriate to their IT environment, risk profile and regulatory obligations", and that relevant controls can be found in the ISM and other ASD guidance. The Essentials sets the outcome. The ISM and ASD's other guidance still hold the detailed controls.
The framework went through public consultation before release. ASD's FAQ says the consultation paper was open from 15 June to 12 July 2026.
Enterprise IT chapter
ASD 2026What the release contains
ASD documents- The chapters share a structure, not a rule set. ASD's FAQ says the specific principles, actions and priority phases differ between chapters.
- The supplementary guides carry most of the method. Implementation planning, assessment, evidence, asset scoping and transition guides sit beside the chapters, with an assessment workbook for enterprise IT.
- Start with the chapter for your environment. ASD says there is no requirement for every organisation to use every chapter.
Being replaced, with no end date set
ASD's own documents describe the change in at least six different ways, which is where most of the misreporting will start.
The senior executive guide calls the Essentials "an evolution of the Essential Eight". The transition guide says ASD "has evolved the Essential Eight into the ASD Essentials for enterprise IT". The reading guide says ASD "has moved beyond the Essential Eight". The FAQ asks "Why is ASD replacing the Essential Eight?". The transition guide refers to "a superseded Essential Eight target", and its first figure labels the Essential Eight "Previous" and the Essentials "Current". The implementation planning guide adds that maturity levels "are no longer defined as implementation targets".
Read together, the direction is clear. ASD is moving organisations off the Essential Eight. What it has not done is set an end date. None of the 18 documents says the Essential Eight is retired or withdrawn, and the Essential Eight page on cyber.gov.au carried no notice of the change on publication day. ASD says it "has been communicating with regulatory bodies around the impact and expected timeframes of transitioning to the new framework and will advise on expectations for transitioning to the new framework in due course". The implementation planning guide adds that "the framework does not prescribe implementation timeframes", which leaves the pace of implementing the Essentials to each organisation.
Approved work should keep going. ASD "does not recommend slowing or stopping the roll-out of pre-approved cyber security initiatives" and says organisations should continue their current uplift programs "while assessing alignment with the new framework". The transition pathway adds two cautions. Do not "initiate work solely to achieve a superseded Essential Eight target unless it remains required by a regulator or other obligation or continues to address material cyber security risk", and "map existing and planned work to ASD Essentials for enterprise IT before deciding whether it should continue unchanged".
Existing work carries across. ASD says every Essential Eight mitigation strategy maps to at least one principle, and the transition guide maps each strategy by name. Multi factor authentication maps to Identity, credential and access management, and regular backups map to Regular and proven backups and Least privilege access. ASD calls the Essential Eight "an important foundation for many of the controls required by ASD Essentials for enterprise IT".
Mapped does not mean equivalent. "Essential Eight maturity level ratings do not automatically convert into ratings under ASD Essentials for enterprise IT." An organisation at Maturity Level Two should not assume an action will be fully effective in every applicable domain, and even Maturity Level Three "does not automatically produce fully effective ratings".
What ASD said
Transition- ASD calls an Essential Eight target superseded. The transition guide uses that phrase and labels the Essential Eight Previous in its first figure.
- No end date or deadline has been published. ASD says it will advise on transition expectations in due course.
- Maturity levels do not convert. A Maturity Level Two result is a starting point for a gap analysis, not an Essentials rating.
- Keep existing obligations. Organisations should continue to meet any obligation that requires Essential Eight implementation or reporting.
Phases set the order. Ratings measure the result
"Priority phases are a sequencing mechanism, not a rating."
The FAQ says the series moves from maturity levels to phased priorities. Each chapter groups its domains into priority phases, and ASD is explicit that a phase is not a measure of security. The senior executive guide gives the example. A statement such as "we have reached priority phase 2" describes implementation scope, not how secure the organisation is.
In the enterprise IT chapter, priority phase 1 is Boundary services and Identity services. Phase 2 is Critical processes and services and Privileged environments. Phase 3 is Business systems and User devices. The two capability domains run across all phases. The OT chapter orders them differently for operational safety, putting Boundary services and Critical processes and services in phase 1.
Security posture is measured by effectiveness ratings. Each action is assessed in each domain it applies to and rated not effective, partially effective or fully effective, with a fourth status of not assessed. A principle takes the lowest rating of its actions in that domain. Domain results are reported as a percentage from a weighted calculation, and the enterprise IT workbook scores a partially effective principle as half.
The assessment looks for evidence that an action works, not that it exists. An assessor weighs coverage, consistency, currency and evidence quality. ASD's evidence scale runs from excellent, which "provides direct evidence that the action works as intended in the live environment", down to poor, which "shows or asserts that the action exists" without demonstrating it is working. The assessment process guide puts it in four words. "Deployment is not effectiveness."
Organisations can assess themselves. The implementation planning guide says engaging an independent assessor "is not required", but it also says to include periodic independent assessment in the reassessment cadence, particularly where external assurance is required. ASD says it will develop a training course for assessors. The release describes no accreditation scheme.
How the rating works
Assessment- The scale has four ratings, not maturity levels. ASD says not assessed must stay distinguishable from not effective in all reporting.
- One weak action caps the principle. The lowest action rating sets the principle rating for that domain.
- Collect operational evidence. Deployment records alone are unlikely to support a fully effective rating.
Written for large organisations and mandated for no one yet
ASD wrote the series "primarily for Commonwealth entities, critical infrastructure owners and operators, and large organisations".
Small and medium sized businesses "can still use this guidance where relevant", and ASD says the outcomes "are equally important for smaller organisations". It points smaller businesses to its tailored small business guidance on cyber.gov.au.
No document in the release requires any organisation to adopt the Essentials. The word must appears in the documents, but every instruction worded that way applies to organisations that adopt or assess against the framework, such as the FAQ's line that organisations adopting the Essentials "must undertake scoping activities". The Protective Security Policy Framework, the Security of Critical Infrastructure Act and named regulators do not appear anywhere in the release.
If you sell to government, read the transition guide closely. It says Maturity Level Two "was the required baseline for Commonwealth entities and many Australian critical infrastructure operators". That is past tense, but no document in the release says the baseline has been withdrawn, and the same guide tells organisations to "continue to meet any regulatory, contractual or other obligations that require Essential Eight implementation or reporting". The senior executive guide adds that organisations should follow any direction issued by relevant regulators. A contract or regulator that asks for an Essential Eight maturity level today still asks for it.
ASD has also promised more. The FAQ says it will publish a strategy document for future work on the Essentials, and the assessment process guide says guidance on assessing suppliers and third parties will come later.
The cloud chapter is written for organisations that run entirely or predominantly on SaaS and PaaS. Where an organisation runs its own infrastructure, ASD points it to the enterprise IT chapter for that part and says most organisations will need both chapters over time. All but one cloud action carry a marker for whether it sits with the customer, the provider or a supplied capability, and ASD calls those markers "indicative rather than determinative". The OT chapter treats every device inside an OT system as privileged.
Scope and obligations
ASD documents- ASD has set no mandate and no deadline. It says it will advise on transition expectations after talking with regulators.
- Existing Essential Eight obligations still apply. Contracts and regulators that require it are unchanged by this release.
- Smaller businesses are not the target audience. ASD still says the outcomes matter for smaller organisations.
Governance is now assessed, and detection now has its own domain
The transition guide lists what the Essential Eight never assessed. The Governance and culture domain covers executive cyber security accountability, cyber security resourcing, security risk management assurance, supplier cyber security assurance, artificial intelligence accountability and legacy system management. ASD says "these areas were not assessed as part of the Essential Eight maturity model".
Asset identification "extends beyond the asset discovery requirements of the Essential Eight", covering infrastructure, operating systems, applications, identities, credentials and data as distinct assets. ASD gives three examples of protect principles with no direct Essential Eight equivalent, Content filtering, Cyber security awareness training and Cyber supply chain security.
Detection is not new, but its place is. The Essential Eight included logging, monitoring and incident response requirements within individual mitigation strategies. The enterprise IT chapter brings them together in the Visibility and response domain, which applies across all phases and expands as more technical domains are implemented.
ASD's argument for the change is qualitative. The case for change publication contains no statistics and cites ASD's Annual Cyber Threat Report without a year or a figure. Its central line is that "a fixed set of prescriptive controls does not always translate across different technology environments or remain suitable as threats and technologies change".
New work for Essential Eight organisations
Transition guide- Governance is now assessed. That includes executive accountability for AI. The evidence guide's optional indicators look for a named executive.
- Suppliers come into scope. Supplier cyber security assurance and cyber supply chain security are both principles.
- Do not defer the capability domains. ASD lists ignoring them as a common transition pitfall.
AI is a risk, a tool and an asset to govern
ASD accepts that prompt injection cannot be completely prevented, so it relies on layered protection.
ASD published a companion paper on AI. It says the Essentials apply "regardless of whether an organisation consumes, develops or deploys artificial intelligence", and that organisations "should consider AI as a source of cyber security risk, a capability that can support cyber defence and an asset that needs to be identified and governed".
On attackers, ASD says AI "has not fundamentally changed how adversaries gain access to and move through an environment" but "has made existing attacks faster, cheaper and available to more people". On AI systems an organisation runs, it names indirect prompt injection through emails, documents or web content processed by AI agents, tampered models from public sources, and sensitive data sent to unapproved AI services. Because prompt injection cannot be completely prevented, ASD asks for layered protection, including design that ensures a manipulated model cannot exceed the access it has been granted.
The paper treats AI tools as identities. "AI tools can be given identities, permissions and access of their own", and organisations should govern them like other identities. In cloud environments, each AI agent should have "an owned non-person identity that is constrained to its intended context", and agents with access to SaaS administration or cloud control planes should be treated as privileged with their actions recorded.
Executive artificial intelligence accountability is the only principle named for AI. The paper says most principles in each chapter apply to AI as they do to other technologies, although implementation may differ, and it adds specific AI notes for a subset of them. The cloud chapter goes further with an action requiring executive or delegate approval before AI functions are enabled in SaaS or PaaS services. The PDF limits this to material AI functions and adds a review of accessible data, permissions, retention, logging, agents and connectors, but the web page drops both. The AI paper itself is guidance. It uses should throughout and never must.
AI in the framework
AI paper- Prompt injection is not fully preventable. Access limits are one layer among several.
- Give agents their own identities. In cloud, each agent gets an owned identity of its own, separate from any person and constrained to its context, and its admin actions are recorded.
- Make AI an executive accountability. Back it with approval, risk assessment, oversight and review of AI use cases.
Quote the source, because the copies disagree
ASD published most documents as a PDF and a web page, and in places they set different tests.
The cloud chapter's PDF and web page differ in wording in 12 of its 78 actions. In two GOV-09 actions, an or in the PDF becomes an and on the web page. In the adoption action, that changes which high risk SaaS and PaaS services need executive approval. In the second, it changes which platforms must express security requirements as a condition of use. The cloud AI approval action also loses the word material and its review list on the web page, so the web version covers every SaaS or PaaS AI function. ASD does not say which version prevails.
In the enterprise IT evidence guide, 15 of the 529 indicator statements differ in wording between the PDF, the web page and the workbook, and a further 10 differ only in punctuation. Most are trivial, but the secret storage action changes the test. Its fully effective indicator in the PDF expects all authentication keys, secrets and tokens within scope to be held in approved secure repositories, while the web page and workbook accept documented, risk assessed exceptions. The indicators are optional, but that difference changes what fully effective looks like.
The workbook reports a domain with nothing yet assessed as zero per cent, while the assessment process guide's own example shows N/A for such a domain and says not assessed must stay distinct from not effective. The transition guide tags its mapping tables ML1, ML2 and ML3 without defining them, says content filtering has no direct Essential Eight equivalent and then maps user application hardening to it, and maps the patching strategies to legacy system management while saying that area was not assessed under the Essential Eight. The assessment process guide says the indicators are provided as an annex to that guide, but they are published only in the separate evidence guide for enterprise IT. The implementation planning guide says its figure shows four asset categories, but the figure, the guide's next paragraph and the assessment process guide all list six.
Indicators of good practice, an evidence guide and a workbook exist only for enterprise IT. The transition guide says the enterprise IT chapter outranks its own copies of the actions, but no document says whether the PDF or the web page of a chapter prevails. None of this changes the direction of the framework. It does mean any compliance claim should quote the exact version relied on.
How to read the release
Method- The PDF and web page differ. Record which version you assessed against.
- Assessment support is uneven. Only enterprise IT has indicators, an evidence guide and a workbook.
- Some figures are ours. The counts on this page come from the documents, not from ASD statements.
Keep the work going and map it before you extend it
Steps drawn from ASD's transition guide, FAQ and senior executive guide
ASD guidance- Continue approved Essential Eight work. Map existing and planned work to the enterprise IT chapter before deciding whether it continues unchanged, and do not start work only to hit a superseded target unless a regulator or other obligation still requires it or it still addresses material cyber security risk.
- Record your current position. Capture recent assessment results, existing controls, exception and risk registers, remediation plans and planned uplift.
- Scope the phase one domains. For enterprise IT that means Governance and culture, Visibility and response, Boundary services and Identity services.
- Run a gap analysis. Classify each action as already effectively addressed, partially addressed or not addressed. ASD says these are gap findings, not formal ratings.
- Define executive accountability. ASD says executive and board cyber security accountabilities should be formally defined and established.
- Keep meeting current obligations. Follow any direction your regulator issues and watch for ASD's advice on transition expectations.
Frequently asked questions
ASD says it has evolved the Essential Eight into the ASD Essentials for enterprise IT. Its FAQ calls this replacing the Essential Eight and its transition guide refers to a superseded Essential Eight target. No document retires the Essential Eight or sets an end date, and ASD says it will advise on transition expectations in due course. Existing Essential Eight work carries forward, but ASD says it should be assessed against the new framework rather than assumed to be equivalent.
Every claim, in context
Related Field Notes
Read nextPlan the transition