OT isolation for critical infrastructure is an essential resilience capability for organisations operating vital industrial systems. As Operational Technology environments become more connected to enterprise IT, cloud platforms, vendors and remote-access services, operators must be prepared to contain cyber incidents without interrupting essential services.

That connectivity supports efficiency, centralised management, remote maintenance, data analytics, and faster operational decision-making. It also creates pathways through which a compromise originating in an IT network, vendor environment, cloud service, or remote-access platform can reach systems responsible for physical processes.

For critical infrastructure operators, the security objective is therefore no longer simply to prevent every intrusion. Organisations must also be able to contain a serious incident while continuing to deliver essential services.

On 28 July 2026, the Australian Signals Directorate’s Australian Cyber Security Centre published its CI Fortify advice for isolating vital systems. Developed with international partners, the guidance provides a practical framework for identifying, separating, isolating, operating, and monitoring vital OT and supporting systems during cyber incidents or periods of increased threat.

Its core message is clear:

Isolation should not be treated as an emergency improvisation. It must be designed, documented, tested, monitored, and integrated into normal operational resilience planning.

Isolation is more than network segmentation

The terms segmentation, separation, and isolation are often used interchangeably, but the CI Fortify guidance makes an important distinction.

Network segmentation divides an environment into zones and restricts communication between them. It is a foundational control that can reduce attack paths and limit lateral movement.

Physical separation means that vital OT systems do not share active infrastructure—such as switches, routers, compute platforms, multiplexers, or management systems—with lower-trust or non-vital networks.

Isolation is an operational capability: the organisation must be able to disconnect vital systems from other networks and continue providing the critical service independently.

A network can appear well segmented during normal operations but still be impossible to isolate safely. Shared authentication, DNS, DHCP, storage, virtualisation, backups, time synchronisation, remote access, or management infrastructure may remain hidden dependencies.

CI Fortify therefore asks a more demanding question:

Can the organisation disconnect its most important operational systems and still operate safely for an extended period?

That is not purely a firewall architecture question. It is a combined engineering, cybersecurity, business-continuity, safety, and incident-response challenge.

1. Identify the systems that are genuinely vital

The first stage is to identify the minimum set of systems and networks necessary to deliver the critical service.

This definition matters. If everything is classified as vital, isolation planning becomes unmanageable. If the scope is too narrow, operators may discover during an incident that an apparently secondary system is essential to maintaining safety, visibility, or control.

The analysis should include obvious operational components such as:

• Programmable Logic Controllers and Remote Terminal Units
• Distributed Control Systems
• Human-Machine Interfaces
• Safety and protection systems
• Engineering workstations
• Historians and operational databases
• Communications gateways
• Network-management systems

It must also include enabling systems whose failure could prevent the critical service from continuing. These might include local identity services, name resolution, time synchronisation, backup power, cooling, physical access control, telecommunications, configuration repositories, or recovery systems.

The resulting inventory should represent the smallest defensible operating environment capable of maintaining the organisation’s critical mission.

This is where asset visibility becomes a resilience dependency rather than merely a compliance exercise. An organisation cannot isolate systems it has not identified, and it cannot protect dependencies it does not understand.

2. Understand who depends on the service

CI Fortify expands the analysis beyond the operator’s own environment by asking organisations to identify their critical customers.

A power operator may support hospitals, water utilities, telecommunications infrastructure, transport systems, emergency services, defence facilities, or other electricity networks. A disruption in one environment can rapidly create cascading effects elsewhere.

The guidance recommends establishing measurable service-delivery targets based on the needs of those dependent organisations. These targets may include quantities such as power output, water volume, service capacity, quality requirements, or minimum operational availability.

This changes the isolation decision from a binary technical action into a mission-based operational choice.

The correct question is not only:

“Can we disconnect this network?”

It is also:

“What level of service must remain available after we disconnect it?”

