Does my Essential Eight maturity level carry over to ASD Essentials?

Not automatically. ASD Essentials replaces maturity levels with effectiveness ratings for each action in each domain, so existing controls need to be assessed again against the new actions. Any obligation that names an Essential Eight maturity level still applies until the authority that set it says otherwise.

ASD Essentials and AI: Essential Eight Replacement, Mapped to the ISM AI Controls

Q: Is the Essential Eight being replaced?

Yes. ASD published ASD Essentials in October 2026 as the Essential Eight's successor and expects to retire the Essential Eight within about two years. It stays published and supported during the transition, and work done against it maps across.

Q: Does ASD Essentials have AI controls?

Not separate ones. ASD Essentials is technology-agnostic and treats AI as an asset, a threat and a defensive capability within its existing principles. ASD's AI considerations publication explains how each principle applies to AI. The specific AI controls are in the Information Security Manual.

What is changing

The Australian Signals Directorate (ASD) published ASD Essentials in October 2026 as the successor to the Essential Eight. It drops the eight prescriptive mitigation strategies and three maturity levels for a model built on principles (the security outcome), actions (what to do) and domains (where it applies), with separate chapters for enterprise IT, cloud and operational technology (OT).

	Essential Eight	ASD Essentials
Structure	Eight mitigation strategies	Principles, actions and domains
Measured by	Maturity levels one to three	Effectiveness of each action in each domain: not, partially or fully effective
Scope	Mainly Windows-based enterprise networks	Chapters for enterprise IT, cloud and OT, with guidance on AI and for senior executives
Order of work	Climb the maturity ladder	Priority phases, starting with the systems at the boundary and the ones that decide who to trust

Timing. ASD expects to retire the Essential Eight within about two years. It stays published and supported during the transition, and existing controls map across, so the work is not wasted. ASD has not set a hard switchover date, and any contract, policy or regulation that names an Essential Eight maturity level still applies until whoever set it says otherwise.

Where AI fits. ASD Essentials has no separate AI chapter. It is technology-agnostic, and ASD's companion publication, AI considerations within the Essentials, explains how each principle applies to AI. The specific AI controls live in the Information Security Manual (ISM). This guide puts the two side by side.

AI as a threat, a solution and an asset

ASD asks organisations to look at AI three ways, in every environment, whether they consume, develop or deploy it.

A threatAI has not changed how attackers get in and move around, but it has made existing attacks faster, cheaper and available to more people. Synthetic voice and video can impersonate the people who approve payments or access. AI systems are targets too: indirect prompt injection through emails, documents and web pages, tampered models from public sources, and sensitive data sent to unapproved AI services.

A solutionAI can help defenders correlate events, triage alerts, find vulnerabilities and synthesise threat intelligence. ASD's caveats: AI security products are AI assets that need governing themselves, they support the Essentials actions rather than replace them, and people stay accountable for decisions made on their output.

An assetAI systems are in scope like any other asset: models you build or fine-tune, hosting and training infrastructure, external AI services, AI-enabled platforms, training data, prompts and outputs, APIs and connectors, and the accounts and non-person identities that agents use.

ASD's answer to the threat side is layered protection: an attacker who defeats one safeguard should run into another. Its view of prompt injection is blunt. It cannot be completely prevented, so systems must be designed so that a manipulated model cannot exceed the access it was given.

Frontier models raise the tempo

ASD's blog Frontier models and their impact on cyber security (last reviewed September 2026) makes the threat concrete: each new generation of frontier model gets better at reading and reasoning about code, so finding and exploiting vulnerabilities is becoming cheaper and faster for attackers and defenders alike. ASD's advice is the Essentials fundamentals, applied harder:

Reduce attack paths and surfaces. Question every internet-facing system, segment what must stay exposed, and buy from suppliers who show how they use AI to find and fix their own vulnerabilities.
Patch every day. Expect more frequent patches, apply them quickly, including low-severity ones that attackers can chain together, and retire unsupported software.
Use AI to find your own vulnerabilities before release, as part of secure-by-design development.
Layer your defences, so no single control is the only thing between an AI-assisted attacker and your systems.

Executive AI accountability

The one AI-specific governance requirement ASD points to comes from the ISM's Executive artificial intelligence accountability principle GOV-08: the board of directors or executive committee is accountable for ensuring AI is secure, controllable, human-supervised and used ethically and accountably.

In practice that means approval, risk assessment, oversight and periodic review of AI use cases, owned at executive level, so the technical controls below operate inside a governance framework that treats AI as its own area of risk. In cloud, ASD adds that switching on AI features in SaaS or platform services needs executive or delegate approval, and high-risk services holding sensitive data fall under the cloud chapter's executive approval arrangements.

If you already run an AI management system under ISO 42001, this is where it plugs in: the impact assessments and governance it produces are the evidence a board needs here.

Where AI sits in the domains

Domains decide which principles and actions apply to a system. ASD's guidance is to scope an AI asset by its function, connectivity, criticality, access and the consequence of its compromise: what it reaches, who can use it and what losing it would cost.

Domain	Enterprise IT	Cloud	OT
Critical processes and services	AI supporting core organisational outcomes	AI supporting core organisational outcomes	Models and decision support that provide input to control
Business systems	AI embedded in general enterprise platforms	AI embedded in general-purpose SaaS
Boundary services	Public-facing AI services and APIs	AI APIs, connectors and integrations
Identity services	AI agents and their non-person identities	AI agents and their non-person identities
Privileged environments	AI tools that can take administrative actions	AI with access to SaaS administration or cloud control planes	AI tools on engineering and operator workstations

An organisation that hosts or trains its own models on its own infrastructure should check whether the enterprise IT chapter, rather than cloud, better reflects what it is responsible for.

Enterprise IT: principle by principle

Most enterprise IT principles apply to AI the way they apply to anything else; what changes is how you implement them. The middle column summarises ASD's AI considerations for each principle. The right column is our mapping to the ISM AI controls that implement it.

Principle	What it means for AI	ISM AI controls
Asset identification	Include AI systems, models, training data, model artefacts and inference endpoints.	ISM-2134 ISM-2135 ISM-2084
Vulnerability management	Cover prompt injection, adversarial inputs, model extraction and compromised weights or training data, as well as ordinary vulnerabilities.	ISM-1924 ISM-2158 ISM-2085 ISM-2086
Secure system lifecycle	Make sure a manipulated model cannot exceed the access it was granted, because prompt injection cannot be fully prevented.	ISM-2156 ISM-2157 ISM-2113 ISM-2158
Cyber supply chain security	Verify the integrity and provenance of model weights, training data and other AI components before use, and approve AI tools and integrations before they reach organisational data.	ISM-2086 ISM-2087 ISM-2088 ISM-2072
Supplier cyber security assurance	Establish where AI providers keep prompts and outputs, and whether your data trains their models.	ISM-2103 ISM-2123
Secure configuration management	Cover model access controls, inference endpoints, connected data sources, interaction limits and safety settings.	ISM-2092 ISM-2090 ISM-2091 ISM-2112
Trustworthy software	Address unapproved AI tools, browser extensions, locally run models and agents, including agents that can execute code.	ISM-2074 ISM-2072
Identity, credential and access management	Apply to machine identities too, including the service principals and managed identities AI platforms use.	ISM-2133 ISM-2135
Least privilege access	Limit agents and integrations to the minimum data and permissions they need, and deal with overshared data an AI assistant would otherwise surface.	ISM-2156 ISM-2157 ISM-2092 ISM-2093
Secure administration	AI tools that can take administrative actions operate through privileged environments, and their actions are recorded.	ISM-2113 ISM-2159
Centralised event logging	Capture relevant prompts, outputs, retrieval activity and administrative actions, allowing for how sensitive and voluminous AI interaction data is.	ISM-2159
Baselined high-risk access activities	Learn the normal behaviour of agents and their identities so anomalies stand out.	ISM-2114 ISM-2089
Content filtering	Filter content AI systems consume as well as what they generate.	ISM-2094 ISM-1924 ISM-2158
Regular and proven backups	Back up the models, configurations and retrieval data stores needed to restore AI-enabled services.	No AI-specific control; the ISM's general backup controls apply.
Cyber security awareness training	Cover approved AI use, handling organisational data, AI-enabled social engineering, out-of-band checks of unexpected requests and the limits of AI output.	ISM-2074

