ASD Essentials for OT

Who it is for. ASD published the OT chapter on 15 October 2026, alongside the enterprise IT and cloud chapters. It is written for operators who run complex control, automation and safety systems in critical service sectors: public transit, supply chain logistics, power generation and networks, water and wastewater, medical services and large-scale industry. ASD says smaller organisations with simpler automation can still use it; the security outcomes are the same, but how they are reached, and how much falls to vendors and service providers, will differ.

Key terms

Operational technology (OT) is ASD's term for systems that detect or cause a direct change in the physical world by monitoring or controlling devices, processes and events. That covers process automation, instrumentation, cyber-physical operations and industrial control systems (ICS).

Vital OT is the subset of critical systems that cannot acceptably be offline for an extended period if the organisation is to keep delivering a minimum viable service safely. Deciding what counts takes into account whether the process can run manually and what the business continuity plan already covers. Many of the chapter's actions apply specifically to vital OT and the services it depends on, including those that sit outside the OT network.

How the domains change for OT

The chapter keeps the standard structure: principles (the outcome), actions (what to do) and domains (where it applies), with each principle traced to an ISM identifier such as GOV-01. Technical actions are also mapped to MITRE ATT&CK techniques, including ICS techniques such as loss of safety, loss of view and manipulation of control.

The big difference is user devices. ASD says ordinary end-user laptops and desktops should not be used inside OT at all, because of the risk of carrying threats straight into a privileged environment. Every device inside the OT system is treated as privileged, so the user devices domain drops out of the technical mapping and the chapter works across five technical domains: critical processes and services, boundary services, identity services, privileged environments and business systems. Governance and culture, and visibility and response, apply across all of them.

Non-production environments are in scope. Development, test and staging systems go into domains like any other asset, and any that hold production trust, admin access or the ability to deploy to production should be protected to production level.

Priority phases are ordered for safety

Phase 1 is boundary services and critical processes and services: the pathways into OT from less trusted networks, and the systems whose failure has the biggest safety, environmental or service consequences. Phase 2 is privileged environments and identity services, to stop an initial foothold turning into control. Phase 3 is business systems. This differs from the enterprise IT and cloud chapters, which start with identity. As in every chapter, ASD says a phase is a sequence, not a maturity level, rating or compliance claim.

Actions that stand out

Isolation as a designed capability. Build and keep demilitarised zones between OT and every network the organisation does not solely control. Document how isolation is enacted, down to clearly labelled cables and equipment, make sure isolation points can only be operated from inside vital OT so no one can undo them remotely, and be able to run vital OT safely in isolation for a defined period. Services that vital OT relies on, such as identity, storage and logging, should keep working with no dependency on systems outside OT.

Exercise it. Regularly practise isolating and running isolated, including the decision to isolate, threat hunting before reconnecting, safe reconnection, capturing artefacts and moving staff between sites with degraded communications. Test which third-party dependencies break under isolation, such as licence checks, activation servers, updates and licences tied to hardware IDs.

Remote access. Never route it straight into OT: terminate it in the OT DMZ. Require explicit, time-bound session grants with no permanent connections and inactivity timeouts, use phishing-resistant MFA for anyone crossing the perimeter, record every session (who, when, which target), tell local operators when a supplier is working remotely, and have a tested plan to cut all remote access fast.

Credentials and administration. Change default, supplier and simple passwords before a device is commissioned or replaced, and protect devices that cannot take unique credentials with compensating controls. Give each admin and engineering function its own role and unique account, and only allow engineering and troubleshooting from dedicated, hardened workstations in a segment of equal or higher trust. Check that break-glass accounts work, and that their secrets are on hand, for when outside authentication is cut off.

Patching realistically. Patch within risk-based timeframes, and keep a register of every asset that cannot or will not be patched, recording the reason, the compensating protections, the residual risk accepted and who accepted it. Review it on a schedule and whenever the asset's exposure changes.

Recover without the vendor. Back up firmware, configuration, licence, calibration, project and logic files and supplier images per site, offline, restorable to a common point in time. Be able to recover any system that cannot stay offline to a minimum service level without supplier help, and have a plan to replace key devices after a destructive attack. Keep per-site copies of playbooks, drawings, reset instructions, break-glass secrets and emergency contacts that do not rely on the systems being recovered.

Safety systems and visibility. Segment safety systems from the rest of OT at a network boundary, not just by device setting. Capture traffic on both sides of every OT DMZ boundary and between OT segments, and alert when control protocols appear where they should not. Keep logging and investigation tools working when everything outside OT is down. Keep OT design and installation details out of public view, and require suppliers to do the same.

Practitioner checklist

1. Name your vital OT and list everything it depends on, including services in IT or the cloud. 2. Map every path into OT and confirm remote access ends in the DMZ with MFA, time-limited sessions and recording. 3. Write down how to isolate each site, label the isolation points and run an isolation exercise; note every licence, update or supplier service that broke. 4. Start or tidy the unpatchable-asset register with named risk owners. 5. Check that offline per-site backups of logic, firmware and configuration exist and have been restored in a test. 6. For SOCI-regulated assets, use this work as evidence for the cyber hazards part of your critical infrastructure risk management program.