These requirements should shape which systems are considered vital, how long they must operate independently, what manual procedures are required, and which external connections must remain available.

3. Group systems by criticality and trust

OT environments are not uniform.

A safety controller, an engineering workstation, a corporate reporting server, a vendor jump host, and an internet-connected remote-access gateway should not be treated as though they have the same operational importance or threat exposure.

CI Fortify recommends grouping systems into zones and segments based on common levels of criticality and trust. This creates the foundation for applying stronger controls to the systems that matter most.

A mature zoning model should consider:

• Operational and safety impact
• Required availability
• Exposure to untrusted networks
• Administrative access requirements
• Protocols and information flows
• External or third-party dependencies
• Recovery requirements
• Consequences of compromise
• Consequences of isolation

The result should not be a diagram created only for an audit. It should become an operational model that informs architecture, detection logic, access policy, incident-response actions, and recovery priorities.

4. Map every connection into and out of vital systems

One of the most valuable parts of the guidance is its focus on connectivity mapping.

After identifying vital systems, organisations should record every point at which those environments connect to other systems or networks. This includes connections to:

• Corporate IT environments
• Vendor and contractor remote-access services
• Managed service providers
• Internet-facing infrastructure
• Cloud platforms
• Mobile or wireless networks
• Carrier-provided services
• Peer utilities and dispatch operators
• Other OT sites
• Emergency maintenance pathways

For each connection, the organisation should understand its business purpose, owner, provider, protocol, information flow, availability requirement, recovery point objective, and recovery time objective.

Architecture diagrams, firewall configurations, router configurations, VPN details, internet gateway documentation, and emergency contact information should be available before an incident begins.

This work frequently reveals that the effective OT attack surface is larger than the visible OT network.

For example, an attacker may not need direct access to a controller if they can compromise:

• A vendor’s remote-support account
• A shared Active Directory environment
• A virtualisation management plane
• A cloud-hosted engineering repository
• A common backup system
• A software-defined networking controller
• A poorly governed jump server
• An internet-facing gateway that was not included in the OT inventory

Every trusted connection should therefore be treated as both a business dependency and a potential attack path.

5. Reduce hidden IT-to-OT dependencies

An isolation plan can fail even when the firewall rules work perfectly.

Vital OT environments often depend on non-OT services for authentication, DNS, DHCP, certificates, time synchronisation, storage, backups, virtualisation, monitoring, firmware, and configuration management.

Disconnecting the OT network may therefore create authentication failures, certificate-validation issues, time drift, lost operator visibility, inaccessible backups, unavailable documentation, or degraded industrial processes.

CI Fortify recommends reducing or eliminating dependencies that could prevent independent operation. Where possible, operators should establish localised capabilities inside the appropriate OT security domain.

Examples may include:

• Local authentication for essential operational accounts
• OT-controlled DNS and time services
• Local copies of approved firmware and configuration files
• Independent OT backup and restoration capabilities
• Offline recovery documentation
• Dedicated administrative workstations
• Locally available engineering tools
• Independent monitoring and logging
• Separate power, cooling, and physical-security controls

This does not mean duplicating every enterprise service inside OT. It means understanding which dependencies are mission-critical and ensuring that isolation does not create an avoidable operational outage.

6. Build credible separation and isolation points

Isolation points are the technical locations at which communication between vital and non-vital environments can be restricted or completely stopped.

Depending on the architecture, these may include:

• Physical disconnection points
• Dedicated OT firewalls
• Route withdrawal or route blocking
• IP access-control lists
• Routing black holes
• Disabled remote-access gateways
• Dedicated encrypted links
• Cross-domain solutions
• Data diodes
• Separate carrier circuits
• Dedicated fibre pairs or wavelengths

The guidance identifies physical isolation as the strongest form of protection because it removes shared connectivity and infrastructure between vital and non-vital systems.

However, complete physical isolation may not be practical for geographically distributed operators, internet-dependent critical services, or organisations that depend on carrier networks.