Cloud: what changes for AI

In cloud, responsibility is split with the provider, so ASD adds one requirement of its own: record AI capabilities in your shared responsibility register, showing which AI controls you operate, which ones the provider gives you to configure, and which outcomes the provider delivers that you verify through assurance. The principles that differ from enterprise IT:

Principle	What it means for AI in cloud	ISM AI controls
Asset identification	Include AI services, agents and connectors, and bring unsanctioned AI applications under governance.	ISM-2134 ISM-2074
Supplier cyber security assurance	As for enterprise IT, plus the regions in which AI processing happens.	ISM-2103 ISM-2123
Cyber supply chain security	Assess and approve AI applications, connectors and consent grants before they reach organisational data.	ISM-2134 ISM-2092
Identity, credential and access management	Give each agent an owned non-person identity, constrained to its intended context.	ISM-2133 ISM-2135 ISM-2157
Secure administration	Treat agents and automation with access to SaaS administration or cloud control planes as privileged, and record their actions.	ISM-2113 ISM-2159
Secure configuration management	Put tenant-level AI settings, such as web grounding, plugins, connectors and data access scopes, in approved configuration baselines.	ISM-2112 ISM-2092
Vulnerability management	Cover weaknesses in AI applications and integrations built on platform services, including susceptibility to prompt injection.	ISM-1924 ISM-2158
Cryptographic protection	Keep customer control of the keys protecting the most sensitive data AI services process or store, where the service supports it.	No AI-specific control; the ISM's cryptography guidelines apply.
Content filtering	Stop sensitive data flowing to unsanctioned AI services, and inspect content AI systems retrieve for malicious instructions.	ISM-2094 ISM-2158
Centralised event logging	Capture prompts, outputs and agent actions, and make sure the provider's logging is switched on and retained.	ISM-2159

OT: what changes for AI

In OT, a security decision can affect safety and physical processes. AI helps attackers understand industrial protocols and control logic faster, which makes exposed OT information more valuable, and OT systems often cannot be patched quickly. ASD's two overriding points: AI-enabled monitoring must not create pathways or dependencies that weaken OT isolation, and nothing an AI recommends or does may compromise a safety function.

Principle	What it means for AI in OT	ISM AI controls
Asset identification and business criticality	Include models, training data and AI embedded in OT products or vendor clouds, and record where vital OT depends on AI, including AI outside the OT environment.	ISM-2134 ISM-2084
Cyber supply chain and supplier assurance	Verify models and model updates before they enter OT, and find out whether suppliers train on your OT telemetry and where it is held.	ISM-2086 ISM-2103
System exposure minimisation	Keep OT configurations and drawings out of AI services you do not control, and require third parties to do the same.	ISM-2074 ISM-2094
Secure configuration management	Constrain the outputs of models that feed control systems to safe operating limits and detect unauthorised changes. Safety systems enforce those limits independently.	ISM-2113 ISM-2114 ISM-2086
Segmentation, isolation and remote access	No AI platform has a path that can change safety systems. Vital OT does not depend on AI outside the OT environment. AI vendor services connect through the OT demilitarised zone, never directly.	No AI-specific control; the ISM's network and OT guidance applies.
Backups and recovery	Hold the models, configurations and data needed to rebuild AI-enabled OT functions per site, and be able to recover them without the supplier.	No AI-specific control.
Continuous improvement	Run isolation exercises proving AI-dependent functions fail safely and operators can run without them.	No AI-specific control.
Centralised event logging	Capture AI recommendations, automated actions and operator overrides, and keep logging available during isolation.	ISM-2159
Awareness training	Cover the risk of sharing OT information with AI tools, and when operators should override AI recommendations.	ISM-2074

