You're staring at a network diagram with hundreds of interconnected systems. Somewhere in that mesh, a handful of systems keep the lights on, the water flowing, or the trains running. The question isn't whether you should isolate them. It's when, how completely, and at what operational cost.
The joint guidance from CISA, ASD's ACSC, and the FBI on isolating vital operational technology and enabling systems forces a decision many risk managers have postponed: do you build isolation capabilities now while operations are stable, or wait until a disruption forces your hand?
This isn't a theoretical exercise. Your choice determines whether your organization maintains essential services during a cyber incident or scrambles to separate systems while under attack.
The Decision You're Facing
You need to determine your isolation posture for critical operational technology and enabling systems. This breaks into three distinct paths:
Pre-positioned isolation: Build and test separation capabilities now, ready to activate during incidents.
Crisis-triggered isolation: Maintain current architecture and separate systems only when a threat materializes.
Continuous segmentation: Operate critical systems in permanent isolation from enterprise networks.
Each path carries different implementation costs, operational constraints, and risk profiles. The wrong choice doesn't just waste budget. It determines whether you can execute a controlled isolation during an incident or attempt emergency surgery on live systems.
Key Factors That Affect Your Choice
Regulatory obligations shape your baseline. If you operate under NERC CIP, you already face mandatory separation requirements for bulk electric systems. NIST SP 800-82 guidance for industrial control systems recommends logical or physical separation from enterprise networks. Your compliance baseline may eliminate certain options before you start the analysis.
System interdependencies define feasibility. Map every connection between your vital systems and the rest of your environment. This isn't limited to network cables. Consider shared authentication systems, centralized logging, patch management servers, and backup infrastructure. If your operational technology relies on Active Directory controllers that also serve the corporate network, you're looking at complex separation points that affect both paths.
Recovery time objectives drive urgency. How long can you operate without external connectivity before essential services degrade? If your water treatment facility needs external lab results within four hours, or your power distribution depends on real-time weather data, permanent isolation may not be viable. But if you can operate autonomously for days or weeks, continuous segmentation becomes practical.
Threat landscape determines your timeline. Organizations facing active nation-state targeting or operating in geopolitically sensitive regions can't afford to wait. If your threat intelligence shows reconnaissance activity or you're in a sector experiencing sustained campaigns, pre-positioned isolation moves from prudent to urgent.
Path A: Pre-Positioned Isolation (Build Now, Activate on Demand)
Choose this path when you need isolation capabilities ready but can't accept the operational constraints of permanent separation.
You're designing a system that operates normally connected but can separate cleanly when needed. This means identifying every connection point, building alternative paths for critical dependencies, and testing the transition repeatedly.
When this fits: Your vital systems require regular interaction with enterprise networks for updates, monitoring, or data exchange, but you face elevated threats that justify preparation costs. You operate in a sector where peer organizations have experienced disruptive incidents but you haven't been directly targeted yet.
What you're building: Document every network path, authentication dependency, and data flow between vital systems and other networks. For each connection, create either a separation mechanism (firewall rules you can activate, physical switches you can throw) or an alternative path (local authentication, cached data, manual processes). Test the full isolation quarterly, not annually. If you can't activate isolation in under an hour, you don't have pre-positioned capabilities; you have an untested plan.
The catch: Pre-positioned isolation requires ongoing maintenance. Every system change, every new integration, every patch cycle potentially creates new dependencies. You need change control processes that explicitly evaluate isolation impact. Budget for this perpetually, not as a one-time project.
Path B: Crisis-Triggered Isolation (Separate Under Duress)
Choose this path when your risk assessment doesn't justify pre-positioning costs, but you need documented procedures for emergency separation.
You're accepting that isolation will happen during an active incident, with all the chaos that implies. Your preparation focuses on understanding separation points and having runbooks ready, not on pre-built capabilities.
When this fits: You operate systems that aren't facing imminent threats, your regulatory environment doesn't mandate separation, and your operational tempo makes frequent isolation testing impractical. You're balancing security investment across multiple priorities and can't dedicate resources to capabilities you might never activate.
What you're building: Create detailed network diagrams showing every connection between vital systems and other networks. Document the sequence of steps to sever each connection, including who has authority to make the decision, who executes the technical steps, and what operational impacts result. Identify which systems can tolerate hard shutdowns versus graceful disconnections.
The reality check: Crisis-triggered isolation means making irreversible decisions under pressure with incomplete information. You're betting that when the moment comes, you'll correctly identify which systems to isolate, execute separation without causing additional damage, and maintain critical operations while cut off. Many organizations discover during incidents that their vital systems have undocumented dependencies they can't quickly replace.
Path C: Continuous Segmentation (Permanent Isolation)
Choose this path when your vital systems can operate autonomously and your threat profile justifies accepting operational constraints.
You're building an architecture where critical operational technology never touches enterprise networks. Updates happen through controlled, unidirectional data flows or manual processes. Monitoring uses separate infrastructure. This is the most secure option and the most operationally expensive.
When this fits: You operate high-consequence systems where a successful attack could cause physical damage, loss of life, or cascading infrastructure failures. Your regulatory obligations explicitly require separation (like certain NERC CIP requirements). You've experienced previous incidents that demonstrated the risk of connected systems.
What you're building: Separate network infrastructure, dedicated authentication systems, isolated monitoring and logging, and manual or unidirectional update processes. Plan for duplicate systems where vital operations require capabilities that normally come from enterprise networks. Budget for significantly higher operational costs, because every task that was automated across your environment now requires special handling for isolated systems.
The operational cost: Your IT team will maintain two parallel infrastructures. Software updates that happen automatically elsewhere require manual intervention. Troubleshooting loses centralized visibility. New capabilities available to the rest of your organization may not reach isolated systems for months or years. You're trading operational agility for security assurance.
Summary Matrix
| Decision Factor | Pre-Positioned | Crisis-Triggered | Continuous Segmentation |
|---|---|---|---|
| Activation time | Minutes to hours | Hours to days | Always active |
| Normal operations impact | Minimal | None | Significant |
| Implementation cost | High initial, medium ongoing | Low initial, low ongoing | Very high initial, high ongoing |
| Threat tolerance | Medium-term preparation | Accepts exposure until crisis | Minimal exposure |
| Testing requirement | Quarterly activation drills | Annual tabletop exercises | Continuous validation |
| Regulatory fit | Satisfies most frameworks | May not meet sector-specific requirements | Exceeds most requirements |
| Operational complexity | Moderate | Low until activation | High perpetually |
| Best for | Elevated but not imminent threats | Lower-risk environments | High-consequence systems |
The guidance from CISA, ASD's ACSC, and the FBI exists because waiting until crisis forces isolation has failed repeatedly. But that doesn't mean every organization needs the same answer. Your path depends on the specific systems you're protecting, the threats you face, and the operational constraints you can accept.
What you can't do is avoid the decision. Map your critical systems, understand their dependencies, and choose your isolation strategy while you still have time to build it properly.