In those cases, the guidance recommends stronger protection of OT boundaries, dedicated communications where possible, and robust encryption across shared or untrusted networks. Carrier services should be treated as untrusted, and encryption should be implemented using dedicated, appropriately hardened devices controlled from the trusted environment.

The guidance also warns against assuming that logical separation provides the same assurance as physical separation.

VLANs can support internal segmentation, but they should not be relied upon as the long-term isolation mechanism between different security domains. Similarly, MPLS does not provide secure segregation by default and requires cryptographic protection when carrying critical OT traffic over an untrusted provider environment.

7. Secure the control plane

An isolation control is only as trustworthy as the system used to administer it.

An attacker who compromises the network-management plane may be able to restore prohibited routes, modify access lists, change VLAN assignments, disable encrypted tunnels, or otherwise defeat isolation controls.

CI Fortify consequently recommends securing privileged access to routers, firewalls, switches, and other network infrastructure.

Where possible, operators should use:

• Physically segregated management networks
• Dedicated out-of-band interfaces
• Privileged access workstations
• Trusted administrative hosts
• Strong conditional access
• Restricted management protocols
• Hardened network appliances
• Local logging of configuration changes
• Alerting on routing and adjacency changes

Remote access to critical management zones from lower-trust environments should be disabled, particularly during elevated threat conditions or active incidents.

This principle also applies to network orchestration, software-defined networking, API-based provisioning, and Network-as-Code platforms.

Automation can make isolation faster and more consistent, but it also concentrates control. If the orchestration platform is compromised, the attacker may gain the ability to alter the same policies the organisation depends upon for containment.

Automation must therefore include strong identity controls, change validation, approval gates, audit trails, configuration integrity checks, rollback procedures, and an independent manual fallback.

8. Create a graduated isolation plan

Immediate total disconnection may sometimes be necessary, but it can also create unacceptable operational consequences.

CI Fortify recommends a graduated isolation plan that progressively reduces access as the threat level increases.

A possible sequence might include:

1. Disable external remote access to OT.
2. Terminate active vendor and contractor sessions.
3. Restrict administrative access to approved on-site workstations.
4. Block non-essential IT-to-OT information flows.
5. Disconnect corporate IT from OT.
6. Restrict lower-priority peer and inter-site connections.
7. Isolate the most vital OT systems completely.

The exact sequence will depend on the organisation’s architecture and mission.

What matters is that each stage has predefined trigger criteria. These triggers should be connected to the incident-response plan and should consider both the cyber threat and the operational impact of the action.

Possible triggers may include:

• Confirmed compromise of a remote-access service
• Malware propagation in the corporate environment
• Compromise of privileged credentials
• Unexpected changes to firewall or routing configurations
• Malicious activity on an OT jump host
• Detection of command-and-control traffic
• Evidence of lateral movement toward OT
• A sector-wide warning from a competent authority
• Loss of confidence in a critical third-party provider

Decision authority must also be defined in advance.

During a high-pressure incident, teams should not be debating for the first time whether the CISO, plant manager, incident commander, control-room supervisor, or executive crisis team is authorised to isolate a system.

9. Test the entire isolation capability

An untested isolation plan is an architectural hypothesis.

CI Fortify recommends regularly testing isolation procedures for all vital systems. Testing only one system or a small subset may fail to expose shared dependencies that appear only when the complete environment is disconnected.

Exercises should validate:

• The technical isolation mechanism
• Decision and escalation procedures
• Continued operational capability
• Manual fallback processes
• Safety implications
• Visibility after disconnection
• Local authentication and administration
• Vendor and partner communications
• Restoration and recovery procedures
• Reconnection criteria

Plans should also be stored in a secure offline format, including a hard-copy version, so that responders can access them if normal documentation systems are unavailable or compromised.

Testing should include more than tabletop discussion.