The ISM AI controls, explained

The September 2026 ISM has around 30 controls aimed at AI. Here they are in plain language, grouped by what they protect. The grouping is ours, not ASD's; the control numbers are the ISM's. Check the wording against the current ISM before you rely on it.

Governance and policy

GOV-08 Executive AI accountability: The board or executive committee is accountable for AI being secure, controllable, human-supervised and used ethically.
ISM-2074 AI usage policy: A general-purpose AI usage policy is developed, implemented and maintained: which tools are approved and what data may go into them.

Agent identity and inventory

ISM-2133 Unique agent identities: Each AI agent has its own identity, separate from staff accounts and from every other agent. No agents running under a developer's account or a shared service account.
ISM-2134 AI agent register: A register of AI agents is kept, maintained and regularly verified.
ISM-2135 What the register records: For each agent: its identifier, owner and business purpose, assigned identities, the accounts and credentials it uses, and the tools, permissions and data it can reach.

Agent authorisation and human oversight

ISM-2113 Human approval for high-impact actions: AI applications require a person's approval before sensitive or high-impact actions.
ISM-2092 Fine-grained permissions: Access control policies enforce fine-grained permissions for AI applications, rather than all-or-nothing grants.
ISM-2093 Role-based access to sensitive data: Role-based access controls stop AI applications surfacing sensitive data to people who could not open it directly.
ISM-2156 Least privilege for agents: Agents get only the tools, functions and permissions their purpose needs.
ISM-2157 User and agent authorisation together: A tool an agent calls is checked against both the invoking user's access and the agent's task-scoped authorisation, and only what both allow goes through. This stops an agent becoming a way to escalate privilege.

Input and output protection

ISM-1924 Prompt attack detection: Generative AI applications evaluate prompts to detect and mitigate adversarial inputs designed to cause unintended behaviour or harmful output.
ISM-2158 External content stays untrusted: Anything an agent retrieves (web pages, emails, files, tool responses) is treated as untrusted throughout, kept apart from system instructions, validated, and can never change instructions, policies, access controls, tool permissions or approval requirements. This is the indirect prompt injection control.
ISM-2094 Output content filtering: AI applications filter output to detect and block sensitive data exposure and improper content.
ISM-2085 No exact confidence scores: Exact model confidence scores are not exposed in APIs or interfaces, because they help attackers extract or probe a model.

Data handling and privacy

ISM-2112 No direct external access on classified systems: AI applications that process classified data cannot directly access external public data sources, such as web search.
ISM-2103 No training on your data without consent: Organisational data processed by AI applications is not used to train, fine-tune or improve models unless the data owner has given informed, explicit consent in advance.
ISM-2123 Deleting a chat deletes it: When a chat session is removed, all its prompts and outputs are securely deleted.

Model and data supply chain

ISM-2084 Model and system cards: Model cards and system cards, or equivalents, document each AI system's model, architecture, use cases and security risks.
ISM-2072 Safe model file formats: Models are stored in a non-executable format that cannot run arbitrary code when loaded.
ISM-2086 Model provenance and integrity: The source and integrity of models, their structures and weights are verified.
ISM-2087 Training data provenance: The source and integrity of training data are verified.
ISM-2088 Training data validation: Training data is validated for reliability and accuracy, which is also how planted or poisoned samples get caught.

Runtime resilience and monitoring

