Carries over
- Your controls often meet, or count toward, actions.
- Evidence you already hold can be reused while it is current.
- Uplift work in progress is not wasted.
ASD Essentials
Plan and do
Transitioning from the Essential Eight.
Your Essential Eight maturity level does not automatically carry over to the ASD Essentials, but your controls and current evidence do. Expect new work on governance, on visibility and response, and on principles with no direct Essential Eight equivalent. Expect it too on extending controls to each domain an action applies to, and on proof that they keep working.
Keep reporting against the Essential Eight while a regulator, contract or other obligation requires it. This guide explains ASD's transition guide in plain English, with ASD's tables word for word.
Reviewed 17 October 2026 · Current to ASD's Transitioning from the Essential Eight, published 15 October 2026
At a glance
Changes
- Maturity levels do not automatically convert into Essentials ratings.
- Each action is rated in each domain it applies to.
- Priority phases set the order of the domains. They are not maturity levels.
New
- Governance and executive accountability are assessed.
- Asset and risk identification goes wider.
- New principles with no direct Essential Eight equivalent, such as content filtering.
- Logging, detection and response join up in one domain.
Existing investment carries forward, but it is assessed differently (ASD)
Every Essential Eight mitigation strategy maps to at least one principle in the ASD Essentials for enterprise IT. Existing controls will often directly satisfy, or contribute to, one or more actions.
The main differences are:
- the scope that controls need to cover
- the broader security outcomes that some controls now contribute to
- the evidence required to demonstrate that an action is effective.
Previous Essential Eight maturity level ratings do not automatically translate into effectiveness ratings under the ASD Essentials for enterprise IT. The two approaches assess different things.
Organisations should instead use their existing implementation and assessment evidence as the starting point for a gap analysis. Existing evidence can be reused where it remains current and relevant.
ASD has set no date to stop using the Essential Eight. It is talking with regulators and will advise on transition expectations in due course. Our overview explains where it still applies, including under the Australian Government's Protective Security Policy Framework (PSPF).
Starting points by maturity level
ASD gives advice for three starting points, plus a short note for Maturity Level One. Find yours below, in ASD's words.
Organisations at Maturity Level Two
Maturity Level Two was the required baseline for Commonwealth entities and many Australian critical infrastructure operators. Organisations that achieved Maturity Level Two can expect many existing controls to contribute to actions in the early priority phases. Examples include controls relating to phishing-resistant MFA, patching internet-facing services, privileged access, application control and centralised logging of security-relevant events.
However, organisations should not assume that previous achievement of Maturity Level Two means an action will be fully effective in every applicable domain.
Common areas requiring additional work are likely to include:
- extending controls to assets or domains not previously covered
- addressing the Governance and culture principle
- expanding Visibility and response capabilities
- producing evidence that demonstrates sustained effectiveness rather than deployment alone.
PSPF Release 2026 still requires non-corporate Commonwealth entities to reach Maturity Level Two. If that applies to you, keep meeting and reporting it while you transition.
Organisations at Maturity Level Three
Organisations that achieved and sustained Maturity Level Three are likely to be able to reuse a broader range of controls and evidence. This may include controls relating to vulnerability management, application control, privileged access, event logging and analysis, configuration hardening and restoration testing.
However, Maturity Level Three does not automatically produce fully effective ratings under ASD Essentials for enterprise IT.
The rest of ASD's advice: Organisations at Maturity Level Three
The enterprise IT chapter includes actions with no direct Essential Eight equivalent, including requirements relating to credential exposure, supply chain security, domain-based implementation and the Governance and culture and Visibility and response capability domains.
A gap analysis therefore remains necessary.
Organisations undertaking an Essential Eight program
Organisations part-way through an Essential Eight uplift program can begin transitioning without discarding work already completed.
The rest of ASD's advice: Organisations undertaking an Essential Eight program
Existing controls, implementation evidence and assessment results should be mapped to the relevant actions in ASD Essentials for enterprise IT. Where planned Essential Eight work remains relevant, it can be incorporated into the broader implementation strategy.
The priority phases can help organisations focus remaining investment on the domains where ASD recommends effort be directed first.
Organisations should also continue to meet any regulatory, contractual or other obligations that require Essential Eight implementation or reporting.
At Maturity Level One
Organisations previously implementing or assessed at Maturity Level One can use the same transition approach. However, they should expect a greater proportion of actions to require additional implementation.
Considering existing maturity levels (ASD)
Essential Eight maturity level ratings do not automatically convert into ratings under ASD Essentials for enterprise IT.
The Essential Eight maturity model assessed implementation against requirements associated with increasing levels of adversary tradecraft. The Essentials assessment model instead assesses whether individual actions achieve their intended security outcomes for the assets within each applicable domain.
Each action is assessed using a four-tier rating scale:
- not assessed
- not effective
- partially effective
- fully effective.
An action is rated not assessed if it has not yet been assessed against a domain or there is insufficient evidence to determine whether its intended security outcome is being achieved. This is a neutral rating and must remain distinct from not effective.
Previous Essential Eight implementation remains a useful indicator of where an organisation may start because many Essential Eight controls address assets and capabilities that remain important under ASD Essentials for enterprise IT.
Never implemented the Essential Eight? ASD says you can go straight to the enterprise IT chapter and skip the transition guidance.
Key concepts translated
ASD's Table 1 lines up each Essential Eight idea with its Essentials match. Mitigation strategies give way to principles and the actions under them. There are eight domains. Each action applies only in the domains ASD maps it to, and an asset that supports more than one domain counts in each. Priority phases sit where maturity levels did, but they only set the order of the technical domains.
| Essential Eight concept | ASD Essentials concept | What changes in practice |
|---|---|---|
| Mitigation strategies with requirements | Principles supported by actions | Principles describe the security outcome. Actions describe what organisations must do to achieve it. One Essential Eight mitigation strategy may contribute to several principles and actions. |
| Maturity levels | Priority phases | Priority phases sequence the technical domains. They are not maturity or assurance ratings. |
| Whole-of-environment implementation | Eight domains | Actions are applied and assessed in the domains to which they are mapped. Assets that support more than one domain are considered in each relevant domain. |
| Selecting a maturity level based on adversary tradecraft | Threat-informed implementation across the framework | Organisations no longer select a target maturity level. The framework is informed by current adversary tradecraft and cyber threat information, while priority phases provide the recommended implementation sequence. |
| Assessment against specific requirements | Four-tier, outcome-based assessment | Assessments consider whether each action achieves its intended security outcome for the assets in scope. |
| Essential Eight assessment process | Assessment process guide | Actions are assessed using the ratings not assessed, not effective, partially effective and fully effective. Indicators of good practice support consistent assessor judgement. |
Our overview explains how principles, actions and domains fit together.
The eight strategies at a glance
Every Essential Eight strategy maps to at least one principle. The table shows where each lands, its action count and where ASD says controls may need more work.
Strategy names, principle names and strengthening labels are ASD's words. The principle codes, action counts and links are ours. Each code starts with its function: GOV Govern, IDE Identify, PRO Protect, DET Detect and RES Respond.
| Strategy | Mapped principles | Actions | Where ASD flags more work | Table |
|---|---|---|---|---|
| Application control | 3 |
| Table 3 | |
| Patch applications |
| 5(shared with Patch operating systems) |
| Table 4 |
| Patch operating systems |
| 5(shared with Patch applications) |
| Table 4 |
| Multi-factor authentication | 1 | ASD lists five more identity actions to consider, and says to check MFA coverage in each applicable domain. | Table 5 | |
| Restrict administrative privileges | 10 |
| Table 6 | |
| Restrict Microsoft Office macros | 3 |
| Table 7 | |
| User application hardening | Table 8 also maps Content filtering. | 3 |
| Table 8 |
| Regular backups |
| 3 |
| Table 9 |
Event logging, detection and response has no action table. The Essential Eight spread it across several strategies, and ASD maps it to principles only. See how ASD maps it.
Why a control that met the Essential Eight may need more work
ASD gives three reasons:
- Principle breadth. Many strategies feed a wider outcome. Macro controls, for example, cover only part of controlling what software runs.
- Domain scope. One control can rate differently from domain to domain, because its coverage or implementation may not match each domain's risks.
- Evidence. Deployment records show a control exists. You may also need operational evidence that it keeps working.
Why existing controls may need to be strengthened (ASD)
A control that satisfied an Essential Eight requirement may need additional work under ASD Essentials for enterprise IT. This is generally because of differences in principle breadth, domain scope or assessment evidence.
Principle breadth
Many Essential Eight mitigation strategies map to principles that have a broader security outcome.
For example, Restrict Microsoft Office macros contributes to the broader Trustworthy software principle. Existing macro controls therefore remain valuable, but they address only part of the broader requirement to control software execution.
A gap analysis helps identify what is already addressed and what additional work is required. Additional work represents an extension of existing investment rather than its replacement.
Domain scope
The Essential Eight maturity model applied requirements across an organisation’s IT environment. ASD Essentials for enterprise IT groups assets and functions into domains with similar risk characteristics.
The same action may therefore be implemented and assessed differently across domains.
For example, an organisation may have an enterprise-wide control that is fully effective in one domain but only partially effective in another because its coverage or implementation is not proportionate to the risks of that domain.
This means organisations need to consider existing controls in the context of each domain rather than assume an enterprise-wide implementation produces the same outcome everywhere.
Evidence
Existing Essential Eight evidence remains valuable. Configuration records, policies, control settings and deployment records can show how a control has been implemented.
However, an assessment under the Essentials series considers whether an action is achieving its intended security outcome. Assessors consider coverage, consistency, currency and evidence quality when determining an action rating.
Where existing evidence demonstrates deployment but not sustained effectiveness, organisations may need additional operational evidence. Depending on the action and environment, this could include control validation, testing, exercise results, monitoring records or other evidence showing that the control continues to operate as intended.
Strategy-by-strategy action crosswalk
ASD's Tables 3 to 9 take each strategy in turn. Each row names an action, ASD's domain coverage notes and what your Essential Eight work may already contribute. Open a strategy to see ASD's table and notes.
ASD's caveat on the mappings, quoted
The mappings assume that the relevant Essential Eight requirements were implemented and sustained. Organisations should confirm that existing controls and evidence remain current before relying on them. The actions reproduced in this section should match the current wording in ASD Essentials for enterprise IT. The enterprise IT chapter remains the authoritative source for the requirements.
ASD, Transitioning from the Essential Eight
The (ML1), (ML2), (ML3), (partial, ML1) and (partial, ML2) notes appear as ASD prints them. ASD does not define them. The column is also not a full list of where an action applies. In 21 of the 28 rows, it names fewer domains than the enterprise IT chapter, or different ones. Our suggestion: read it as where your Essential Eight work may already count, and take each action's domains from our enterprise IT page.
Application control
Three actions in ASD's table, under two principles.
Will need strengthening:
- Broader software requirements
- Administrative tooling
- Exception management
- Domain coverage
ASD's Table 3 and notes: Application control
| Principle | Action | Domain coverage | Existing E8 contribution |
|---|---|---|---|
| Trustworthy softwarePRO-07 | Permit only supported, verified and organisation-authorised software to execute on systems, with exceptions minimised, formally risk accepted, time-bound, monitored and regularly reviewed. |
| Existing application control rulesets, approved software lists and blocklists can provide strong evidence of software execution controls. |
| Trustworthy softwarePRO-07 | Restrict administrative and management tooling to approved software sets and executed from only authorised, known locations. |
| Existing application control may provide partial coverage. Administrative and management tooling may need to be identified and controlled separately. |
| Secure configuration managementPRO-04 | Detect and respond to configuration drift using scheduled technical assessments and, where supported, automated monitoring, based on system criticality and change rate. |
| Existing ruleset reviews and validation records may contribute evidence, but organisations may need broader mechanisms for identifying configuration drift. |
Where existing investment is recognised, quoted
Key mapped principles: Trustworthy software and Secure configuration management.
Existing investment may include:
- application control on workstations and servers
- approved software lists and block list configurations
- restrictions on executables, scripts, installers, software libraries and other executable content
- documented application control exceptions
- application control logging and monitoring.
These controls remain relevant to the Trustworthy software principle.
Existing application control events forwarded to central logging can also contribute evidence for the Centralised event logging principle.
ASD, Transitioning from the Essential Eight
Where investments will need to be strengthened, quoted
Broader software requirements. Application control is one part of the Trustworthy software outcome. Organisations also need to consider whether software is supported, verified and organisation-authorised.
Administrative tooling. Administrative and management tools must be restricted to approved software sets and authorised locations.
Exception management. Exceptions need to be minimised, formally risk accepted, time-bound, monitored and regularly reviewed.
Domain coverage. Trustworthy software applies across the technical domains. Organisations should confirm that existing controls provide appropriate coverage in each applicable domain.
ASD, Transitioning from the Essential Eight
Patch applications and patch operating systems
Five actions in ASD's table, under two principles.
May need strengthening:
- Asset coverage
- Risk-based treatment
- Domain context
- Legacy systems
ASD's Table 4 and notes: Patch applications and patch operating systems
| Principle | Action | Domain coverage | Existing E8 contribution |
|---|---|---|---|
| Vulnerability managementPRO-06 | Identify known software and configuration weaknesses of assets through continuous and repeatable assessment activities, including vulnerability scanning activities. |
| Existing scanner configurations, scan schedules and results can provide useful evidence. |
| Vulnerability managementPRO-06 | Apply security patches or updates within defined risk-based timeframes or, where operational impact is low, automatically. Chapter wording: Apply security patches or updates within defined risk-based timeframes or automatically where operational impact is low. |
| Patch deployment records and compliance reporting remain relevant. |
| Vulnerability managementPRO-06 | Remediate or mitigate vulnerabilities exceeding defined risk thresholds within defined timeframes based on exploitation, exposure, criticality, impact and compensating controls and verify treatment effectiveness. |
| Existing vulnerability treatment and mitigation records can contribute evidence. |
| Asset identificationIDE-01 | Use an approved asset inventory mechanism that supports automated discovery to detect new and changed physical and non-physical assets. |
| Existing automated discovery capabilities remain relevant. |
| Asset identificationIDE-01 | Continuously identify and document infrastructure, operating systems, applications, identities, credentials and data as distinct assets. Chapter wording: Maintain current records of infrastructure, operating systems, applications, identities, credentials and data assets. |
| Existing operating system and application inventories provide a starting point but may not cover every required asset type. |
Where existing investment is recognised, quoted
Key mapped principles: Vulnerability management, Asset identification and Legacy system management.
Existing investment may include:
- automated asset discovery
- vulnerability scanning
- patch deployment processes
- patch compliance reporting
- processes for responding to vulnerabilities where a patch is unavailable
- processes for removing or replacing unsupported systems.
These capabilities can be reused where they remain current and provide appropriate coverage.
ASD, Transitioning from the Essential Eight
Where investment may need to be strengthened, quoted
Asset coverage. Asset identification includes infrastructure, operating systems, applications, identities, credentials and data as distinct assets. Existing inventories may need to be expanded.
Risk-based treatment. Existing Essential Eight patching arrangements remain relevant, but organisations need to consider the exploitation, exposure, criticality, impact and compensating controls associated with vulnerabilities. Applicable ISM, regulatory and other mandatory timeframes continue to apply.
Domain context. An appropriate treatment timeframe may differ between domains because their assets and risk contexts differ.
Legacy systems. Where legacy systems cannot be removed or replaced immediately, organisations need to identify and manage the associated cyber security risk until decommissioning or replacement.
ASD, Transitioning from the Essential Eight
Multi-factor authentication
One action in ASD's table, under one principle.
ASD's Table 5 and notes: Multi-factor authentication
| Principle | Action | Domain coverage | Existing E8 contribution |
|---|---|---|---|
| Identity, credential and access managementPRO-13 | Use phishing-resistant MFA for users authenticating to systems, including from untrusted, external or high-risk locations. |
| Existing MFA configurations, authentication policies and coverage reporting can provide strong evidence. |
Where existing investment is recognised, quoted
Key mapped principles: Identity, credential and access management.
Existing phishing-resistant MFA controls remain directly relevant. This includes MFA used for privileged users, unprivileged users, organisational online services, third-party services or remote or external access. Logging of successful and unsuccessful authentication events can also contribute evidence for Centralised event logging and the detection of identity and credential misuse.
ASD, Transitioning from the Essential Eight
Where investment may need to be strengthened, quoted
MFA is one part of the broader Identity, credential and access management principle.
Organisations also need to consider actions requiring them to:
- identify and disable or remove default and unused accounts
- store authentication keys, secrets and tokens in approved secure repositories
- regularly scan codebases, configuration files, file shares and collaboration platforms for unsecured keys, secrets and credentials
- disable legacy authentication protocols or, where this is not feasible, restrict and monitor their use, apply compensating controls and establish a time-bound decommissioning plan
- ensure user, machine, system and service account credentials are unique per system or account, particularly in high-privilege contexts.
Existing MFA coverage should also be considered for each applicable domain rather than only for external or remote access.
ASD, Transitioning from the Essential Eight
Restrict administrative privileges
Ten actions in ASD's table, under four principles.
May need strengthening:
- Privileged environments
- Time-bound privilege
- Administrative recording
- Non-person accounts
- Network segmentation
ASD's Table 6 and notes: Restrict administrative privileges
| Principle | Action | Domain coverage | Existing E8 contribution |
|---|---|---|---|
| Secure administrationPRO-05 | Ensure administrative activities can only be executed from dedicated and hardened environments that are isolated from unprivileged user workloads. Chapter wording: Ensure administrative activities can only be performed from dedicated and hardened environments that are isolated from unprivileged user workloads. |
| Existing privileged access workstations, restricted administrative environments and jump servers can provide strong evidence. |
| Secure administrationPRO-05 | Enforce explicit session establishment controls before privileged actions are permitted, including the use of time-bound privilege grants. |
| Existing session controls may contribute, but time-bound privilege is likely to require additional consideration. |
| Secure administrationPRO-05 | Record all administrative or management actions that modify systems, configurations or controls with the details of the user, timestamp and target. Chapter wording: Record all administrative or management actions that modify systems, configurations or controls, including the details of the associated user, timestamp and target. |
| Existing privileged access and account management logging can contribute evidence. |
| Least privilege accessPRO-12 | Periodically review and update access privileges in alignment with current roles, duties and business requirements. |
| Existing privileged access reviews and revalidation processes remain relevant. |
| Least privilege accessPRO-12 | Restrict permissions to create, modify or delete accounts or roles, or to access privileged functions or applications, to authorised administrative roles. Chapter wording: Grant only authorised administrative roles permissions to create, modify or delete accounts and roles, and access privileged functions or applications. |
| Existing privileged access approval processes can contribute. |
| Least privilege accessPRO-12 | Provision user, administrative and non-person accounts with only the minimum access and privileges required to perform defined operational functions. |
| Existing account provisioning and privileged account controls provide a strong starting point. |
| Identity, credential and access managementPRO-13 | Identify and disable or remove default and unused accounts on a regular basis. Chapter wording: Identify and disable or remove default and unused accounts regularly, permitting exceptions only where the account is documented, justified, hardened and monitored. |
| Existing inactivity and account management processes may partially satisfy this requirement. |
| Identity, credential and access managementPRO-13 | Store authentication keys, secrets and tokens in approved secure repositories with access controls, including MFA. |
| Existing management of privileged credentials may contribute. |
| Identity, credential and access managementPRO-13 | Ensure that user, machine, system and service account credentials are unique per system or account, particularly in high-privilege contexts. |
| Existing controls for administrator, service and break-glass credentials may contribute. |
| Network segmentation and segregationPRO-18 | Limit lateral movement between, and within, network segments to explicitly approved pathways and services, based on business requirements and trust levels. |
| Existing separation of privileged environments may provide partial evidence. |
Where existing investment is recognised, quoted
Key mapped principles: Identity, credential and access management, Least privilege access, Secure administration and Network segmentation and segregation.
Existing controls that remain relevant include:
- separate privileged and unprivileged accounts
- privileged access workstations and restricted administrative environments
- restrictions on internet and email access from privileged environments
- privileged access approval and revalidation processes
- management of privileged and service account credentials
- logging of privileged access and account management events.
ASD, Transitioning from the Essential Eight
Where investment may need to be strengthened, quoted
Privileged environments. Organisations need to identify the assets and functions that make up the Privileged environments domain, including relevant management platforms and privileged access services.
Time-bound privilege. ASD Essentials for enterprise IT requires explicit session establishment controls, including time-bound privilege grants. Organisations with standing privileged access should determine whether existing controls achieve this outcome.
Administrative recording. Logging needs to capture administrative or management actions that modify systems, configurations or controls, including the user, timestamp and target.
Non-person accounts. Least privilege requirements apply to non-person and service accounts as well as user accounts.
Network segmentation. Organisations need to limit lateral movement using explicitly approved pathways and services based on business requirements and trust levels.
ASD, Transitioning from the Essential Eight
Restrict Microsoft Office macros
Three actions in ASD's table, under two principles.
May need strengthening:
- Beyond macros
- Configuration baselines
- Configuration drift
ASD's Table 7 and notes: Restrict Microsoft Office macros
| Principle | Action | Domain coverage | Existing E8 contribution |
|---|---|---|---|
| Secure configuration managementPRO-04 | Define approved configuration baselines, informed by vendor and industry hardening guidance, that disable or remove unnecessary services, insecure settings and unsupported or weak communication protocols. |
| Existing macro policies and security configuration settings can contribute directly to user device baselines. |
| Secure configuration managementPRO-04 | Deploy approved configuration baselines on systems, including infrastructure, operating systems and applications. |
| Existing enforced macro settings can provide evidence of baseline deployment. |
| Trustworthy softwarePRO-07 | Permit only supported, verified and organisation-authorised software to execute on systems, with exceptions minimised, formally risk accepted, time-bound, monitored and regularly reviewed. |
| Macro restrictions, trusted publisher arrangements and other execution controls can provide evidence. |
Where existing investment is recognised, quoted
Key mapped principles: Trustworthy software and Secure configuration management.
Existing controls may include:
- disabling macros where there is no demonstrated business requirement
- blocking macros in files originating from the internet
- scanning macros for malicious content
- preventing users from changing macro security settings
- Trusted Location and trusted publisher arrangements.
These controls remain useful for limiting unauthorised code execution and enforcing approved configurations.
ASD, Transitioning from the Essential Eight
Where investment may need to be strengthened, quoted
Beyond macros. Macro controls contribute to broader requirements covering software execution. Organisations should consider equivalent controls for other relevant execution mechanisms.
Configuration baselines. Macro settings should form part of approved configuration baselines that are deployed, maintained and reviewed.
Configuration drift. Organisations need processes for detecting and responding to configuration drift using scheduled technical assessments and, where supported, automated monitoring.
ASD, Transitioning from the Essential Eight
User application hardening
Three actions in ASD's table, under two principles.
May need strengthening:
- Approved and tailored baselines
- Configuration drift
- Coverage
- Beyond user devices
- Broader content filtering
ASD's Table 8 and notes: User application hardening
| Principle | Action | Domain coverage | Existing E8 contribution |
|---|---|---|---|
| Secure configuration managementPRO-04 | Define approved configuration baselines, informed by vendor and industry hardening guidance, that disable or remove unnecessary services, insecure settings and unsupported or weak communication protocols. |
| Existing browser, office productivity and PDF hardening can provide strong evidence for user devices. |
| Secure configuration managementPRO-04 | Deploy approved configuration baselines on systems, including infrastructure, operating systems and applications. |
| Existing enforced security settings can contribute evidence of baseline deployment. |
| Content filteringPRO-09 | Block outbound network connections to known malicious or untrusted destinations. |
Our note: the enterprise IT chapter applies this action in Boundary services and Critical processes and services, not User devices. | Existing browser and application controls may provide partial evidence but do not necessarily address all outbound connections. |
Where existing investment is recognised, quoted
Key mapped principles: Secure configuration management and Content filtering.
Existing hardening controls remain relevant, including controls applied to:
- web browsers
- office productivity suites
- PDF software
- PowerShell and command-line activity
- application security settings.
Associated event logging can also contribute to Centralised event logging and detection activities.
ASD, Transitioning from the Essential Eight
Where investment may need to be strengthened, quoted
Approved and tailored baselines. Organisations should ensure configuration baselines are appropriate to their environment, formally approved and maintained.
Configuration drift. Organisations need to detect and respond to deviations from approved baselines.
Coverage. Configuration baselines should cover the relevant assets within each applicable domain.
Beyond user devices. Secure configuration management applies across the technical domains, not only endpoints.
Broader content filtering. Blocking advertisements or browser-based content may contribute to the Content filtering principle, but organisations need to consider outbound connections across relevant applications and services.
ASD, Transitioning from the Essential Eight
Regular backups
Three actions in ASD's table, under one principle.
May need strengthening:
- Storage protection
- Repository isolation
- Recovery objectives
- Domain scope
ASD's Table 9 and notes: Regular backups
| Principle | Action | Domain coverage | Existing E8 contribution |
|---|---|---|---|
| Regular and proven backupsPRO-10 | Back up important data, applications and settings on a defined schedule to secure, resilient storage protected by encryption and immutable, offline, logically isolated or equivalent controls. |
| Existing backup schedules, retention arrangements and access controls provide a strong starting point. |
| Regular and proven backupsPRO-10 | Isolate backup repositories from general user environments and production workloads, ensuring they are separated from primary systems to prevent unauthorised modification or deletion. Chapter wording: Isolate backup repositories from general user environments and production workloads, ensuring they are separated from primary systems to prevent unauthorised access, modification or deletion. |
| Existing restrictions on backup access may provide partial or direct evidence depending on the architecture. |
| Regular and proven backupsPRO-10 | Conduct regular testing of backup and restoration procedures to ensure that backups are reliable and capable of meeting defined recovery time objectives and recovery point objectives. |
| Current restoration test results and disaster recovery exercises can provide strong evidence. |
Where existing investment is recognised, quoted
Key mapped principles: Regular and proven backups and Least privilege access.
Existing Essential Eight backup arrangements remain highly relevant, including:
- regular backups of important data, applications and settings
- backup retention arrangements
- restrictions on who can access, modify or delete backups
- restoration testing
- disaster recovery exercises.
ASD, Transitioning from the Essential Eight
Where investment may need to be strengthened, quoted
Storage protection. Organisations need secure and resilient backup storage protected through appropriate measures such as encryption and immutable, offline, logically isolated or equivalent controls.
Repository isolation. Backup repositories need to be separated from primary systems, general user environments and production workloads to reduce the likelihood that an adversary can affect both production data and backups.
Recovery objectives. Restoration testing should demonstrate that defined recovery time and recovery point objectives can be achieved.
Domain scope. Organisations should confirm that backup arrangements cover the important data, applications and settings associated with each applicable domain.
ASD, Transitioning from the Essential Eight
Event logging, detection and response
The Essential Eight included event logging, detection and incident response requirements across several mitigation strategies. As such, these requirements contribute to a broader set of principles in ASD Essentials for enterprise IT.
Key mapped principles:
- DET-01 Centralised event logging
- DET-04 Baselined high-risk access activities
- DET-02 Cyber security event detection
- DET-03 Cyber security incident identification
- DET-05 Detection capability efficacy
- RES-05 Cyber security incident coordination
- RES-03 Cyber security incident response
- RES-04 Cyber security incident insights
These capabilities are primarily implemented through the Visibility and response domain.
ASD gives no action table here. Each principle opens on our enterprise IT page.
May need strengthening:
- Visibility and response across all phases
- Log management
- Detection
- Detection efficacy
- Incident response
- Post-incident learning
Event logging, detection and response: Where existing investment is recognised (ASD)
Existing Essential Eight investment may include:
- centralised logging of MFA events
- privileged access and account management logs
- application control logs
- PowerShell and command-line event logging
- protection of event logs from unauthorised access, modification or deletion
- analysis of security-relevant events
- incident escalation and reporting processes
- cyber security incident response plans.
These capabilities provide a strong starting point for the Visibility and response requirements.
Event logging, detection and response: Where investment may need to be strengthened (ASD)
Visibility and response across all phases. Visibility and response is a capability domain that applies across all phases and expands as implementation progresses.
Log management. High-value, security-relevant event logs and configuration changes need to be forwarded to a central logging capability. Event logs also need to support effective correlation across systems and environments.
Detection. Organisations need to consider detection of unauthorised change, anomalous authentication activity, suspicious software execution and other behaviours relevant to the domains in scope.
Detection efficacy. Detection coverage should be reviewed to identify gaps arising from new assets, services, cyber threats or architectural change.
Incident response. Organisations need documented, tested and approved procedures for responding to cyber security incidents.
Post-incident learning. Reviews should identify the security gaps that enabled an incident and consider whether monitoring and response procedures need to change.
What is new compared with the Essential Eight
The enterprise IT chapter goes beyond the Essential Eight in five areas.
Governance and risk management
Now assessed: executive accountability, cyber security resourcing, risk and supplier assurance, AI accountability and legacy systems.
Asset and risk identification
Keep a running record of infrastructure, operating systems, apps, identities, credentials and data. Assess risk against how real attackers work.
Expanded protect principles
Your controls still count, but the outcomes are wider. MFA, for example, now sits inside identity, credential and access management.
New protect principles
Some principles have no direct Essential Eight match, such as content filtering, awareness training and supply chain security.
Visibility and response
Logging, detection and response come together in one domain, which runs in every phase.
ASD's full list
The Essential Eight remains an important foundation for many of the controls required by ASD Essentials for enterprise IT. However, the enterprise IT chapter also introduces security outcomes that were not directly addressed by the Essential Eight.
Governance and risk management
The Governance and culture domain includes principles covering areas such as:
- executive cyber security accountability
- cyber security resourcing
- security risk management assurance
- supplier cyber security assurance
- artificial intelligence accountability
- legacy system management.
Organisations may already have relevant governance arrangements through existing regulatory, risk management or assurance processes. However, these areas were not assessed as part of the Essential Eight maturity model.
Asset and risk identification
Asset identification extends beyond the asset discovery requirements of the Essential Eight.
Organisations need to continuously identify and document infrastructure, operating systems, applications, identities, credentials and data as distinct assets.
The framework also requires threat-informed risk assessment that considers relevant weaknesses, malicious actor techniques and cyber threat behaviours.
Expanded protect principles
Many Essential Eight controls continue to contribute directly to the Protect principles, but the required security outcomes are broader.
For example, the Identity, credential and access management principle includes MFA as well as requirements relating to accounts, credentials, authentication protocols and credential storage.
Similarly, application control and macro restrictions contribute to broader requirements for Trustworthy software and Secure configuration management.
New protect principles
ASD Essentials for enterprise IT also contains principles that do not have a direct Essential Eight equivalent.
Examples include:
- Content filtering
- Cyber security awareness training
- Cyber supply chain security
Visibility and response
The Essential Eight included logging, monitoring and incident response requirements within individual mitigation strategies.
ASD Essentials for enterprise IT brings these capabilities together through the Visibility and response domain and dedicated principles covering event logging, detection, incident identification, detection efficacy, incident coordination, incident response and post-incident insights.
The Visibility and response domain applies across all phases and expands as additional technical domains are implemented.
Reusing existing evidence
Reuse your Essential Eight evidence where it is current and reliable and shows the right coverage and consistency. You do not need to collect it again just because it was gathered for another framework.
What you may already hold
- assessment reports
- configuration extracts
- ruleset exports
- control test results
- logging architecture documentation
- exception registers
- risk registers
- remediation plans
What shows a control keeps working
- validation results
- monitoring records
- configuration drift reports
- review records
- restoration tests
- exercises
- detection engineering artefacts
Both lists are ASD's.
Review old decisions before you rely on them. An expired exception, a weakened compensating control or a risk acceptance based on old threats needs a fresh look. Our assessment guide explains what makes evidence strong.
Reusing existing assessment evidence (ASD)
Organisations that have been assessed against the Essential Eight may already hold substantial evidence, including assessment reports, configuration extracts, ruleset exports, control test results, logging architecture documentation, exception registers, risk registers and remediation plans.
This evidence should be reused where it remains current and relevant.
Evidence that shows what has been deployed remains useful. It can demonstrate where and to what extent a control is implemented.
However, deployment alone does not demonstrate effectiveness.
Evidence showing how a control operates over time can provide stronger support for an action rating. This may include:
- validation results
- monitoring records
- configuration drift reports
- review records
- restoration tests
- exercises
- detection engineering artefacts.
The Assessment process guide explains how existing evidence can be reused and when additional evidence may be required. If existing evidence is current and reliable and demonstrates appropriate coverage and consistency, organisations do not need to generate new evidence simply because it was originally collected for another framework or assessment.
Existing exceptions, compensating controls and accepted risks should also be reviewed. An expired exception, degraded compensating control or risk acceptance based on an outdated threat environment should not be relied on without review.
ASD's six-step pathway
The transition should follow the implementation approach described in the Implementation planning guide, while making use of existing Essential Eight investment.
ASD recommends the following sequence.
Step 1: Establish the transition baseline
Record where you stand: your last assessment, controls, registers, fix plans and planned uplift. Map it to the Essentials before deciding whether it should continue unchanged. Do not start work only to reach an old Essential Eight target, unless an obligation still requires it or it still addresses significant cyber security risk.
Our suggestion
Record each planned task against the action it serves, in the mapping sheet described under running both.
ASD's wording for step 1
Record the organisation’s current Essential Eight position, including:
- the most recent assessment results
- existing controls
- exception and risk registers
- remediation plans
- committed or planned uplift activities.
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.
Map existing and planned work to ASD Essentials for enterprise IT before deciding whether it should continue unchanged.
Step 2: Scope the priority phase 1 domains
List the assets and functions in your first four domains:
- Governance and cultureAll phases
- Visibility and responseAll phases
- Boundary servicesPhase 1
- Identity servicesPhase 1
Reuse the asset lists and architecture documents you have. Put an asset in every domain it supports.
Our suggestion
Agree the list in a scoping workshop with the people who run the systems.
ASD's wording for step 2
Identify the assets and functions within:
- Governance and culture
- Visibility and response
- Boundary services
- Identity services.
Reuse existing asset inventories, architecture documentation, business impact assessments and other relevant information.
Where an asset supports more than one domain, include it in each relevant domain.
Step 3: Conduct a gap analysis
For each principle that applies, check its actions against the controls you have. Sort each action, in each domain, as already effectively addressed, partially addressed or not addressed (ASD's planning guide calls the first one addressed). A gap analysis gives findings, not ratings.
Our suggestion
Start with each action's indicators of good practice for the not effective rating. They show your clearest gaps. See how to run a gap analysis.
ASD's wording for step 3
For each applicable principle, review the associated actions against existing controls.
Classify each action as:
- already effectively addressed
- partially addressed
- not addressed.
These are gap analysis findings, not formal assessment ratings.
Document how existing controls address each action and identify what remains to be delivered.
This terminology is consistent with the Implementation planning guide, which deliberately separates initial gap analysis from the formal action ratings used during assessment.
Step 4: Plan implementation
Turn the gaps into a plan. If a gap affects only one domain, you can plan its fix there. Where several domains need the same thing, you can build it once and roll it out in priority phase order.
Our suggestion
Start with actions that apply across several domains. ASD's planning guide calls these the best candidates for reusable patterns, including MFA, configuration baselines and drift detection, central logging, vulnerability management and backups. See designing patterns.
ASD's wording for step 4
Use the identified gaps to develop an implementation strategy.
Where a gap is specific to one domain, organisations can use a domain-focused implementation approach.
Where the same requirement applies across several domains, organisations can design the capability once and progressively apply it in priority phase order.
Step 5: Deliver and measure
Prepare for assessment as each control lands. Check each action in each domain for coverage, consistency, currency and evidence quality. If an action is rated partially effective, record the gaps and set dated fixes.
Our suggestion
Add to each domain's evidence register as controls land, so proof builds up from normal work. See what counts as evidence.
ASD's wording for step 5
Implement remediation and prepare for assessment as controls are delivered.
For each applicable action and domain, consider:
- coverage
- consistency
- currency
- evidence quality.
Where an action is rated partially effective during an assessment, document the specific gaps and establish remediation with defined actions and timeframes.
Step 6: Progress through the priority phases
Move on to priority phase 2, then phase 3. Keep growing the two capability domains as you go. Reassess on a regular cycle to confirm controls still work.
Results are reported by priority phase and domain. ASD says not assessed must stay distinct from not effective.
Our suggestion
Use each domain score to show progress phase by phase. See how domain scores work.
ASD's wording for step 6
After addressing the priority phase 1 technical domains, progress through:
- priority phase 2: Critical processes and services, and Privileged environments
- priority phase 3: Business systems and User devices.
- Governance and culture, and Visibility and response, continue across all phases and expand as implementation progresses.
Establish an appropriate reassessment cadence to confirm that controls continue to achieve their intended outcomes.
While you transition, report progress as ASD's assessment process describes.
ASD, reporting during transition, quoted
During transition, organisations should use the reporting approach defined in the Assessment process guide.
Domains or actions that have not yet been assessed should be reported as not assessed.
The not assessed rating should not be used to imply that an action is ineffective. It records that the action has not yet been assessed, or that there is insufficient evidence to determine its effectiveness.
Organisations with regulatory or other reporting obligations that continue to require Essential Eight terminology should continue to meet those obligations as directed by the relevant authority.
ASD, Transitioning from the Essential Eight
Common transition pitfalls
ASD lists seven pitfalls. Check your plan against each one.
Treating priority phases as maturity levels. Priority phases sequence implementation across domains. They are not maturity, compliance or assurance ratings.
Claiming equivalence instead of assessing. A control that previously satisfied an Essential Eight requirement provides evidence. It does not automatically produce a rating under ASD Essentials for enterprise IT.
Assessing the enterprise instead of the domain. Actions are assessed in the context of each applicable domain. Enterprise-wide implementation does not mean an action will receive the same rating in every domain.
Ignoring the capability domains. Governance and culture, and Visibility and response, apply across all phases and expand as implementation progresses. They should not be deferred until the technical domains are complete.
Attempting to transition every domain at once. Spreading implementation, evidence collection and stakeholder effort across the whole environment can dilute progress. Use the priority phases to focus effort while continuing to mature the two capability domains.
Reusing stale evidence. Existing evidence remains useful only where it continues to represent the current environment and operation of the control.
Overlooking new requirements. Some actions have no direct Essential Eight equivalent and require additional planning and resourcing.
Our suggestion: run both frameworks side by side
Two things to add to ASD's pathway.
Keep the Essential Eight running
ASD says to keep meeting any obligation that requires Essential Eight work or reporting. For example, the PSPF still requires non-corporate Commonwealth entities to reach Maturity Level Two.
Our suggestion: use one set of controls and produce two reports. One is the Essential Eight report you owe now, and the other is Essentials ratings by domain.
Build one mapping sheet
Give it one row per action, keyed by ASD's identifier (such as IT.PRO-13.4), and one column per domain. Note the Essential Eight control or evidence behind each cell.
Cover all 58 actions, not only the 25 in ASD's tables. The tables miss some mapped work: Table 2 maps both patching strategies to Legacy system management, which has no rows in Table 4.
ASD says the transition should follow its implementation approach. Steps 2 to 6 match five of its seven stages. The other two still apply: get executive commitment before you start, and plan to keep controls working as part of the program, not after it. See ASD's seven implementation stages. Every action, with its domains and indicators, is on our ASD Essentials for enterprise IT page.
Frequently asked questions
Short answers to common questions about moving from the Essential Eight.
Does our Essential Eight maturity level carry over to the Essentials?
No, the ratings do not automatically convert, even from Maturity Level Three. Your controls and current evidence carry over instead, as the starting point for a gap analysis.
Should we pause our Essential Eight uplift program?
No. Keep current uplift going while you check how it lines up with the Essentials. Do not start new work only for a superseded target, unless an obligation still requires it or it still addresses significant cyber security risk.
Do we keep reporting against the Essential Eight?
Yes, wherever a regulator, contract or other obligation requires it. PSPF Release 2026 still requires Maturity Level Two for non-corporate Commonwealth entities. ASD has set no end date for the Essential Eight and will advise on transition expectations in due course.
Are priority phases the new maturity levels?
No. They set the order in which you work on the domains. They are not a maturity, compliance or assurance rating.
What do notes such as (ML1), (ML3) and (partial, ML2) mean in the domain coverage column?
ASD does not say, so we show them exactly as printed. The column often lists fewer domains than an action applies to, so take its domains from the enterprise IT chapter.
Sources
The publications this page explains or draws on.
Quoted ASD material © Commonwealth of Australia 2026, licensed under CC BY 4.0.
Everything else on this page is written by Control Stack.