Where operational safety permits, organisations should perform controlled technical exercises that confirm routes are removed, sessions are terminated, prohibited flows stop, local services continue functioning, monitoring remains available, and operators can maintain the required level of service.

10. Verify that isolation actually worked

Issuing an isolation command does not prove that the environment is isolated.

Routes may remain active. Backup links may automatically restore connectivity. A misconfigured firewall may permit an unintended flow. A carrier network may expose an unexpected path. An administrator may reconnect a system to resolve an operational problem.

Verification is therefore a continuous activity.

CI Fortify recommends inspecting routing tables at important convergence points and monitoring routing updates and adjacency changes. Devices can send these logs to an on-premises logging server or Security Information and Event Management platform, where detection rules can alert on changes that could reconnect OT and non-OT environments.

Operators should also monitor traffic flows at critical network points and perform controlled reachability tests between vital and non-vital networks.

Useful detection scenarios may include:

• A previously withdrawn OT route reappearing
• New adjacency formation on a critical router
• Traffic crossing a disabled trust boundary
• An unauthorised source reaching an OT address range
• Administrative access from outside the management zone
• Unexpected DNS or authentication requests leaving OT
• A new tunnel or remote-access session
• Changes to firewall, switch, or router configurations
• Traffic appearing on a physically or logically isolated interface
• Loss of expected telemetry from an isolation control

Monitoring must continue throughout the isolation period—not only during the first few minutes after disconnection.

11. Plan for the risks created by isolation

Isolation reduces some risks while introducing others.

The guidance highlights several challenges, including reduced external visibility, systems falling behind on updates, and increased reliance on removable media.

During prolonged isolation:

• Threat-intelligence feeds may become unavailable.
• Antivirus or detection signatures may stop updating.
• Central monitoring may lose telemetry.
• Vulnerability-management workflows may be interrupted.
• Certificate or time-dependent services may degrade.
• Operators may transfer files through removable media.
• Recovery tools may become inaccessible.
• Manual processes may increase the chance of human error.

Removable media deserves particular attention. When networks are disconnected, USB devices may become the default method for transferring configurations, logs, updates, or engineering files across security boundaries.

Media-control procedures should include approved devices, controlled transfer stations, malware scanning, integrity verification, chain-of-custody records, and clear authorisation requirements.

An isolation plan must preserve enough defensive visibility to avoid turning the protected environment into a black box.

12. Reconnection is a security-sensitive operation

Although isolation is the immediate focus, reconnection can be equally dangerous.

A system should not be reconnected merely because the visible incident appears to be over. The original access path may still exist, compromised credentials may remain valid, persistence may be present, or the receiving environment may still be untrusted.

Before reconnection, teams should establish confidence in:

• The integrity of vital OT systems
• The integrity of the network-control plane
• The security of external dependencies
• Privileged account recovery
• Configuration baselines
• Malware eradication
• Updated detection coverage
• Boundary-control validation
• Third-party access
• Continuous monitoring after restoration

Reconnection should be staged, logged, authorised, and observed. Each restored pathway should have a clear operational justification and should be monitored for unexpected behaviour.

Turning CI Fortify into an operational capability

The guidance demonstrates that OT isolation requires three complementary capabilities:

1. Architecture and engineering controls to create credible separation points.
2. Security operations capabilities to detect threats, trigger actions, and verify that controls remain effective.
3. Prepared people and procedures to make safe decisions under pressure.

Technology cannot replace physical separation, safety engineering, or a tested operational plan.

It can, however, help organisations maintain visibility, detect conditions that justify escalation, automate approved containment actions, and produce the evidence required to confirm that isolation remains effective.

Where Logstail can support the isolation lifecycle

The Logstail cybersecurity portfolio brings together security monitoring, asset visibility, alert management, automated response playbooks, external attack-surface management, compliance workflows, training, and continuous monitoring.

Within an OT isolation programme, these capabilities can support several practical use cases.

Centralised monitoring and correlation