ISM-2114 Behaviour baselines: Baselines of expected behaviour and performance are set for AI applications and monitored for unexpected deviations.
ISM-2089 Performance monitoring: Model performance metrics are monitored and anomalies investigated.
ISM-2090 Rate limiting: Inference queries are rate limited.
ISM-2091 Resource limits: Resource limits are enforced for AI models, so one crafted request or runaway agent loop cannot exhaust them.
ISM-2159 Agent activity logging: Every tool call, external request and output from agentic AI is centrally logged in enough detail to investigate an incident.

AI in security operations

ISM-2117 AI-assisted detection: Suitable AI models help detect cyber security events and identify incidents.
ISM-2119 AI-assisted testing: Suitable AI models augment vulnerability assessments and penetration tests.
ISM-2122 AI-assisted software security testing: Suitable AI models augment software security testing.

These last three are ASD's "AI as a solution" in control form. ASD's caveat applies: the AI tools are themselves assets to govern, and people stay accountable for the decisions.

Where to start

ASD Essentials sets its own order of work in each chapter's priority phases, starting with the systems at the boundary and the ones that decide who to trust. For AI, that points to four things most organisations can begin this quarter:

Find your agents. Build the AI agent register (ISM-2134, ISM-2135) and give each agent its own identity (ISM-2133). Agents are identity services in ASD's domain model, and you cannot scope least privilege for agents you do not know exist.
Cap what a manipulated agent can do. Least privilege, combined user and agent authorisation, and human approval for high-impact actions (ISM-2156, ISM-2157, ISM-2113). ASD's own assumption is that prompt injection will sometimes succeed.
Settle the data questions with suppliers. Where prompts and outputs are kept, whether they train models, and in which region processing happens (ISM-2103, ISM-2123). Record the answers in the shared responsibility register for cloud services.
Log agent activity centrally. Tool calls, external requests and outputs, tied to the agent and the user it acted for (ISM-2159), then baseline it (ISM-2114).

Above all four sits the governance piece: executive accountability for AI (GOV-08) and a usage policy staff have actually read (ISM-2074). For setting that up, see our cyber security governance framework.

Get a transition assessment

Want to know where you stand against ASD Essentials, including your AI systems, before the Essential Eight retires? Tell us a little about your organisation. We reply within two business days, and we can introduce you to an independent assessor who does ASD Essentials and ISM gap assessments.

Your name

Work email

Organisation

Size

What needs assessing?

Enterprise IT Cloud OT AI systems

When

Anything else? (optional)

CISO AI may receive a fee from providers we introduce you to. Your details are used only for this enquiry; see our privacy policy.

Questions

Is the Essential Eight being replaced?

Yes. ASD published ASD Essentials in October 2026 as its successor and expects to retire the Essential Eight within about two years. It stays published and supported during the transition, and work done against it maps across.

Does my Essential Eight maturity level carry over?

Not automatically. Maturity levels are replaced by effectiveness ratings for each action in each domain, so existing controls need assessing again against the new actions. Any obligation that names an Essential Eight maturity level still applies until the authority that set it says otherwise.

Does ASD Essentials have AI controls?

Not separate ones. It treats AI as an asset, a threat and a defensive capability within its existing principles, and ASD's AI considerations publication explains how each principle applies. The specific AI controls are in the ISM, mapped above.

What is the difference between ASD Essentials and the ISM?

ASD Essentials sets out the security outcomes and priority actions most organisations should achieve. The ISM is the detailed control catalogue that government agencies apply and many others use as a reference. Our mapping shows which ISM AI controls deliver which Essentials outcome.

We are APRA-regulated. Does this change CPS 234?

No. CPS 234 sets its own, principles-based information security obligations and does not name any ASD framework. Many regulated entities use ASD guidance as evidence of good practice under CPS 234, so the transition is still worth tracking. See our APRA CPS 220, 230 and 234 guide.

ASD Essentials and AI