The ASD always said the Essential Eight was not designed for operational technology. OT operators in mining, energy, water and heavy industry have spent years bending an office-IT framework around control systems that cannot be rebooted on a Tuesday afternoon. ASD Essentials for OT, published on 15 October 2026, is the first ASD baseline written for them from the start.
It changes the order of work, drops the idea of ordinary user devices on the plant network, and builds much of its guidance around one question: can you isolate the systems that matter and keep running safely? Here is what is in it, and what it means for WA operators. The wider transition is covered in our Essential Eight to ASD Essentials tracker.
The chapter defines OT as systems that detect or cause a direct change to the physical environment by monitoring or controlling devices, processes and events. Its principles apply to all OT, from simple building automation to large control systems, but its target audience is operators of complex control, automation and safety systems across critical service sectors: public transit, critical supply chain logistics, power generation, transmission and distribution, water and wastewater, medical services and large-scale industry.
Smaller organisations can still use it where relevant. As with the other chapters, the outcomes are the same and what changes is how they are achieved and how much sits with vendors and service providers.
The ASD introduces the term vital OT: the subset of critical systems that cannot acceptably be offline for an extended period if the organisation is to keep providing a safe minimum viable product, taking into account manual workarounds and business continuity plans.
Organisations have to identify and document vital OT and every system and service it depends on, including dependencies outside the OT environment. That last part is where most surprises turn up: licence servers, time sources, historians feeding corporate reporting, or vendor cloud portals that the plant quietly cannot run without.
The OT chapter keeps the eight-domain structure but sequences it for operational safety:
| Priority phase | OT chapter | Enterprise IT chapter, for comparison |
|---|---|---|
| Phase 1 | Boundary services, and Critical processes and services | Boundary services, and Identity services |
| Phase 2 | Privileged environments, and Identity services | Critical processes and services, and Privileged environments |
| Phase 3 | Business systems | Business systems, and User devices |
Governance and culture, and Visibility and response, run across every phase as in the other chapters. In OT, the ASD notes, visibility does double duty for engineering fault analysis.
The bigger change is User devices. The chapter does not map any actions to that domain, because typically configured user endpoints should not be in an OT environment at all. Every device inside the OT system is to be treated as privileged. If engineering laptops that also browse the web and read email are plugging into control networks, this chapter treats that as the problem to fix.
Much of the chapter turns on being able to cut OT off from everything else and keep operating. The actions include:
Isolate vital OT and keep running. Maintain the capability to isolate vital OT and sustain safe operation for a defined period aligned to critical service continuity requirements, and verify the isolation actually works when it is enacted.
No hidden dependencies. The services vital OT depends on must operate independently of systems outside OT, with separate software, credentials, storage, policy and servers. An OT environment that authenticates against the corporate directory fails this test.
Isolation that cannot be undone from outside. Isolation points can only be managed from within vital OT, and the procedures to enact isolation are documented down to physically identifying the cables and equipment involved.
DMZs at the perimeter. Demilitarised zones isolate OT from any network not under the organisation’s sole administrative control.
Practise it. Regular exercises of isolation and sustained isolated operation, including the decision to isolate, threat hunting before reconnecting, safe removal of isolation and moving staff when normal communications are degraded.
Vendor and support remote access is a well-worn route into OT, and the chapter treats it accordingly. Remote access must not route directly into OT; all traffic terminates in the OT DMZ before the next hop. Sessions need explicit establishment controls, including time-bound grants, no permanent connections and disconnection after a period of inactivity. Every remote session is recorded with user, time and target. Local operators are notified of authorised remote maintenance or supplier activity so unexpected changes do not become normal. And there must be an exercised plan to cut remote access fast when malicious activity is spotted.
For many sites, the “always on” vendor connection is the single biggest change this chapter asks for.
The ASD accepts that OT cannot always be patched. The action is to patch within defined, risk-based timeframes and record every asset that cannot or will not be patched, with the reason, then apply compensating protections to those assets and to anything operationally critical that is no longer supported. Critical OT elements that can be updated are expected to meet the same hardening baseline as equivalent critical IT. Legacy systems that remain operationally critical need a managed risk process until they are replaced.
Safety systems get their own actions: segment them from non-safety parts of the OT environment at a network boundary, not by device configuration alone, and protect them against change originating outside the site safety system boundary.
Several actions assume a destructive attack and a supplier who cannot help in time. Organisations must be able to recover any system that cannot acceptably stay offline, to at least a minimum viable level, without supplier support, with a plan to replace key OT devices. Each site keeps copies of playbooks, drawings, installation and configuration instructions, break-glass secrets and emergency contacts in a form that does not depend on the systems being recovered. Alternative communications, a way for staff to raise an OT cyber concern that does not rely on IT systems, and forensic collection within pre-approved areas round it out.
Suppliers are covered too. Providers of services essential to OT must understand the criticality of vital OT and be able to meet agreed prioritised support, and OT installation details must be protected from public disclosure, with third parties held to the same standard.
We support mining, resources and engineering businesses where the line between corporate IT and site systems has blurred over the years: shared domains, shared remote access tools, and site laptops that do everything. Our view is that the OT chapter is mostly an untangling exercise. The controls are not exotic, but proving that vital OT can stand alone usually means separating identity, remote access and support pathways that grew together for convenience.
Most operators will apply the OT chapter to site systems and the enterprise IT chapter to the corporate network, with the boundary between them handled carefully in both. The ASD’s chapter guidance notes OT often carries the larger gap and the higher consequence, which is an argument for starting there.
Name your vital OT. Agree which systems cannot be offline for long, and map every dependency, especially anything outside the OT environment.
Audit remote access paths. List every way a vendor, engineer or support team reaches OT. Anything that bypasses a DMZ, stays permanently connected or is not recorded is a phase 1 fix.
Test whether you could isolate. Work out what would actually happen if you pulled the cable between corporate and OT today, and what would stop working. Talk to us on 1300 EPIC IT if you would like help scoping it.
ASD Essentials for OT is the operational technology chapter of ASD Essentials, the ASD framework that replaces the Essential Eight, published on 15 October 2026. It is aimed at operators of complex control, automation and safety systems in critical service sectors, though its principles apply to all OT.
Vital OT is the ASD’s term for the subset of critical systems that cannot acceptably be offline for an extended period if the organisation is to keep delivering a safe minimum viable product, taking manual processes and business continuity plans into account. ASD Essentials for OT requires organisations to identify vital OT and everything it depends on.
Phase 1 is boundary services and critical processes and services, phase 2 is privileged environments and identity services, and phase 3 is business systems. Governance and culture and Visibility and response run across all phases. The order differs from the enterprise IT chapter to reflect operational safety.
The ASD considers it too risky to have typically configured end-user devices inside OT environments, so every device in the OT system is treated as privileged and no actions are mapped to a separate user devices domain.
No. It requires patching within defined, risk-based timeframes, recording every asset that cannot or will not be patched with the reason, and applying compensating protections to those assets and to unsupported systems that remain operationally critical.
Summarised from ASD Essentials for OT. © Commonwealth of Australia 2026, used under CC BY 4.0. See the ASD’s chapter selection guidance for more.