Logs from OT firewalls, routers, VPN concentrators, jump hosts, identity systems, remote-access services, servers, and selected industrial security controls can be centralised for analysis.

Correlation rules can identify combinations of activity that may justify moving to a higher isolation stage—for example, a compromised privileged account followed by routing changes and unexpected traffic toward an OT zone.

Isolation-verification alerts

Detection content can monitor:

• Routing-table changes
• Firewall policy modifications
• New network adjacencies
• Unauthorised remote-access sessions
• Unexpected cross-zone traffic
• Configuration drift
• Administrative access outside approved pathways
• Loss of telemetry from critical isolation controls

This supports the CI Fortify recommendation to use SIEM queries and alerts to detect interconnection between OT and non-OT environments.

Controlled response automation

Automated playbooks can help security teams execute predefined, approved actions consistently.

Depending on the architecture and safety requirements, a workflow might:

• Open a high-severity incident
• Collect relevant logs and configuration state
• Notify OT operations and incident commanders
• Disable a remote-access account
• Revoke a session or credential
• Request approval for a network-control change
• Validate whether expected traffic has stopped
• Preserve evidence for investigation
• Track every action in an audit record

In safety-critical environments, automation should not blindly modify production controls. Human approval, role separation, rollback logic, and operational validation should remain central to the design.

External exposure discovery

Logstail’s External Attack Surface Management capabilities are designed to identify unmanaged domains, cloud assets, certificates, shadow IT, and risky internet-facing services.

For an OT operator, this can help identify external systems connected to the broader operational ecosystem—such as forgotten remote-access portals, vendor gateways, exposed services, or cloud assets—that may not appear in the internal OT inventory but could provide an indirect path toward critical environments.

Evidence and continuous improvement

Isolation exercises generate valuable security evidence.

SIEM events, workflow records, configuration snapshots, alert timelines, approvals, and post-exercise findings can help demonstrate that controls were tested and can identify gaps before a real crisis occurs.

The goal is to transform isolation from a static network diagram into a measurable operational process.

AICOT: Building OT-native monitoring and detection

Traditional security platforms often begin with IT assumptions. OT environments impose different constraints: deterministic communications, specialised protocols, legacy equipment, strict uptime requirements, safety implications, and limited tolerance for intrusive monitoring.

The AICOT project is developing an AI-driven cybersecurity platform specifically for Operational Technology environments in critical infrastructure.

Building on Logstail’s SIEM and data-analytics capabilities, the project aims to integrate machine learning, anomaly detection, OT protocol analysis, and threat intelligence to support real-time monitoring, detection, and response across diverse industrial environments.

AICOT’s objectives include:

• Developing a modular and scalable OT cybersecurity platform
• Detecting stealthy and previously unseen threats
• Analysing OT-specific protocols and telemetry
• Supporting secure, privacy-preserving threat-intelligence sharing
• Validating the technology through realistic OT pilot scenarios
• Strengthening European cybersecurity capability and digital sovereignty

These capabilities are relevant to the monitoring and verification side of CI Fortify.

An OT-aware platform could help distinguish legitimate operational behaviour from suspicious changes occurring before, during, or after isolation. Potential analytical scenarios include:

• Unexpected communication between OT zones
• New devices appearing in a vital segment
• Abnormal industrial protocol commands
• Changes in normal controller or HMI communication patterns
• Unexpected engineering workstation activity
• Traffic attempting to bypass an isolation boundary
• Inconsistent topology or asset behaviour
• Activity that suggests an attacker is preparing to regain access

AICOT should not be presented as a replacement for physical separation, cryptographic isolation, or properly engineered boundaries.

Its value is in helping defenders understand what is happening inside complex OT environments and identify behaviour that conventional IT-focused detection may miss.

Building the human capability through Logstail Academy

Technology controls will not execute an effective isolation strategy on their own.

