- ASD Essentials replaces fixed maturity levels with principles, actions and domains, so the question changes from "which level are we?" to "is each control working where it matters?"
- Your Essential Eight investment is not wasted. Every mitigation strategy maps to at least one principle, but old maturity ratings do not convert into new ones.
- Priority phase 1 covers Boundary services and Identity services, while Governance and culture and Visibility and response run from day one.
- Each action is rated not assessed, not effective, partially effective or fully effective, and a principle takes the rating of its weakest action.
- Start with a phase 1 gap analysis and build evidence as you deploy, not when the assessor arrives.
ASD Essentials (ASD's own shorthand is "the Essentials") is the Australian Signals Directorate's evolution of the Essential Eight, a principles-based cyber security framework that changes how Australian organisations plan, fund and prove their security. Instead of choosing a maturity level and working through eight mitigation strategies, you scope business functions into domains, implement outcome-based actions in a recommended order and report posture by domain. If you have already invested in the Essential Eight, you are not starting again. You are being asked to extend that work and show that it holds up.
The Essential Eight told you what to deploy. ASD Essentials asks whether it works, in every domain, with evidence to prove it. That is a better question.
Robert Kirtley, Head of Cyber Security · Virtuelle GroupASD Essentials Explained: Principles, Actions and Domains
The ASD Essentials series is a framework that gives organisations one consistent approach to cyber security across different technology environments. Each chapter applies the same three layers. A principle describes the outcome you are trying to achieve. An action describes what needs to be done to achieve it. A domain describes where that action applies.
The practical effect is that no control is judged in isolation. An action is implemented and assessed in the context of a particular domain, so the same action can be fully effective in one place and only partially effective in another. That is a real shift from a checklist model, where a control either exists or it does not.
Current chapters cover enterprise IT, cloud and operational technology, and more can be added. Some organisations will need only one chapter. Others will need several, because different parts of an environment, or a single business function, can depend on assets covered by more than one. Actions are technology-agnostic, so you choose the products and architecture, and where appropriate they are mapped to MITRE ATT&CK techniques. For example, phishing-resistant MFA maps to techniques such as valid accounts (T1078) and brute force (T1110), which shows the adversary behaviour the action is meant to disrupt. ASD notes that many other techniques may be relevant to the same action.
Principle, action, domain: Think of it as outcome, requirement and location. If you cannot say which domain an action is being applied to, you cannot say whether it is effective.
Why ASD Moved Beyond the Essential Eight
ASD's reasoning is straightforward. Sophisticated tradecraft is now used against a broad range of Australian organisations, and highly capable adversaries now pose a credible threat to a broader range of organisations than before. Malicious actors also operate at scale and reach organisations through their suppliers, service providers and other connections. ASD's Annual Cyber Threat Report consistently finds that threats affect organisations across all sectors, regardless of size or profile.
The Essential Eight maturity model gave organisations a prioritised set of controls. But a fixed set of prescriptive controls does not always translate across enterprise IT, cloud and operational technology, and it does not always stay suitable as threats and technology change. Artificial intelligence is the obvious current example. A principles-based model lets the outcomes stay stable while the way you achieve them adapts.
ASD describes the series as threat-informed, flexible, compatible with the Information Security Manual and other recognised frameworks, and future-focused. For executives, the most important change is accountability. The board or executive committee is accountable for setting, monitoring and adjusting organisational risk tolerance and appetite, and executive commitment is now assessable content within the Governance and culture domain.
A priority phase is not a maturity level. Saying "we have reached phase 2" describes implementation scope, not how secure you are. Security posture is expressed through effectiveness ratings, and the framework deliberately does not give you a single overall level.
Essential Eight versus ASD Essentials at a glance
| Topic | Essential Eight | ASD Essentials |
|---|---|---|
| Core structure | Eight mitigation strategies, each with requirements | Principles supported by actions, applied by domain |
| Approach | Prescriptive and solution specific | Outcome-driven and technology agnostic |
| Scope | Requirements applied across the whole IT environment | Eight domains of assets and functions that share similar risk (enterprise IT chapter) |
| Sequencing | Maturity levels, selected based on adversary tradecraft | Priority phases that recommend an order of work. They are not maturity or assurance ratings |
| Assessment | Assessment against specific requirements | Four-tier, outcome-based rating of each action in each domain |
| Reporting | Maturity level | Principle ratings by domain, with a summary view and a detailed view |
Source: ASD, Transitioning from the Essential Eight, summarised by Virtuelle Group.
The Eight Domains and Three Priority Phases Explained
In the enterprise IT chapter, six technical domains split your environment by the function technology performs, not by product or org chart. Two capability domains, Governance and culture and Visibility and response, largely cover programs and artefacts rather than digital systems. Domains group assets with comparable exposure and consequence of compromise, so effort goes where it reduces the most risk.
ASD recommends addressing earlier phases before later ones, because each phase builds on the one before. Phase 1 targets the most common entry and escalation paths. Phase 2 hardens the highest-consequence assets and the elevated access used to administer them. Phase 3 extends coverage to the rest of the enterprise. Organisations with specific threat intelligence or regulatory drivers can adjust the sequence, but any departure should be a documented, risk-based decision.
Scoping is where many programs stumble. Domains decompose an environment by function, not by business structure, so a subsidiary or brand is not a domain. Where two businesses share a function such as an identity tenancy, a gateway or a security operations capability, you scope that shared function once and record the environments that consume it. Shared functions typically carry a higher consequence of compromise, which should be reflected when you prioritise within a phase. Non-production environments are in scope too, and if one holds production trust or can modify production systems, it needs production-equivalent protection.
The good news is that scoping is not a full enterprise asset discovery exercise. You scope only the phase 1 domains first, across six asset categories: infrastructure, operating systems, applications, identities, credentials and data. Imperfect asset visibility is recorded as a finding and addressed through the Visibility and response domain, not treated as a reason to wait.
What Happens to Your Essential Eight Investment
ASD is explicit that existing investment carries forward. Every Essential Eight mitigation strategy maps to at least one principle, and your controls, tooling and evidence feed the gap analysis. What does not carry forward is the rating. Maturity level results do not convert into effectiveness ratings, because the two models assess different things.
Organisations that achieved Maturity Level Two can expect many controls to contribute to early phase actions, including phishing-resistant MFA, patching of internet-facing services, privileged access, application control and central logging. Those that sustained Maturity Level Three can reuse a broader range of controls and evidence. In both cases a gap analysis is still necessary, and higher maturity may reduce the transition effort. If you are part-way through an uplift program, map the completed and planned work to the new actions rather than discarding it, and do not start work solely to hit a superseded Essential Eight target unless a regulator or other obligation still requires it or it addresses material cyber security risk.
Where existing controls typically need strengthening
-
01
Principle breadth
Many Essential Eight strategies map to principles with a wider outcome. Macro restrictions, for example, contribute to the Trustworthy software principle, which also expects supported, verified, organisation-authorised software and controlled administrative tooling. Your macro controls still count. They just cover part of the requirement. -
02
Domain scope
An enterprise-wide control can be fully effective in one domain and only partially effective in another. Assess the control per domain, against that domain's assets and risk, rather than assuming one result applies everywhere. -
03
Evidence of operation
Configuration records show a control is deployed, not that it works. Assessors look at coverage, consistency, currency and evidence quality, so expect to add validation results, drift reports, review records and restoration tests. -
04
Genuinely new requirements
Governance principles such as executive accountability, resourcing, security risk management assurance, supplier assurance and AI accountability were not assessed under the Essential Eight maturity model. The enterprise IT chapter also includes actions with no direct Essential Eight equivalent, including credential exposure and supply chain security. -
05
Stale evidence and expired exceptions
An exception that expired without re-approval, a compensating control that no longer operates or a risk acceptance based on an old threat picture should not be relied on. ASD says each should be treated as a finding.
MFA is a good illustration of how the scope widens. Phishing-resistant MFA remains directly relevant, but it is only one part of the Identity, credential and access management principle. The same principle also expects you to:
- Identify and disable or remove default and unused accounts on a regular basis.
- Store keys, secrets and tokens in approved secure repositories protected by access controls, including MFA.
- Scan codebases, configuration files, file shares and collaboration platforms for unsecured credentials.
- Disable legacy authentication protocols, or restrict and monitor them with a time-bound decommissioning plan.
- Keep user, machine, system and service account credentials unique, particularly in high-privilege contexts.
How ASD Essentials Assessment Works in Practice
Assessment follows four stages: planning and preparation, plan approval, the assessment itself, and aggregation and reporting. Domains are assessed individually and in any order. Each applicable action gets one of four ratings. Not assessed is a neutral status for work not yet examined or where evidence is insufficient, and it must stay distinct from not effective. Partially effective requires a genuine security benefit, not just activity. Starting a project or having a plan is not partial effectiveness. Fully effective means the outcome is demonstrably achieved across the domain with sufficient evidence.
Assessors lean on indicators of good practice, which describe what each rating typically looks like, but they are a structural aid and not a checklist. A single not effective statement is normally decisive, though a documented compensating arrangement can justify a higher rating.
Results roll up using a weakest link rule. A principle takes the lowest rating of its applicable actions in that domain. For reporting, not effective scores 0, partially effective 0.5 and fully effective 1, and the domain percentage is the total score divided by the number of principles. ASD's worked example has five principles fully effective, four partially effective and one not effective, which gives 70 percent. Reports must include a summary view and a detailed view, so that visible progress never hides outstanding risk.
Design for assessment from day one. Controls built from a single approved baseline, reconciled against a version-controlled scope statement and backed by an exception register with named owners and expiry dates generate their own evidence. ASD notes that building this in during implementation is typically less resource-intensive than reconstructing evidence later, which often results in avoidable rework.
Evidence quality also matters. ASD describes four broad levels, from poor evidence that merely asserts a control exists, through fair and good, up to excellent evidence that directly proves the outcome in the live environment. Technical validation such as control testing, purple team exercises or breach and attack simulation can lift evidence quality, but it carries operational risk and must be planned and approved in advance. Independent assessment is not required. Where it is affordable and proportionate, it adds a fresh view and credibility with regulators and governing bodies.
AI Is an Asset, a Threat and a Tool Under ASD Essentials
ASD applies the Essentials regardless of whether an organisation consumes, develops or deploys AI. It treats AI in three ways. As a threat, AI makes existing attacks faster, cheaper and more accessible, including synthetic voice and video used to impersonate trusted people and deceive help desks or those who approve payments or access, and AI systems themselves can be attacked through methods such as indirect prompt injection. As a tool, AI-enabled security products can speed up triage and correlation, but they are AI assets themselves and accountability stays with people. As an asset, AI systems sit inside your domain scope.
The mapping is practical. AI systems that support core outcomes are likely to be scoped into Critical processes and services, and AI embedded in general platforms into Business systems. Public-facing AI services and APIs are relevant to Boundary services, AI agents and their non-person identities to Identity services, and AI tools capable of administrative actions to Privileged environments. Under the Executive AI accountability principle, the board or executive committee is accountable for ensuring AI is secure, controllable, human-supervised and used ethically.
In cloud environments, ASD expects executive or delegate approval before SaaS or PaaS AI functions are enabled, AI capabilities recorded in the shared responsibility register, and tenant-level AI settings such as web grounding, plugins, connectors and data access scopes included in approved configuration baselines. Least privilege must also address overshared data that AI assistants can surface, and logging should capture prompts, outputs and agent actions.
In a Microsoft 365 tenant, this typically means reviewing oversharing in SharePoint and Teams before wider Copilot access, giving each agent an owned and constrained identity, baselining Copilot connector and plugin settings, and confirming Microsoft Purview and audit logging capture AI activity. This is our interpretation of how the cloud and enterprise IT AI considerations apply to Microsoft 365, not wording taken from ASD.
What Executives, IT Managers and Security Teams Should Do Next
The framework does not set implementation timeframes. It asks for a clear sequence of work and the artefacts that prove it. Here is how we would split the first steps by role.
Executives and boards
Formalise executive and board accountabilities and agree risk appetite. Agree the reporting format up front: summary and detailed views, with not assessed used honestly as a neutral status. Ask for funding to be split into capability build, operating uplift and assessment, and expect the shape of spend to change across tranches. Capability build falls as patterns such as logging, baselines and authentication are reused, operating uplift grows as more domains move into sustainment, and assessment cost stays broadly steady. There is no completion date for cyber security, so the business case should separate the program end date from the ongoing run rate.
IT managers
Document your operating context, then run a scoping workshop for the four phase 1 domains. Issue a version-controlled scope statement for each domain, listing in-scope assets by category, exclusions with reasons, multi-domain assets and visibility gaps. Classify every action as addressed, partially addressed or not addressed. Those are planning labels, not ratings. Then design cross-cutting capabilities once as patterns. MFA, configuration baselines with drift detection, centralised logging, vulnerability management and backup architecture are the best candidates, and ASD's guidance is that one pattern with one exception process and one evidence model avoids the duplicated effort of building the same capability separately in each domain. Domain-focused delivery is the recommended default early in the journey.
Security professionals
Treat deployment and effectiveness as separate questions. Build a per-domain evidence register that maps each action to its control, scope coverage, evidence source and self-assessed rating, and record the rating and implementation status in separate fields. Use the ATT&CK mapping to prioritise within a phase, not across phases, and remember it is generalised and informs rather than replaces risk management. Schedule validation after remediation, keep an exception register with named owners, approvals and expiry dates, and set a reassessment cadence that triggers earlier after material change or a relevant incident.
Avoid the common transition mistakes. ASD flags treating phases as maturity levels, claiming equivalence instead of assessing, assessing the enterprise instead of the domain, deferring the two capability domains, trying to transition every domain at once, reusing stale evidence and overlooking new requirements.
Keep meeting any existing regulatory, contractual or reporting obligations during the transition, and follow direction from the relevant authority. ASD is clear that organisations with obligations expressed in Essential Eight terms should continue to meet them.
Who This Guidance Is For
ASD's guidance is written for organisations across sectors, with separate chapters for enterprise IT, cloud and operational technology, and ASD notes that cyber threats affect organisations regardless of size or profile. Maturity Level Two was the baseline for Commonwealth entities and many critical infrastructure operators, so those organisations have the most existing evidence to reuse. For our clients in financial services, healthcare, government, professional services and technology, the practical questions are the same: what carries over, what is new, and what to fund first.
It also matters if you have already deployed Microsoft 365 Copilot or AI agents. AI sits inside the framework, so existing deployments belong in your asset scope, your identity and access reviews and your logging design from the start.
Frequently Asked Questions About ASD Essentials
What is ASD Essentials?
ASD Essentials is a series of cyber security guidance from the Australian Signals Directorate that evolves the Essential Eight. Each chapter uses principles, actions and domains to describe the outcomes an organisation should achieve, what it needs to do and where it applies. Current chapters cover enterprise IT, cloud and operational technology.
Is the Essential Eight being retired?
ASD describes ASD Essentials as an evolution of the Essential Eight, and existing controls, tooling and evidence carry forward. Organisations with regulatory or contractual obligations expressed in Essential Eight terms should continue to meet them as directed by the relevant authority, so check your regulator's current guidance.
What is the difference between the Essential Eight and ASD Essentials?
The Essential Eight is eight prescriptive mitigation strategies assessed through maturity levels. ASD Essentials uses principles, actions and domains, recommends an order of work through priority phases, and assesses each action in each domain on a four-tier, outcome-based scale.
Do Essential Eight maturity levels convert into ASD Essentials ratings?
No. Maturity level ratings do not automatically convert into effectiveness ratings. Use your existing implementation and assessment evidence as the starting point for a gap analysis, then rate each action in each applicable domain.
What are the ASD Essentials priority phases?
For enterprise IT, priority phase 1 covers Boundary services and Identity services, phase 2 covers Critical processes and services and Privileged environments, and phase 3 covers Business systems and User devices. Governance and culture, and Visibility and response, apply across all phases. Phases are an implementation sequence, not a measure of security.
Where should we start with ASD Essentials?
Confirm executive accountabilities and risk appetite, record your operating context, and scope the phase 1 domains along with the two capability domains. Then run a gap analysis that classifies each action as addressed, partially addressed or not addressed, and build your evidence register as controls are delivered.
Do we need an independent assessor for ASD Essentials?
No. Independent assessment is not required, but where it is proportionate and affordable it brings a fresh perspective and strengthens the credibility of posture reporting to regulators and governing bodies.
Sharing this on LinkedIn? The most useful point for your network is that Essential Eight maturity levels do not convert into ASD Essentials ratings. Tag your CISO, IT manager or Microsoft partner and ask how they are planning the transition. Share this article →
Sources: this article draws on the ASD Essentials series published by the Australian Signals Directorate on cyber.gov.au, including What is the Essentials?, The case for change, The Essentials for senior executives, the Reading guide, the Implementation planning guide, the Assessment process guide, Transitioning from the Essential Eight and the AI considerations within the Essentials publication. For the authoritative requirements, refer to the Essentials for enterprise IT chapter, with companion chapters for cloud and OT. ASD material is © Commonwealth of Australia 2026, licensed under CC BY 4.0, and has been summarised and adapted here. Commentary and interpretation are Virtuelle Group's own, and the ASD publications remain the authoritative source. This article is general information and not legal advice.
