Isolating Vital Systems: From Connection Inventory to Separation Points

Introduction

Ask an OT team how fast they could unplug the corporate link. Most have an answer. Ask what still works an hour later, and the room goes quiet.

The second question is the one that matters. Some intruders sit inside critical networks for years without doing anything obvious, waiting for a moment when that access is worth spending. Others move fast and loudly and encrypt everything by Friday. Either way the defender ends up in the same place: needing to cut the paths into the systems that keep the service running and needing the service to survive the cut.

It changes how an incident feels, too. In a flat network, stopping the attack and staying open fight each other. Cut enough to stop the spread and you take out the business. Leave it connected and the intruder keeps moving. When the vital environment already stands on its own, that fight goes away. You can act hard on the corporate side without touching the plant.

Getting there is ordinary engineering work. Find out what is connected. Remove what nobody needs. Turn the few connections that remain into points you can close on purpose.

Core concepts

Vital systems are the smallest set of systems and networks that deliver the critical service. Not everything the OT team owns, and usually a shorter list than people expect.

Critical customers are whoever depends on that service. Write the target down in the units the operators already use: megawatts at a stated quality, gallons per day. That number is what isolation has to protect.

Inside OT, group hosts by how much damage their failure causes and how exposed they are, rather than by site or vendor. That grouping is what tells you where a boundary belongs.

Separation and isolation sound alike but are not. Separation is about hardware: no switch, router or hypervisor carries OT and non-OT traffic at the same time. Isolation is what you can do with that hardware when something goes wrong, which is cut the links and keep running.

Architecture and workflow

1. Identify vital systems and networks.
2. Identify critical customers.
3. Group hosts by criticality and trust.
4. Map every connection, mark the isolation points.
5. Build those separation and isolation points.
6. Write the plan, then test it.

Step four is the heavy one, and the one teams skip, because drawing a zone diagram is easier than writing an honest list of what talks to what. Work through corporate systems, vendor remote access both routine and emergency, contractor and MSP paths, internet, cloud services, and links to peer operators such as neighbouring utilities and dispatch. For each one, write down who owns it at both ends, what protocol runs over it, how fast it has to come back after a failure, and what it crosses once it leaves your own cable: carrier circuit, radio, mobile, satellite, Wi-Fi.

Inventories usually miss the same three things. Connections nobody planned, like vendor access opened for a cutover, or a firewall rule added at 3am during an incident and never removed. Logins, because most inventories record traffic and forget accounts, so nobody notices who can sign in on both sides. And dependencies. The useful question for each entry is plain: does the vital system actually need this, or is it here because it has always been here? Anything in the second group can be deleted, and deleting it is the cheapest security work you will ever do.

The list then has to stay alive. Tie it to change management and check it after any significant change, because an inventory you cannot confirm this quarter turns the isolation plan into a guess.

Isolation happens in stages rather than in one move. Each stage removes one kind of access, so the disruption grows with the threat instead of landing all at once.

Components and configuration

Isolation breaks on dependencies long before it breaks on cables. Active Directory, DNS, DHCP, PKI, time, backup, hypervisors and shared storage all need a copy living inside the OT boundary. For each one, choose deliberately: run it locally, feed it in through a controlled point, or accept the dependency with your eyes open. The bad outcome is finding out it was there when it breaks.

Use your own cable where you can: dedicated fibre pairs, dedicated CWDM wavelengths. Once a carrier is in the path, assume the carrier is not trustworthy. MACsec for Layer 2 services, IPsec, GETVPN or DMVPN for Layer 3, and always on a separate device rather than the encryption built into the OT gear. The interface facing the carrier should carry tunnel traffic and nothing else.

Direction matters as much as volume. The OT side can send logs, metrics and status outward without accepting connections coming back the other way. Anything that does need to come in should be narrow, authenticated and logged, and should exist because a named system needs it.

Then there is the route intruders actually take. Most serious break-ins run on stolen credentials and management tools rather than clever exploits. Nobody needs to attack the PLC if they can log in as the engineer who configures it. All the segmentation in the world does nothing if one laptop reaches both sides, or the same admin account works in both places.

So split administration the same way you split traffic. Use the dedicated management ports if the hardware has them, and a locked-down data port if it does not. Keep management on an out-of-band network and administer from a workstation used for nothing else, with accounts that only work on one side of the boundary. Vendor access gets the same treatment: switched on for a job, switched off after it. And where VLANs or access lists are doing the separating, a device configuration is the only thing holding the line, so anyone who reaches the management plane can undo the isolation without touching a cable.

Practical examples

Here is what failure usually looks like. A site pulls the corporate link at 02:10 as a planned test. Half an hour in, everything looks fine. The historian is writing, alarms are quiet, the supervisor signs it off and goes back to work.

At 03:40 two HMIs start showing stale tags. Nothing crashed, nothing alarmed. The screens just quietly stopped telling the truth.

Two causes, neither of them on the connection map. The historian was checking certificates against a CA on the corporate side, so those sessions failed once the cached copy expired. And the OT clock was following a corporate NTP server through a static route added during a migration years earlier, so when the clock drifted, timestamps stopped lining up. Both were quick fixes, and neither could be found on paper. The example is made up, but the shape is real: isolation rarely fails at the moment you disconnect, it fails ninety minutes later on something nobody drew.

Common issues and troubleshooting

Routing is the quietest way it goes wrong. Send route and neighbour changes to a SIEM that lives on site, and raise an alert when a prefix turns up where it should not. Run reachability tests in both directions, and alert when a test that is meant to fail starts passing.

An isolation point nobody has tested is a guess. Rules drift, exceptions pile up, and a wide allow rule written to get a deployment out the door stays long after the deployment is finished. Good tests ask plain questions. From a compromised PC on the corporate side, can anything reach the OT network? Can it log in? Can it open a management interface? Is there a way around the boundary that nobody is watching, and would anyone see the attempt in time to act?

Being isolated has a price of its own. Patching slows down and you lose some outside visibility. USB drives become the way things move across the gap, and the PC used to scan them stops getting updates too, so it gets weaker the longer you stay cut off. Data diodes can keep a few flows alive, but a badly designed one that drops traffic it was meant to pass will hurt operations rather than protect them.

Best practices

• Test all the vital systems together. Testing one at a time hides the dependencies.
• Keep a printed copy of the plan. The systems holding it may be the ones you switched off.
• Decide the trigger for each stage in advance and put it in the incident response plan.
• Separate administration as carefully as traffic: dedicated workstations, accounts scoped to one side, vendor access that expires.
• VLANs do not separate security domains, and MPLS is not segregation.
• SD-WAN and SASE give you separation on paper. Physical separation gives it to you in copper and glass.
• Keep the allowed path usable. If the safe route is slow, people build their own.

Summary

• Write the vital systems list first.
• Separation is hardware. Isolation is what you can do with it.
• Record every connection: owner, protocol, recovery time, what it crosses. Delete what nobody needs.
• Run AD, DNS, PKI and time inside the OT boundary.
• Your own cable, or your own encryptors. Out-of-band management either way.
• Admin paths and admin accounts stop at the boundary.
• Cut in stages, with the trigger for each one agreed in advance.
• Test everything at once, and test it the way an attacker would.

References

Australian Signals Directorate's Australian Cyber Security Centre, CI Fortify — Advice for isolating vital systems, 28 July 2026. Published jointly with CISA, the FBI, NCSC-UK, the Canadian Centre for Cyber Security and New Zealand's NCSC. https://www.cyber.gov.au/sites/default/files/2026-07/CI%20Fortify%20-%20Advice%20for%20isolating%20vital%20systems.pdf