Network engineers must understand OT consequences. SOC analysts must recognise industrial attack patterns. OT operators must understand escalation procedures. Incident commanders must be able to balance cyber containment with safety and service continuity.

The Logstail Academy OT and ICS learning path provides practical learning around layered industrial defence, including network segmentation, protocol hardening, secure remote access, firewall placement, and secure asset configuration.

The wider Logstail Academy is built around realistic, SOC-focused training and includes role-based learning paths and hands-on defensive exercises.

Training aligned with an isolation programme should cover:

• The difference between IT and OT priorities
• Identification of vital operational systems
• OT architecture and segmentation
• Industrial protocols and expected traffic
• Remote-access risks
• Safe handling of legacy systems
• SIEM investigation and alert triage
• Escalation and isolation decision-making
• Manual operating procedures
• Removable-media security
• Evidence preservation
• Safe restoration and reconnection

The best isolation plan is one that engineers, operators, analysts, and leadership have already practised together.

A practical CI Fortify readiness checklist

Critical infrastructure organisations can use the following questions to assess their current maturity.

Vital systems

• Have we identified the minimum systems required to provide the critical service?
• Have we included supporting infrastructure and operational dependencies?
• Do we know the minimum service level required by critical customers?

Connectivity

• Do we maintain an accurate view of every connection into and out of the vital environment?
• Are vendor, cloud, carrier, remote-access, and peer-network connections included?
• Does each connection have an owner, purpose, protocol, and recovery requirement?

Architecture

• Are vital systems physically separate from non-vital systems where feasible?
• Which infrastructure remains shared?
• Are carrier and third-party networks treated as untrusted?
• Are critical links protected using dedicated, appropriately managed encryption?

Dependencies

• Can essential authentication, DNS, time, backup, engineering, and monitoring functions operate locally?
• What will fail immediately after isolation?
• Which manual procedures are required?

Response planning

• Do we have graduated isolation stages?
• Are trigger criteria documented?
• Is decision authority clear?
• Are external partners and critical customers included in communications planning?

Testing

• Have we technically tested full isolation of all vital systems?
• Have we tested prolonged operation?
• Are plans available offline?
• Have we tested safe reconnection?

Monitoring

• Can we detect route, adjacency, firewall, and configuration changes?
• Can we identify unexpected traffic crossing isolation boundaries?
• Does monitoring remain available while the environment is disconnected?
• Are alerts linked to approved response workflows?

People

• Have SOC, IT, OT, engineering, safety, and executive teams exercised together?
• Do responders understand the physical consequences of cyber actions?
• Can the organisation operate when key external specialists are unavailable?

From architecture to resilience

CI Fortify makes an essential point: resilience depends on the ability to continue operating under degraded and hostile conditions.

For OT environments, isolation is not simply a switch that defenders activate during an emergency. It is an engineered operating mode.

Organisations must know what is vital, understand every dependency, establish credible isolation points, define graduated actions, protect the management plane, practise manual procedures, and continuously verify that prohibited connectivity has not returned.

Logstail’s monitoring, automation, visibility, exposure-management, and training capabilities can support the security-operations and workforce components surrounding that strategy.

AICOT extends this direction toward OT-native analytics, protocol awareness, anomaly detection, and AI-assisted defence designed for the realities of industrial environments.

Together, architecture, monitoring, automation, OT-specific analysis, and trained personnel can help critical infrastructure operators move beyond the assumption of a permanent air gap and toward a testable, measurable, and operationally sustainable cyber-resilience capability.

Explore further

• Read the official CI Fortify advice for isolating vital systems.
• Explore the Logstail cybersecurity product portfolio.
• Build practical industrial cybersecurity knowledge through the Logstail Academy OT and ICS learning path.
• Learn about the EU-funded AICOT project and its OT-native, AI-driven cybersecurity objectives. Follow the project on LinkedIn and X for project updates and practical insights into AI-driven OT cybersecurity.

Contact Our Experts  or Sign Up for Free