AI agents investigate every alert, add context, and prepare cases for response, on a full-stack SecOps platform that captures and correlates all your security data.
Cloud-based SIEM platform providing visibility across all your data sources
Every alert investigated, with a verdict and the evidence behind it
Manage your external footprint, publicly available data, and Dark Web leaks
Log management and threat detection across any of your log sources
Get ultimate assurance that your environment is free from threat actors
Fully featured distrubuted NDR for on-premises and public cloud environments
A SecOps platform purpose-built for industrial and OT environments
Integrated endpoint agent providing deep visibility, response and forensics
Deploy honeypots and honeytokens and stay ahead of threat actors
24x7 security operations from our Australian SOC. AI investigates every alert, and experienced analysts validate findings and contain threats around the clock.
24x7 managed detection and response across endpoint, network, cloud, identity, and log sources
AI investigations and 24x7 MDR on the Microsoft Sentinel you already own
Eyes-on-glass SOC and continuous threat hunting
Expert hunters and AI agents find attacker activity your alerts missed
Quickly recover from cyber attacks and breaches
ThreatDefence is the only SecOps as a Service company providing broad coverage across your entire technology stack with evidence-based security.
We provide security teams with full-stack SecOps infrastructure – you get deep visibility from day one, gain control over your security data, and get access to a comprehensive set of ready-to-use tools, detections, workflows, playbooks and scenarios.
24x7 SOC, Continuous Monitoring, Threat Containment and Incident Response
Visibility and actionable insights for all IT assets
Leverage our Cyber Range to train defenders based on real-world scenarios and simulations
OT and industrial cyber security services for critical infrastructure
Monitoring, evidence and a 24x7 SOC in one platform
Compliance monitoring, evidence and board reporting
Privacy Act reform impacts, obligations, and practical security considerations
Monitoring and compliance support for critical infrastructure environments
A practical guide to securing critical infrastructure with continuous monitoring
A practical buyer’s guide for schools evaluating SIEM and SOC services
A practical guide to selecting the right SIEM and SOC service for local government
Articles on security operations, AI and compliance
Events, awards and company news
Read what our customers say about us
Solution briefs and datasheets
How we keep your data secure
Technical support and knowledge base
Guides, case studies, and advisories in one place
How AI agents investigate alerts and run security operations
Free ebook: a practical guide to adopting an AI SOC platform
A practical guide to incident response and digital forensics
Where SOAR playbooks fit and where AI agents take over
Free ebook: modern security operations with Microsoft Sentinel
How the framework is structured and what changes from the Essential Eight
November 10, 2026
November 6, 2026
We provide end-to-end SecOps solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs).
Find out how you can become a ThreatDefence partner.
Protect your entire technology stack and build your SecOps on your own pace
White-labeled AI SOC for every client tenant, co-managed with our SOC team
Launch your SOC business without any upfront investment
Embed security operations, threat intelligence and exposure data in your product
Sovereign SOC for Australian MSPs and MSSPs, with onshore analysts and client data
Set the rules for closing alerts automatically, with evidence checks and review
How MSPs deliver branded security monitoring with a SOC partner
ThreatDefence was an official partner of the Cyber Resilience Summit NSW, 29 October 2026 at Hilton Sydney.
Our team was back at BSides Canberra, and our cyber quiz was a hit again.
Two days in Perth with our partner Ever Nimble, on security operations and cyber resilience.
Sponsors of the AUSCERT Cyber Security Conference on the Gold Coast.
Sponsors of the Gartner Security & Risk Management Summit in March.
Sponsors of the Cyber Security for Critical Assets Summit in Perth, February 2026.
Expert conversations with speakers and attendees at CyberCon Melbourne 2025.
ASD Essentials is the Australian Signals Directorate’s cyber security framework for strengthening and assessing cyber resilience in enterprise IT, operational technology and cloud environments.
Published on October 15, 2026, it builds on the Essential Eight. Each environment has its own chapter, which sets out security outcomes, the actions that achieve them and where those actions apply.
The Essential Eight is still maintained, and obligations that reference it still have to be met. What ASD Essentials asks of an organisation depends on which chapter applies, how its assets fall into the enterprise IT domains and where the priority phases place the first work.
ASD Essentials is a series of cyber security publications covering enterprise IT, operational technology and cloud environments. ASD describes it as an evolution of Australia’s widely adopted Essential Eight framework.
an evolution of Australia’s widely adopted Essential Eight framework.
The framework is also called the Essentials or the Essentials series. Alongside the environment-specific chapters, it includes overview publications and supporting guidance for implementation, transition and assessment.
ASD developed the series primarily for:
Government agencies, including those reporting under the Protective Security Policy Framework.
Organisations managing important services, including those subject to risk management program obligations.
Enterprises whose scale, technology dependencies, complexity or regulatory exposure require structured cyber security management.
ASD’s FAQ confirms that small and medium businesses can also use the framework where relevant.
The principles come from ASD’s Information Security Manual (ISM) and align with its Modern Defensible Architecture. Where appropriate, actions map to MITRE ATT&CK techniques, so a security requirement can be traced to the adversary behaviour it addresses.
Where the Essential Eight has eight mitigation strategies and maturity levels, ASD Essentials organises security around principles, actions and domains. The enterprise IT chapter is the closest successor to the Essential Eight, but it covers a different scope and is assessed differently.
ASD Essentials currently has chapters for enterprise IT, operational technology and cloud. Each uses the same principles, actions and domains structure, with requirements adapted to the technology environment.
ASD says further chapters may follow. It also expects most organisations to need both enterprise IT and cloud over time.
The chapters can be applied independently, in the order that best fits an organisation’s environments, obligations and risk. ASD’s guidance, Which chapter should I start with?, recommends weighing these questions together:
Which chapter should I start with?
Identify the main technology environments, the functions they support and the assets involved. An overview is enough at this stage. Comprehensive asset discovery can come later.
Identify regulatory, contractual and other requirements affecting each environment. ASD notes that an obligation establishes a floor, not a priority order.
an obligation establishes a floor, not a priority order.
Compare existing protections with the outcomes described in each chapter. A large gap does not automatically make that environment the first priority.
Consider the likelihood and consequences of compromise. Internet-facing systems, large user populations, unclear access controls and known sector targeting each raise the likelihood.
ASD defines enterprise IT as environments operated by organisations whose scale, complexity, regulatory exposure or reliance on technology requires a structured and deliberate approach to cyber security.
whose scale, complexity, regulatory exposure or reliance on technology requires a structured and deliberate approach
Size alone does not decide whether the chapter applies. Smaller organisations may also use it, although how they implement it and what their service providers are responsible for may differ.
Whether an environment belongs under enterprise IT or cloud depends largely on operational control.
An organisation operating its own servers, operating systems, applications, identity infrastructure and network architecture generally starts with enterprise IT. That remains true when the systems run on infrastructure as a service (IaaS).
ASD explains that using another party’s infrastructure does not materially change what the organisation must do.
does not materially change what the organisation must do.
An organisation may need several chapters, because one business function often depends on more than one technology environment. ASD puts the choice between enterprise IT and cloud plainly: The question is which to begin with, not which to adopt.
The question is which to begin with, not which to adopt.
When more than one chapter applies, list the identities, infrastructure, services and access paths the environments share. A compromise in one environment can open a way into another, even when the two are assessed under separate chapters. An administrator account that signs in to both an on-premises directory and a SaaS tenancy is a typical case.
Every part of ASD Essentials is built from the same pieces: a principle states the security outcome, an action describes the work and a domain says where that work applies.
State the intended cyber security outcome and keep their ISM identifiers. Examples include GOV-01 Executive cyber security accountability, DET-01 Centralised event logging and PRO-13 Identity, credential and access management.
Describe the work that supports a principle. One PRO-13 action reads Use phishing-resistant MFA for users authenticating to systems.
Use phishing-resistant MFA for users authenticating to systems.
Group business functions and assets with similar security risks. Each applicable action is implemented and assessed separately in every domain it applies to.
Principle identifiers follow the ISM families: governance (GOV), identification (IDE), protection (PRO), detection (DET) and response (RES). Each identifier traces back to the underlying ISM principle.
The enterprise IT chapter contains 28 principles and 58 actions, counted from ASD’s assessment workbook because the chapter text does not state these totals.
One action can apply to several domains. An organisation might run a single authentication platform across all of them and still find the implementation effective for some systems and incomplete for others. For that reason the action is assessed within each domain.
Non-production environments are covered too. ASD includes development, testing and staging systems, and assigns them to domains by their function, connectivity, data, privileges and potential impact on production.
A non-production system that holds production trust or administrative access, or can modify or deploy to production, should get the same protection as the production environment it can affect.
ASD also treats AI as an asset when scoping domains, alongside governance obligations under GOV-08 Executive artificial intelligence accountability.
ASD Essentials for enterprise IT has capability domains, which apply throughout implementation, and technical domains, which are sequenced into priority phases.
The capability domains are Governance and culture and Visibility and response. The technical domains group systems, services and assets with similar security risks.
The capability domains grow as technical implementation progresses. Governance and culture sets accountability and decision-making. Visibility and response builds the capabilities needed to identify assets, detect incidents and coordinate response.
An action may appear in several technical domains. The same phishing-resistant MFA solution, for example, might protect Boundary services effectively while important applications in Business systems sit outside its coverage.
Priority phases give the recommended order for improving the technical domains. ASD states: Priority phases are a sequencing mechanism, not a rating or maturity model.
Priority phases are a sequencing mechanism, not a rating or maturity model.
An organisation working on an earlier phase is not operating at a lower standard than one further along.
is not operating at a lower standard
The order follows where ASD expects security improvements to reduce risk most effectively.
ASD prioritises these domains because they are common pathways for adversaries seeking initial access.
common pathways for adversaries seeking initial access.
ASD explains that addressing these domains reduces the likelihood that an adversary can escalate access, while protecting systems important to organisational operations.
reduces the likelihood that an adversary can escalate access,
These follow so organisations can build on the protections established for boundary, identity, privileged and critical environments.
build on the protections established for boundary, identity, privileged and critical environments.
ASD bases this order on attacker behaviour, commonly observed weaknesses across Australian organisations and the availability of mature security solutions.
The sequence is a recommended starting point. Active threats, regulatory obligations or a planned technology refresh may justify addressing particular domains earlier, provided the reasoning is documented.
Assessment results are recorded against the applicable actions within each domain. No single maturity level or phase is awarded.
The ASD Essentials assessment guide explains the effectiveness ratings, supporting evidence and reporting method.
Asset scoping in ASD Essentials decides which systems, services and information assets belong to each technical domain. An asset is assigned by its function and security significance. Its product category and its organisational owner do not decide the domain.
A practical scoping review asks what an asset does, what it connects to, which privileges it holds and what its compromise could lead to. The answers help determine which domain descriptions apply.
ASD’s asset scoping guide asks organisations to consider each asset against every applicable domain description. An asset can belong to more than one domain.
An internet-facing application supporting a primary organisational outcome, for example, may belong to both Boundary services and Critical processes and services. A workstation used for routine work and privileged administration may belong to both User devices and Privileged environments.
All actions applicable to those domains then apply to the asset. Where the same action is reached through more than one domain, it is implemented once.
Assessment still needs to account for the asset’s role within each applicable domain.
An environment boundary marks which assets and shared services fall inside a particular implementation scope.
A subsidiary or division may operate its own environment and have separate domain assignments. A shared service, such as a common identity tenancy, is scoped once, however many business units use it.
Review dependencies as well as direct ownership. A service operated centrally may provide authentication, administrative access or other functions across several environments.
ASD’s implementation planning guide gives an example first tranche covering Boundary services and Identity services, together with Governance and culture and Visibility and response.
Existing asset inventories, architecture diagrams and business impact assessments are enough to begin with. Implementation does not have to wait for comprehensive discovery across every technical domain.
Later technical domains can be scoped as their priority phases start. The initial scope still records the gaps in visibility, so that incomplete discovery is addressed later and does not drop out of sight.
Each technical domain gets a version-controlled scope statement.
The statement lists included assets, exclusions, the reason for each exclusion and known visibility gaps. Anyone reading a finding or an assessment rating can then see which assets it covers.
Revisit scoping decisions when systems, dependencies or organisational boundaries change. An asset that was excluded may come into scope after a new connection, administrative role or business dependency is introduced.
ASD’s implementation planning guide asks organisations to assemble an evidence base for each domain before testing assets against its definition.
Examples include configuration management database extracts, network and identity architecture diagrams, business impact assessments, internet-facing service registers and cloud tenancy inventories.
The collection methods are common practice rather than ASD requirements.
imperfect visibility is a finding to record rather than a barrier to starting.
The evidence has to be current enough to represent the environment during the assessment period. An inventory extract taken before a migration, for example, describes systems that may no longer be there.
A dated extract from the system holding the record is generally stronger than a screenshot or hand-maintained list. Screenshots are still usable when they identify the date, scope and tenant.
Reconciliation records are most useful where discovery tools and the approved inventory disagree. They show which differences were investigated, which assets were added and which visibility gaps remain unresolved.
ASD’s implementation planning guide recommends a staged approach to enterprise IT implementation that follows the priority phases, without designing and funding every domain in detail at the beginning.
The initial plan sets the scope, the required improvements and the assessment approach for the first domains. Later phases are refined as implementation progresses.
ASD suggests organising investment into tranches aligned with the priority phases.
Each tranche accounts for capability development, operating improvements and assessment activity. Decision-makers can then tell the initial implementation investment apart from the ongoing cost of maintaining controls.
The cost profile changes as implementation expands. Shared capabilities such as logging, authentication and configuration baselines can reduce implementation costs in later phases. Operating costs may rise as more domains need maintenance, monitoring and assurance.
Each tranche can begin with a gap analysis against applicable actions, using existing controls and evidence. The Essential Eight vs ASD Essentials guide explains how earlier investment carries over to the new framework.
ASD describes domain-focused and principle-focused approaches for organising implementation.
Domain-focused implementation applies the relevant principles and actions within one domain before moving to another.
ASD recommends this as the default for organisations early in implementation. The scope stays manageable, and control implementation and assessment can produce defined outcomes within it.
Principle-focused implementation addresses a principle across relevant domains in priority phase order.
The approach can support consistent implementation and better use of enterprise-wide technologies and licensing. Established security programs may use either approach or combine them.
The choice depends on existing capabilities and the work required. A shared authentication or logging platform may suit a principle-focused approach, while substantial gaps in one domain may favour concentrating the work there.
ASD recommends defining reporting arrangements at the start of implementation.
A useful report shows progress by priority phase and domain, including which areas have been assessed and which are still outside the current assessment scope.
It also separates completed implementation work from evidence of control effectiveness. A control deployed across several domains still needs its effectiveness considered against the applicable actions and assets.
ASD publishes the framework chapters and supporting implementation resources through its ASD Essentials hub.
The material covers framework interpretation, implementation planning, transition, asset scoping and assessment.
As of late 2026, the resources include:
What is the Essentials?, The case for change, The Essentials for senior executives, Which chapter should I start with?, AI considerations within the Essentials, the FAQ, a reading guide and a glossary.
A mapping of Essential Eight strategies to ASD Essentials principles and ASD’s recommended transition pathway for enterprise IT.
Guidance for planning security improvements, conducting assessments and reporting results across chapters.
Separate guidance for defining the scope of enterprise IT and cloud environments.
Indicators of Good Practice for each action, with examples of possible supporting evidence.
An Excel workbook containing an Existing E8 Controls sheet, individual domain sheets, a Domain Summary and a Principle Summary heatmap.
A machine-readable version of the enterprise IT chapter, labelled E4EIT OSCAL v2026.10.15, for use in governance, risk and compliance tools.
Each publication does a different job. The chapters define the principles, actions and domains. The implementation planning guide helps sequence the work. The asset scoping guides support domain assignment, and the assessment process and evidence guides explain how implementation effectiveness is evaluated.
The assessment workbook gives a structured place to record results, and OSCAL supports machine-readable use of the enterprise IT requirements.
The supporting material is still being filled in. The OT chapter has no chapter-specific assessment material yet, while the cloud chapter has its asset scoping guide.
ASD has not published an ASD Essentials tracker. The tracker pages that appear in search results are made by vendors and are not official ASD publications.
ASD Essentials is currently guidance rather than a mandatory replacement for the Essential Eight. ASD describes itself as not a regulator or law enforcement body.
not a regulator or law enforcement body.
Its launch announcement states that organisations should continue to meet their current regulatory obligations until relevant regulators communicate changes.
should continue to meet their current regulatory obligations
As of late 2026, existing requirements continue to reference the Essential Eight:
PSPF Release 2026 requires implementation of all eight strategies at Maturity Level Two. See ASD Essentials for government.
The SOCI risk management program rules include the Essential Eight among accepted frameworks. See ASD Essentials for OT.
DISP members must achieve and maintain the complete Essential Eight at Maturity Level Two.
NSW and Western Australia maintain Essential Eight maturity requirements for their agencies.
ASD’s stakeholder materials indicate that relevant regulators will determine transition timeframes. An organisation can begin implementing ASD Essentials without waiting for a regulatory requirement.
Those already subject to Essential Eight obligations can use their existing controls and evidence as a foundation for ASD Essentials while continuing to satisfy their current requirements. Publishing a new framework does not, on its own, remove an existing reporting or maturity obligation.
ASD published the ASD Essentials series on October 15, 2026, following consultation earlier that year. No formal date has been announced for retiring the Essential Eight.
The published milestones are:
ASD opened its consultation paper for feedback. Consultation also included more than 30 face-to-face workshops across Australian capital cities and targeted engagement for the OT and cloud chapters.
ASD published the ASD Essentials series. Both ASD Essentials and the Essential Eight remain available and maintained on cyber.gov.au during the transition.
ASD’s Annual Cyber Threat Report 2025-26 confirmed that engagement on transitional arrangements would continue into 2027.
The consultation changed the final framework. ASD introduced terminology changes, additional overview publications, stronger executive guidance, expanded domain scoping information and guidance on AI.
Possible transition dates have been mentioned, but they are not official requirements. In June 2026, an ACSC official indicated that ASD would probably begin deprecating the Essential Eight in approximately 12 months and retire it after approximately 24 months. At launch, the expectation was that government agencies would be assessed against both frameworks in 2027.
Neither timeline appears in published ASD or Home Affairs requirements. Treat both as indications, because no regulatory deadline has been announced.
ASD has not finalised every aspect of the transition from the Essential Eight. Its FAQ states that it will advise on expectations for transitioning to the new framework in due course.
will advise on expectations for transitioning to the new framework in due course.
The published guidance leaves these matters open:
The SOCI rules incorporate the Essential Eight Maturity Model as in force from time to time, but do not explain what happens if ASD eventually retires it.
as in force from time to time,
The September 2026 ISM still identifies controls using Essential Eight maturity levels, with no published timetable for changing those references.
The assessment process guide addresses organisations assessing their own environments. ASD says guidance for supplier assessments will follow.
ASD has indicated that it will develop and deliver a training course for assessors.
Preparation for ASD Essentials can go ahead alongside current Essential Eight requirements. Formal transition decisions should follow ASD publications and the directions of relevant regulators.
ThreatDefence runs a 24x7 SOC with its team based in Australia and a 3 min average response under guaranteed SLAs. Threat hunting and an incident response retainer are included in the standard service.
Response actions remain within the authority each customer approves. Case records can be exported for an assessor or at the end of a contract. Australian customers’ data and AI processing stay in Australia.
For phase 1, ThreatDefence ITDR covers risky sign-ins, session token replay and privileged role changes within Identity services.
At the network boundary, and as later phases expand network coverage, NDR detects reconnaissance, command and control beaconing and lateral movement.
ThreatDefence does not certify organisations. The assessor determines ASD Essentials ratings based on the implementation and supporting evidence.
The free ASD Essentials Navigator maps every principle and action by chapter and priority phase, and turns ratings into a board summary. Readers new to the framework can start with the five-minute ASD Essentials explainer, which walks through principles, actions, domains, priority phases and ratings.
Open the ASD Essentials Navigator Start the 5-Minute Explainer Explore ASD Essentials Compliance
See how ThreatDefence automates security monitoring, compliance and cyber risk management in one platform.
CountryAustraliaUnited StatesNew ZealandUnited KingdomCanadaSingaporeOtherI'm an MSP, MSSP, or reseller
Δ
No. As of late 2026, no regulator, government policy or industry program has made ASD Essentials mandatory. The PSPF, DISP, SOCI rules and applicable state policies continue to reference the Essential Eight.
Adoption is voluntary and sits alongside existing requirements. Relevant regulators will determine any future transition timeframes, so adopting the new framework does not automatically satisfy or replace an existing Essential Eight obligation.
ASD published the ASD Essentials series on October 15, 2026. The release followed a consultation paper open from June 15 to July 12, 2026, and more than 30 face-to-face workshops across Australian capital cities.
The release included enterprise IT, OT and cloud chapters. ASD’s Annual Cyber Threat Report 2025-26, published on October 26, 2026, confirmed that engagement on transitional arrangements would continue into 2027.
ASD has announced no retirement date for the Essential Eight. Its FAQ says it will advise on expectations for transitioning to the new framework in due course, and both frameworks remain available and maintained.
will advise on expectations for transitioning to the new framework in due course,
In June 2026, an ACSC official indicated that deprecation would probably begin in approximately 12 months, followed by retirement after approximately 24 months. No published ASD or Home Affairs requirement sets those dates.
The chapter that applies depends on the environments an organisation operates and controls. Enterprise IT generally covers on-premises, hybrid and IaaS environments, while cloud addresses predominantly SaaS and PaaS environments. OT covers systems controlling physical processes and has its own priority phases.
ASD expects most organisations to need both enterprise IT and cloud over time. The starting chapter should reflect operational control, existing obligations, security gaps and the consequences of compromise.
Enterprise IT, in most cases. Organisations operating their own servers, operating systems, applications, identity infrastructure and network architecture on IaaS generally begin with the enterprise IT chapter.
ASD explains that using another party’s infrastructure does not materially change what the organisation must do. The cloud chapter addresses environments where technology is delivered entirely through SaaS and PaaS, where the organisation configures provider-operated services and runs no server or network infrastructure of its own.
E4EIT is ASD’s abbreviation for ASD Essentials for enterprise IT. The abbreviation appears in its machine-readable OSCAL release, labelled E4EIT OSCAL v2026.10.15.
Enterprise IT action identifiers start with IT followed by the relevant principle and action number. Examples include IT.PRO-13.4 for phishing-resistant MFA and IT.DET-01.3 for protected central log storage. The same identifiers appear in the assessment workbook, linking ratings and evidence to the applicable action.
No. ASD states: Priority phases are a sequencing mechanism, not a rating or maturity model.
Enterprise IT 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 throughout. Assessment results are recorded against applicable actions within domains. No maturity level or phase is awarded.
No. ASD describes imperfect visibility as a finding to record rather than a barrier to starting.
a finding to record rather than a barrier to starting
Its implementation planning guide gives an initial tranche covering Boundary services and Identity services, together with Governance and culture and Visibility and response. Existing inventories, architecture diagrams and business impact assessments provide a starting point.
Later technical domains can be scoped when their priority phases begin. Each domain still needs a version-controlled scope statement listing included assets, exclusions and known visibility gaps.
Yes. ASD provides the framework chapters, implementation guides, assessment workbook and OSCAL release free of charge through cyber.gov.au.
The publications use a Creative Commons Attribution 4.0 licence, with exceptions for the Coat of Arms, logos and third-party content.
The framework itself costs nothing to use. An organisation may still incur costs when implementing controls, maintaining security capabilities, collecting evidence or commissioning independent assessments.
No. ASD’s stakeholder kit confirms that the ISM remains ASD’s authoritative source of cyber security principles and controls.
remains ASD’s authoritative source of cyber security principles and controls.
ASD Essentials draws its principles from the ISM and keeps their identifiers, including GOV-01 Executive cyber security accountability. It organises these principles into environment-specific chapters, actions and domains to guide implementation and assessment.
The ISM remains the broader source of principles and controls. ASD Essentials is a structured framework for applying selected security outcomes from it.
ASD Essentials Visibility and Response
"Essential Eight vs ASD Essentials: What Changed and How to Transition"
ASD Essentials Assessment and Checklist