AI agents investigate every alert, add context, and prepare cases for response, on a full-stack SecOps platform that captures and correlates all your security data.
Cloud-based SIEM platform providing visibility across all your data sources
Every alert investigated, with a verdict and the evidence behind it
Manage your external footprint, publicly available data, and Dark Web leaks
Log management and threat detection across any of your log sources
Get ultimate assurance that your environment is free from threat actors
Fully featured distrubuted NDR for on-premises and public cloud environments
A SecOps platform purpose-built for industrial and OT environments
Integrated endpoint agent providing deep visibility, response and forensics
Deploy honeypots and honeytokens and stay ahead of threat actors
24x7 security operations from our Australian SOC. AI investigates every alert, and experienced analysts validate findings and contain threats around the clock.
24x7 managed detection and response across endpoint, network, cloud, identity, and log sources
AI investigations and 24x7 MDR on the Microsoft Sentinel you already own
Eyes-on-glass SOC and continuous threat hunting
Expert hunters and AI agents find attacker activity your alerts missed
Quickly recover from cyber attacks and breaches
ThreatDefence is the only SecOps as a Service company providing broad coverage across your entire technology stack with evidence-based security.
We provide security teams with full-stack SecOps infrastructure – you get deep visibility from day one, gain control over your security data, and get access to a comprehensive set of ready-to-use tools, detections, workflows, playbooks and scenarios.
24x7 SOC, Continuous Monitoring, Threat Containment and Incident Response
Visibility and actionable insights for all IT assets
Leverage our Cyber Range to train defenders based on real-world scenarios and simulations
OT and industrial cyber security services for critical infrastructure
Monitoring, evidence and a 24x7 SOC in one platform
Compliance monitoring, evidence and board reporting
Privacy Act reform impacts, obligations, and practical security considerations
Monitoring and compliance support for critical infrastructure environments
A practical guide to securing critical infrastructure with continuous monitoring
A practical buyer’s guide for schools evaluating SIEM and SOC services
A practical guide to selecting the right SIEM and SOC service for local government
Articles on security operations, AI and compliance
Events, awards and company news
Read what our customers say about us
Solution briefs and datasheets
How we keep your data secure
Technical support and knowledge base
Guides, case studies, and advisories in one place
How AI agents investigate alerts and run security operations
Free ebook: a practical guide to adopting an AI SOC platform
A practical guide to incident response and digital forensics
Where SOAR playbooks fit and where AI agents take over
Free ebook: modern security operations with Microsoft Sentinel
How the framework is structured and what changes from the Essential Eight
November 10, 2026
November 6, 2026
We provide end-to-end SecOps solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs).
Find out how you can become a ThreatDefence partner.
Protect your entire technology stack and build your SecOps on your own pace
White-labeled AI SOC for every client tenant, co-managed with our SOC team
Launch your SOC business without any upfront investment
Embed security operations, threat intelligence and exposure data in your product
Sovereign SOC for Australian MSPs and MSSPs, with onshore analysts and client data
Set the rules for closing alerts automatically, with evidence checks and review
How MSPs deliver branded security monitoring with a SOC partner
ThreatDefence was an official partner of the Cyber Resilience Summit NSW, 29 October 2026 at Hilton Sydney.
Our team was back at BSides Canberra, and our cyber quiz was a hit again.
Two days in Perth with our partner Ever Nimble, on security operations and cyber resilience.
Sponsors of the AUSCERT Cyber Security Conference on the Gold Coast.
Sponsors of the Gartner Security & Risk Management Summit in March.
Sponsors of the Cyber Security for Critical Assets Summit in Perth, February 2026.
Expert conversations with speakers and attendees at CyberCon Melbourne 2025.
The Australian Signals Directorate published ASD Essentials for OT as a separate chapter for operational technology, where a cyber security change can affect a physical process or an essential service.
Its principles and actions are organised around safe operation, continuity, controlled connectivity and the ability to isolate vital OT.
The chapter was published on October 15, 2026. Existing SOCI Act and CIRMP obligations still apply. Those rules list the Essential Eight among their accepted frameworks and do not name ASD Essentials.
Operational technology (OT) covers the systems that detect or cause direct changes to the physical environment by monitoring or controlling devices, processes and events.
The chapter is aimed mainly at operators of complex control, automation and safety systems in public transit, critical supply chain logistics, power generation, transmission and distribution, water and wastewater, medical services and large-scale industry.
Its principles apply to OT more broadly. What changes from enterprise IT is the cost of applying them: a control that is routine on an office server may need engineering approval, planned maintenance or compensating protections on an industrial system.
ASD uses the term vital OT for the subset of critical systems that cannot acceptably remain offline for an extended period, measured against the safe provision of a minimum viable product.
The definition takes manual operating procedures and business continuity plans into account. A system may be vital simply because manual procedures cannot sustain the service for long enough.
Identifying vital OT means documenting:
The equipment and services needed to maintain minimum viable operations.
How long each system can be unavailable without unacceptable consequences.
The identity, communications, storage, licensing and other services vital OT needs to keep operating.
The manual procedures and continuity arrangements available when normal systems cannot be used.
Dependencies outside OT deserve the closest look. A typical case is an authentication, licensing or communications service hosted elsewhere, which vital OT loses the moment it is isolated.
The chapter complements ASD’s CI Fortify guidance and deals with these operational dependencies directly. The Essential Eight never did: ASD says it was not designed for OT.
ASD’s guidance on which chapter to start with uses OT to show that the starting point depends on risk and that no fixed sequence suits every organisation:
OT systems may operate for decades. Unsupported platforms, legacy protocols, safety requirements and restricted maintenance windows can make patching or replacement impractical without significant investment or disruption.
An incident may affect personnel safety, physical processes, environmental conditions or essential service delivery. ASD notes that an organisation’s OT can carry materially higher risk than enterprise IT.
Limited connectivity may reduce some exposure, but remote access and integration arrangements change. An environment that was isolated when it was commissioned may no longer be, so the risk position is documented and reviewed.
Most OT operators also run enterprise IT, so both chapters apply. Assess the interfaces between them explicitly, particularly historians, remote access infrastructure and shared identity services. An enterprise IT compromise may open a route towards operational systems through any of them.
ASD Essentials for OT puts Boundary services and Critical processes and services in priority phase 1. Privileged environments and Identity services follow in phase 2, with the supporting Business systems in phase 3. The order reflects the consequences of losing control of an operational process.
Enterprise IT is sequenced differently, as the table shows. Identity services is a phase 1 domain there, and Critical processes and services waits until phase 2.
Boundary protections govern every connection to a less trusted environment, enterprise IT and external networks included. Critical process protections cover the systems responsible for safe operation, environmental protection and continuity of essential services.
Each depends on the other. Restricting an external connection helps only when the process can continue safely without it.
Privileged environments and Identity services decide who can administer OT and how. An engineering workstation, a privileged account or an authentication service can change configurations or control functions, so a weakness here can turn a limited compromise into unauthorised access to critical systems. The chapter addresses privileged devices and identities together, including the hardened environments that administration originates from.
Business systems come last, and they still matter: their failure or compromise can disrupt operations or create a route into OT. Scope them by the data, communications and administration they share with OT, whichever part of the organisation owns them.
ASD also recognises that operational requirements may constrain patching and replacement. Compensating controls and a register of unpatched assets apply across every OT technical domain, whatever its priority phase.
Every device inside an OT system is treated as privileged, including the workstations and other endpoints that enterprise IT would class as user devices. This is why the OT technical domain mapping has no User devices domain: an end-user device in its typical configuration can introduce threats directly into an environment with elevated operational trust.
ASD states: All devices within the OT system must be considered as privileged and treated accordingly.
All devices within the OT system must be considered as privileged and treated accordingly.
Several of the chapter’s actions follow from that position:
Operator workstations, engineering devices and connected endpoints fall under Privileged environments.
Administrative, engineering and troubleshooting access originates from dedicated, hardened environments in a segment with equal or greater trust than the target system.
Each privileged function uses a distinct role on a unique account, limited to that function.
Default, supplier-provided and simple passwords are changed before commissioning. Compensating controls apply where equipment cannot support unique credentials.
Unused physical ports and removable media interfaces are disabled where business continuity requirements permit.
Classification follows where a device operates and what it can reach. An engineering workstation may look like an office computer and still be able to modify a control system. Business systems can remain within enterprise IT, although ASD notes that their role in supporting operational processes may bring them within the OT system.
PRO-19 Operational technology isolation asks operators to be able to disconnect vital OT from external environments and sustain safe operation for a defined period.
A firewall rule or a network diagram cannot show that on its own. Both describe the connection. Neither says whether vital OT keeps operating safely once the connection is gone.
The chapter calls for demilitarised zones that isolate OT at its perimeters from every network outside the organisation’s sole administrative control. It also calls for documented isolation procedures that physically identify the cables and equipment involved.
That detail is for the people on shift when isolation is called. They need to know in advance which connections to disconnect, which services will be affected and how to confirm that isolation holds.
ASD calls for isolation points that can be managed only from within vital OT, so that isolation, once enacted, cannot be reversed from outside. An attacker who controls enterprise IT or external management infrastructure then has no way to restore access.
Vital OT is expected to stay safe and operational throughout its defined isolation period, including when services outside OT are unavailable. ASD calls for the services it depends on to operate independently, using separate software, credentials, storage, policy and servers.
The dependencies to assess include:
Software licences, activation services and hardware-linked licensing that might stop operation after disconnection.
Reliance on external update infrastructure, suppliers and maintenance services, identified, tested and resolved.
Break-glass accounts and their secrets, verified as usable when external identity services cannot be reached.
Ways for sites, operators and responders to communicate when normal channels are lost.
Continuity plans that account for the isolation period, including access to the staff needed at affected sites.
Test the loss of each external service, because assurances are no substitute. A controller may keep running while an engineering workstation loses authentication or a licensed application cannot restart.
ASD calls for regular exercises of isolation, sustained operation and safe reconnection. GOV-07 lists what they cover: isolation decisions, operation throughout the defined period, degraded communications, staff movement, artefact capture and safe removal of isolation.
The exercises also cover threat hunting before reconnection. The hunt answers whether the compromise is still active and whether reconnecting would restore an attacker’s access.
threat hunting before reconnection
The exercise record captures when isolation was enacted, whether each mechanism held, how long vital OT operated safely and which dependencies failed. Each failed dependency then becomes a remediation item to close before the next exercise.
Under the OT chapter, remote access is explicitly authorised, time-bound and monitored. PRO-20 Remote access to operational technology holds the main boundary and session actions. Related identity, detection and response actions cover authentication, session records and the termination of suspicious connections.
ASD specifies: Ensure remote access is not routed directly into OT, terminating all traffic in the OT demilitarised zone before the next hop.
Ensure remote access is not routed directly into OT, terminating all traffic in the OT demilitarised zone before the next hop.
The chapter’s remote access actions include:
Each remote session is explicitly established and granted for a limited time. No connection is permanent, and an idle session is disconnected after a defined period of inactivity.
Users authenticating across an OT perimeter, or from networks outside sole OT administrative control, use phishing-resistant multifactor authentication (MFA).
Authorised remote users are tracked, periodically reviewed and limited to their work.
Every remote session records the user, timestamp and target. Monitoring identifies deviations from validated activity patterns.
Local operators are informed of authorised vendor and maintenance activity, so that unexpected changes are not normalised or ignored.
so that unexpected changes are not normalised or ignored.
A documented, exercised procedure disconnects remote access quickly when malicious activity is identified.
Strong authentication does not compensate for a connection that bypasses the OT demilitarised zone or remains permanently established.
Monitoring needs operational context to be useful. A supplier connecting in an approved maintenance window may be expected. The same source reaching an unfamiliar target outside that window warrants investigation.
Match session records against approved users, work periods and targets. A vendor’s notification says what the vendor intended to do, and the session record shows what happened.
OT remote access monitoring covers collection and investigation of session records, connection changes and access alerts.
Controls for OT safety and legacy systems have to preserve availability while they protect safety functions, manage unsupported equipment and allow a site to recover independently.
The chapter asks operators to identify safety components and their dependencies, including the communications that connect safety functions with external alarm systems. Safety systems are segmented from other OT systems at a network boundary. Device configuration alone does not count as separation.
When communications are degraded, the external alarm paths still have to be understood, and a change made from outside the site safety system boundary cannot be allowed to compromise a protected safety function. Physical site access controls keep operating through degraded or isolated conditions.
OT vulnerability management follows defined, risk-based patching timeframes, with compensating protections for equipment that cannot or will not be patched. The chapter calls for a register containing:
Equipment that cannot be patched or for which patching will not be performed.
The technical or operational constraint preventing remediation.
The protections applied to reduce exposure.
The risk remaining after compensating protections are considered.
The authority accepting that residual risk and the relevant review dates.
Each entry is reviewed at the defined cadence and whenever the asset’s exposure changes. Compensating protections are sized to the actual risk. A vulnerable workstation with limited, monitored access is a different problem from one reachable through an unrestricted remote connection.
The chapter also calls for hardening new instances of control software where doing so does not degrade the availability or safety of the OT system.
where doing so does not degrade the availability or safety of the OT system.
OT recovery planning accounts for destructive attacks, damaged equipment and periods when supplier support cannot be reached. The chapter’s recovery actions cover:
Firmware, configuration, licence, calibration, project and logic files, plus the supplier images needed to rebuild OT systems, held per site and isolated from network access.
Systems that cannot acceptably remain offline are recoverable to a minimum viable level of service without supplier support.
Plans are maintained for replacing important OT devices following destructive attacks.
Equipment integrity and provenance are verified before hardware is introduced into OT, and equipment returned for maintenance is sanitised.
Recovery tests show whether each site can restore the operational function it needs within its defined recovery objectives.
The OT chapter also addresses system exposure minimisation. It asks operators to protect information about operational systems, to keep device installation details out of public view and to hold third parties to the same expectation.
OT visibility and incident response have to stay useful through degraded communications and isolation. ASD notes that monitoring in OT also supports engineering fault analysis, and that limited visibility can delay the detection, analysis and containment of intrusions, which in OT could lead to potentially catastrophic system failure.
Use an approved mechanism supporting automated discovery of new and changed assets. Record physical and logical location, role, criticality, dependencies, known vulnerabilities and compensating controls.
Document the critical systems that must remain available and the services enabling them, including dependencies outside the OT environment.
Continuously review connections, exposed pathways, network boundaries and the points where complete isolation can be enacted.
A workable inventory keeps approved records apart from newly observed activity. A device that first appears in network traffic is an observation until engineering has validated it.
Communication records add what an asset list cannot: which systems exchange data across OT boundaries, and which of those connections could become unavailable during isolation.
OT incident procedures have to stay within reach when the systems normally used for communication, documentation or investigation are not. The chapter addresses:
Maintain tested and approved procedures for safety events, loss of visibility, workstation compromise and other OT incidents, including the people and third parties involved.
Keep playbooks, network drawings, configuration instructions, break-glass secrets and emergency contacts available without depending on systems being recovered.
Prepare for forensic artefact collection in pre-approved areas for later offline analysis.
Maintain a way for personnel to report OT cyber security concerns without depending on systems outside OT.
Each procedure names who makes operational decisions and which specialists are involved. An investigation may recommend restricting a connection. It is the operator who assesses whether doing so could interrupt a safety function or an essential service.
OT monitoring draws on hosts, network boundaries and configuration changes, and the ability to investigate has to remain available during isolation.
On hosts, the chapter calls for logging on operator, engineering and server systems, with collection, querying and investigation still possible when systems outside OT are unavailable.
On the network, it calls for traffic capture on both sides of all OT-connected demilitarised zone boundaries and at interfaces between OT segments, including detection of unexpected control protocols crossing segment boundaries. OT network detection and response explains sensor placement and the resulting network visibility.
on both sides of all OT-connected demilitarised zone boundaries
Configuration changes across OT and its demilitarised zones, including changes to name resolution records, are detected and addressed.
Check monitoring coverage against the actual network. A sensor receiving traffic from one side of a demilitarised zone boundary says nothing about the other side.
ASD’s AI guidance adds that AI-enabled monitoring relying on vendor cloud services should not create pathways or dependencies that impact OT isolation capability. In our reading, that means checking which evidence and functions remain once the vendor connection is cut.
ASD has published no OT-specific assessment workbook, evidence guide or scoping guide, so the checks below follow the OT chapter’s action text and ASD’s general assessment process guidance. The collection methods are common practice rather than ASD requirements.
Dated exports and exercise records are stronger evidence than screenshots, which help only when they identify the date, site and system.
ASD’s assessment process considers whether evidence is recent enough to represent current operation. A session log exported for a single day shows that day. Records spanning the assessment period show that the control kept operating.
An isolation procedure with no evidence of testing is likely to support a lower effectiveness rating than one backed by dated exercises and verified outcomes. The same applies to remote access, recovery and monitoring.
For a covered critical infrastructure asset, the framework obligation comes from the SOCI Act and its critical infrastructure risk management program (CIRMP) rules. ASD Essentials can guide improvements across enterprise IT, OT and cloud, but the selected CIRMP framework sets the compliance obligation.
The rules are contained in LIN 23/006, with the current compilation dated June 10, 2026. Section 8 sets the baseline framework requirements and section 8A the enhanced requirements for specified asset classes.
Under section 8, compliance with the selected framework was required within 12 months after the end of the initial applicable period. The enhanced requirements have separate transitional arrangements.
The CIRMP rules incorporate the listed frameworks as in force from time to time. For the Essential Eight, that means the maturity model ASD maintains, whose current release remains November 2023.
as in force from time to time
SOCI offers the Essential Eight as one compliance option and does not require it of every operator. An operator using ISO/IEC 27001, NIST or the AESCSF may meet the applicable framework obligation without reporting an Essential Eight maturity level.
The Security of Critical Infrastructure Legislation Amendment (Enhanced Critical Infrastructure Risk Management Program) Rules 2026, F2026L00701, were registered on June 9, 2026 and commenced on June 10, 2026. Section 4A(1) identifies the affected classes:
For these classes, section 8A requires a higher level or updated version of the selected framework. The Essential Eight option moves from Maturity Level One to Maturity Level Two, and the other options change as shown in the table. Existing assets have a 24-month grace period from commencement for the enhanced framework uplift.
Section 8B introduces phishing-resistant MFA obligations where an entity subject to the enhanced requirements uses a framework that does not already require it. ASD Essentials contains a related identity action calling for phishing-resistant MFA, explained in the ASD Essentials Identity services guide.
The enhanced framework requirement does not apply to every critical infrastructure asset. Other assets keep their baseline obligations, so confirm each asset’s regulatory position before setting its framework, maturity level and schedule.
ASD Essentials results and CIRMP framework compliance are tracked separately because they assess different requirements. ASD has advised organisations to continue meeting existing regulatory obligations until relevant regulators communicate changes.
An operator can use ASD Essentials to find weaknesses, prioritise improvements and assess effectiveness while reporting against its selected CIRMP framework.
Framework equivalence remains unresolved. CIRMP permits equivalent frameworks, but no published guidance says whether ASD Essentials qualifies as one. Confirm the position with the relevant regulator before relying on ASD Essentials for CIRMP compliance.
ASD’s cross-references to NIST CSF 2.0 and the AESCSF are covered in ASD Essentials vs ISO 27001, NIST CSF and SOC 2.
Essential Eight Maturity Level Two remains a live target for operators whose assets are subject to section 8A and whose selected CIRMP framework is the Essential Eight.
ASD’s transition guidance advises against beginning work solely to achieve a superseded Essential Eight target unless a regulator or another obligation still requires it, or the work addresses material risk. For these operators, enhanced CIRMP is that obligation.
ASD also states that organisations at Maturity Level Two can expect many existing controls to contribute to the early ASD Essentials priority phases, though that does not show every applicable action is fully effective. The moving from the Essential Eight to ASD Essentials guide covers the transition and reuse of existing controls and evidence.
An enterprise IT assessment says nothing about OT. The OT chapter has its own technical domain mapping, priority phases and principles for isolation, remote access and continuity, so assess OT under it and record its interfaces with enterprise IT.
A shared identity service or remote access gateway may sit in an enterprise IT assessment while supporting OT. The OT assessment asks what happens to that dependency during isolation, so the same infrastructure can produce different conclusions in each.
For each covered asset, the CIRMP record sets out:
Which critical infrastructure asset is subject to the requirement.
Whether section 8 or the enhanced section 8A applies.
The framework used to meet the CIRMP obligation.
The maturity level, framework version or security profile the rules specify.
The relevant grace period and implementation deadline.
The latest assessment result and outstanding improvements.
Mandatory CIRMP work stays on its required schedule. Further ASD Essentials improvements can follow the chapter’s priorities, with the reason recorded where the order changes.
CIRMP reporting uses the terminology of each asset’s selected framework, while ASD Essentials reporting shows effectiveness by domain, principle and applicable action. Dated access reviews, monitoring records, isolation exercises and recovery tests can serve both.
The results themselves have to stay distinguishable. An Essential Eight maturity result is not an ASD Essentials effectiveness rating, and a completed ASD Essentials assessment does not show CIRMP compliance.
ThreatDefence runs a 24x7 SOC with its team based in Australia and a 3 min average response under guaranteed SLAs. Threat hunting and an incident response retainer are included in the standard service.
Response actions remain within each customer’s approved authority, and case records can be exported for an assessor or at the end of a contract. Australian customers’ data and AI processing stay in Australia.
ThreatDefence does not certify organisations. The assessor determines ASD Essentials ratings.
ThreatDefence provides critical infrastructure security monitoring across enterprise IT and OT. Its OT SOC services include network detection and response for operational environments.
OT NDR detections cover reconnaissance and lateral movement, new control senders, remote access from first-seen sources and business hosts connecting to OT systems.
Decisions affecting operational safety and isolation remain with the operator. The same SOC team can support threat hunting before reconnection.
The free ASD Essentials Navigator lets organisations rate their environment action by action, with principle and domain results that update as the assessment progresses. Readers new to the framework can start with the five-minute ASD Essentials explainer, which walks through principles, actions, domains, priority phases and ratings.
Open the ASD Essentials Navigator Start the 5-Minute Explainer Explore ASD Essentials Compliance
See how ThreatDefence automates security monitoring, compliance and cyber risk management in one platform.
CountryAustraliaUnited StatesNew ZealandUnited KingdomCanadaSingaporeOtherI'm an MSP, MSSP, or reseller
Δ
No. The CIRMP rules under the SOCI Act require responsible entities to comply with one of the listed cyber security frameworks or an equivalent. The Essential Eight is one option alongside ISO/IEC 27001, NIST, C2M2 and the AESCSF. Neither list names ASD Essentials, and whether it qualifies as an equivalent is unresolved, so confirm the position with the relevant regulator.
They apply to critical broadcasting, domain name system, electricity, energy market operator, freight infrastructure, freight services, gas, liquid fuel and water assets. For these classes, section 8A raises the Essential Eight option to Maturity Level Two. Existing affected assets have a 24-month grace period from June 10, 2026 for the uplift. Other assets keep their baseline requirements.
Yes, where an asset is subject to section 8A and the operator has selected the Essential Eight as its CIRMP framework. ASD advises against starting work solely for a superseded Essential Eight target unless a regulator, another obligation or material risk justifies it, and enhanced CIRMP provides that obligation. Existing Maturity Level Two controls may support early ASD Essentials actions without proving full effectiveness.
The regulatory outcome remains unresolved. CIRMP incorporates the Essential Eight Maturity Model as in force from time to time, but no published direction explains how the rules would operate if ASD retired it. ASD has announced no retirement date and maintains both frameworks. An ACSC official indicated in June 2026 that deprecation could begin in about 12 months, with retirement following at 24 months, but no ASD policy sets those dates.
No. ASD says the Essential Eight was designed for internet-connected IT networks and was not designed for operational technology. The ASD Essentials OT chapter addresses operational systems directly, including PRO-19 Operational technology isolation and PRO-20 Remote access to operational technology. Regulatory obligations that name the Essential Eight still apply as written, so the framework guiding OT improvements is kept separate from the one used for reporting.
No. ASD publishes OT as a separate chapter with its own technical domain mapping and priority phases, with Boundary services and Critical processes and services first. An enterprise IT assessment may provide evidence for shared systems but says nothing about how effective the OT controls are. Assess OT separately and document the interfaces, access paths and dependencies between the environments.
Vital OT is the subset of critical operational systems that cannot acceptably remain offline for an extended period, judged by the safe provision of a minimum viable product and considering manual operating procedures and business continuity plans. Operators identify vital systems, their acceptable disruption periods and their dependencies, including external ones. The chapter also addresses recovering them to a minimum viable level of service without supplier support.
PRO-19 asks operators to maintain the capability to isolate vital OT and sustain safe operation throughout a defined isolation period. Demilitarised zones separate OT from networks outside sole administrative control, and isolation points are managed only from within vital OT so external systems cannot reverse isolation. Supporting software, credentials, storage, policy and servers operate independently. GOV-07 calls for regular exercises, including threat hunting before reconnection and safe removal of isolation.
Yes, within the OT chapter’s protections. PRO-20 calls for explicitly established, time-bound sessions, no permanent connections and disconnection after defined inactivity, with traffic terminating in the OT demilitarised zone. Users crossing the OT perimeter use phishing-resistant MFA, every session records its user, timestamp and target, and local operators are informed of authorised maintenance. OT remote access monitoring explains the associated evidence and alerts.
No. As of late 2026, ASD had published no OT-specific assessment workbook, evidence guide, scoping guide or OSCAL release, while enterprise IT has dedicated assessment materials and cloud has a scoping guide. OT assessments can use the chapter’s action matrices with ASD’s general assessment process guide. Dated isolation exercise records, remote access logs, unpatchable asset registers and recovery tests show whether controls work.
ASD Essentials Explained: Framework, Chapters and Enterprise IT
ASD Essentials vs ISO 27001, NIST CSF and SOC 2
ASD Essentials Boundary Services