Thinking Beyond Network Segmentation in OT Environments

Network segmentation is the most consistently recommended control in OT cybersecurity, appearing in every framework, anchoring every reference architecture, and serving as the answer most consultants will offer to most questions about OT defense. In many programs, it has taken on the quality of a talisman, with the underlying assumption being that once segmentation is in place — the Purdue Model levels drawn, the firewalls deployed, and the DMZ stood up between enterprise IT and the plant floor — the OT environment can be considered defended. 

Segmentation is necessary, but it is not sufficient, and the incidents that have actually disrupted industrial operations over the past decade have almost all occurred in environments that had segmentation on paper. 

Consider the 2021 ransomware attack on Colonial Pipeline, which forced the shutdown of nearly half the fuel supply on the U.S. East Coast. The company had a segmented architecture separating its IT business systems from its OT pipeline controls, yet when ransomware encrypted the billing systems on the IT side, operators chose to halt pipeline operations anyway because they could not reliably bill customers for fuel they delivered. The segmentation worked exactly as designed in the technical sense, since the malware never crossed into the control systems, and yet the operational impact was indistinguishable from what a direct OT compromise would have produced. 

The failure is rarely the absence of segmentation but rather the assumption that segmentation alone will carry the weight of the entire defensive program. In reality, the dependencies between business operations and physical operations, the trust relationships that cross the boundary, and the human decisions made under pressure all sit outside the firewall rules — and remain capable of producing the very outcomes segmentation was meant to prevent. 

What Colonial revealed about segmentation assumptions 

Colonial Pipeline had an IT/OT boundary. It was not a theoretical boundary. There were firewalls, documented zones, and an architecture that on paper kept the corporate network separate from the control systems. When DarkSide ransomware hit the IT side in May 2021, the OT environment was reportedly not directly infected. And yet the pipeline shut down for six days. 

The reason is instructive. The IT and OT environments were not functionally independent. The billing system, which lived on the IT side, was essential to the commercial operation of the pipeline. Visibility into pipeline status depended on platforms that spanned both environments. The company could not be certain the OT network was clean, because the segmentation between the two had enough legitimate crossings that verifying the boundary’s integrity would take time the operation did not have. Shutting the pipeline down was the safe choice precisely because segmentation, as implemented, did not provide the confidence that the OT network was isolated. 

This is the most common failure mode in real segmentation programs. The architecture shows a boundary. The operating reality shows many small holes in that boundary, each individually justified, each added by a different team at a different time, each with its own access controls and audit procedures. Add them up, and the boundary becomes a membrane. Membranes let things through. 

Vendor remote access and the myth of the sealed perimeter 

The most persistent source of those small holes is vendor remote access. Most OT environments have multiple vendors with legitimate reasons to reach the control systems. Controls engineering support. Turbine monitoring. Variable frequency drive diagnostics. Safety system configuration. Each vendor typically has its own preferred remote access solution, its own credentials, and its own update schedule, and the plant’s security team is often not informed when the vendor’s access profile changes. 

The February 2021 Oldsmar incident, whatever its ultimate cause, illustrated the pattern. Investigators found a water treatment facility in which a remote access tool was installed on operator workstations, reachable from the internet, and shared among multiple users with a common password. The point is not that this was a sophisticated compromise — it was not. The point is that segmentation at Oldsmar, whatever it looked like on a diagram, had been effectively bypassed by a single piece of legitimate software that the operations team had installed for their own convenience. 

A practitioner trained only on reference architectures will look at the diagram and conclude that segmentation is in place. A practitioner trained to ask the right questions will ask what remote access tools are installed on the operator workstations, who put them there, what credentials they use, and what happens to the boundary if any of those credentials are compromised. Those are not architecture questions. They are operational questions, and they require spending time with the operations staff to answer. 

From architecture review to risk quantification 

Recognizing that segmentation is a partial control is the first step. The harder step is putting numbers on what segmentation does not cover, in a way that operations leadership, finance, and the board can act on. This is where a scenario-based risk quantification workshop earns its place — not as a compliance exercise, but as the bridge between the technical reality the security team understands and the investment decisions the business has to make. 

The temptation in these workshops is to model the probability of a technical compromise crossing the boundary. That is the wrong starting point, because the Colonial and Oldsmar incidents demonstrate that the boundary holding is not the same as the operation continuing. The workshop should instead quantify the operational and financial consequences of dependencies that cross the boundary, of decisions made under uncertainty, and of legitimate access paths that bypass segmentation by design. 

Dependency mapping as the foundation 

Before any quantification, the workshop needs to surface the gap between the architecture diagram and operating reality. Participants should walk through every business process that touches both IT and OT, asking which IT systems, if unavailable, would force an operational shutdown even if the OT network itself is clean. Billing, scheduling, customer dispatch, regulatory reporting, inventory management, and product movement tracking are typical candidates. The output is a list of indirect shutdown triggers — IT-side failures that produce OT-side consequences without ever crossing the boundary. 

For each dependency, capture three things: the business function it supports, the maximum tolerable downtime before operations must halt, and whether a manual workaround exists and has been tested recently. Untested workarounds should be treated as nonexistent, because the muscle memory and edge-case handling that make a workaround viable do not survive long periods of disuse. 

Four scenarios worth modeling 

Based on the incidents discussed above and the underlying failure patterns, four scenario archetypes form the minimum starting set. 

The first is the Colonial scenario — IT ransomware forcing OT shutdown. The workshop should model the financial impact of a three, six, and ten-day operational halt triggered not by OT compromise but by loss of confidence in segmentation integrity or loss of essential IT-side business functions. Lost revenue, contractual penalties, regulatory fines, restart costs, and reputational impact all belong in the calculation. The key question is not “what is the probability of ransomware” but rather, given a ransomware event on IT, what is the probability the organization shuts down OT anyway, and what does that cost per day. 

The second is the Oldsmar scenario — vendor or remote access bypass. The workshop should model the impact of an attacker reaching an HMI or engineering workstation through legitimate remote access software that bypasses documented segmentation. Quantification is based on what the attacker could change — setpoints, safety parameters, recipe values — and the consequence range from product loss to safety incident to environmental release. This scenario should be run separately for each major vendor with remote access, since the access profiles and blast radius differ meaningfully across them. 

The third is what might be called the membrane scenario — the cumulative effect of legitimate crossings. The workshop inventories every legitimate crossing of the IT/OT boundary, including historian replication, jump servers, Active Directory trust, patching infrastructure, file transfers, dual-homed engineering workstations, and vendor tunnels. For each, the team estimates the likelihood that a compromise on the IT side propagates through that specific crossing, and the consequence if it does. The aggregate gives a realistic picture of boundary integrity that a single firewall-rule review will miss, and it forces the conversation about which crossings are actually necessary versus which have accumulated by inertia. 

The fourth is the decision-under-pressure scenario. Colonial shut down because operators could not verify the OT network was clean fast enough to keep running. The workshop should model the cost of that uncertainty directly. How long does it take, today, to gain high confidence that OT is uncompromised after an IT incident? If the answer is “we don’t know” or “several days,” the quantified risk is essentially the cost of an operational halt multiplied by the probability of an IT incident that creates verification doubt. This number is often larger than the modeled cost of a direct OT compromise, and it points toward investments in OT visibility and incident response readiness rather than additional perimeter controls. 

Deciding on a defensible quantification method 

The Forrester Wave: Cyber Risk Quantification Solutions, Q2 2025 evaluated the most popular  platforms and methodologies in market today. Through an OT lens, and based on publicly available marketing information from the vendors themselves, the shortlist looks like this: 

• SAFE (Leader) — The telemetry-driven FAIR-CAM heavyweight. Great if you have rich IT security data feeds; less natural for OT, where instrumentation is thinner and controls are often procedural or vendor-managed. 

• Axio (Leader) — OCTAVE Allegro, impact-first. Built for cyber-physical and safety scenarios where frequency data is thin and operations and finance speak the language of consequence. 

• KPMG CRI (Leader) — Guided experience with strong benchmarks. Good for organizations without in-house CRQ expertise; value is bound up with KPMG’s services. 

• Balbix (Strong Performer) — Continuous, asset-driven FAIR quantification. Strong for IT-heavy environments; weaker where OT assets resist active scanning. 

• ThreatConnect (Strong Performer) — Threat-driven CRQ tying loss to attack patterns. Conceptually elegant, but flagged for limited benchmarks. 

• X-Analytics (Contender) — Proprietary model with board-ready outputs; trades transparency for ease. 

• Zscaler (Contender) — Embedded in its zero-trust platform; minimal OT relevance. 

• Kovrr (Contender) — Built for insurers and portfolio analytics, not asset operators. 

• Mastercard Cyber Quant (Contender) — Control-assessment-driven, with IT-oriented integrations. 

If this is the first time you have looked at any of this, the vendor landscape and the methodology debates can feel overwhelming, and the temptation is either to default to whichever platform the consultants recommend or to give up on quantification entirely and fall back to a red-yellow-green heat map.  

Neither is the right move.  

The methodologies sound more complicated than they are, and the underlying logic — what could happen, how often, what would it cost — is something operations and finance teams reason about every day in non-cyber contexts. What is missing is usually the structured practice of applying that reasoning to cyber scenarios, and that is a learnable skill rather than an innate one. A short course on FAIR fundamentals, a workshop facilitated by someone who has run a few of these before, or even a single tabletop exercise using a simplified impact-only model is enough to get past the initial barrier.  

The goal at the start is not a board-ready loss exceedance curve but a shared vocabulary and a first pass at the scenarios that matter. The sophistication comes later, with practice. 

Who needs to be in the room 

The cultural divide between security and control engineers matters as much in this workshop as it does on the plant floor. A risk quantification workshop staffed only by the security team will reproduce the architecture-diagram view of the world, and the numbers it produces will reflect that limitation. To get realistic figures, the room needs control engineers who know the actual remote access situation, operations leadership who know the financial consequence of downtime and the contractual exposure, a finance representative who can validate revenue and penalty figures, and ideally someone from safety and environmental compliance. Vendor management should be consulted on the remote access inventory before the workshop, because the security team’s understanding of vendor access is almost always incomplete. 

Outputs that justify holding the workshop 

A workshop that produces a heat map and adjourns has not done the job. Useful outputs include a ranked list of scenarios by expected annualized loss with explicit ranges, a documented inventory of boundary crossings with associated risk contribution, identification of the top three to five dependencies whose failure would force an operational shutdown regardless of OT integrity, and a list of detection and response capabilities whose absence is driving the largest portion of quantified risk. That last item is what turns the exercise into a defensible investment case rather than a compliance artifact, and it is typically what moves a board to fund the controls that segmentation alone cannot provide. 

Training for the questions the diagram does not ask 

CyberEd.io builds its segmentation training around the reality that architecture diagrams rarely match operating conditions. The simulations include deliberately messy environments, with undocumented vendor connections, dual-homed historians, and legitimate business flows that cross the boundary in ways the reference architecture did not anticipate. Learners practice identifying those crossings before an incident forces them to, and they practice the east-west detection, identity management, and process-aware monitoring that have to sit alongside segmentation for it to function as intended. They also practice translating those technical realities into the kind of quantified scenarios a workshop can act on. 

Segmentation taught as a single-step solution produces practitioners who check the wrong boxes. Segmentation taught as one control among several, tested against Colonial-style and Oldsmar-style scenarios, and connected to a quantification practice that surfaces the business consequences of its limitations, produces practitioners who understand what their boundary will and will not actually stop — and who can explain that distinction to the people writing the checks. 

CyberEd.io helps security and operations teams prepare for the OT risks architecture diagrams do not reveal. Connect with our experts to build practical OT security skills and incident readiness.

References: CISA and FBI, Joint Cybersecurity Advisory: DarkSide Ransomware (May 2021); Dragos, Recommendations Following the Oldsmar Water Treatment Facility Cyber Attack (February 2021); CISA/EPA/MS-ISAC joint advisory on the Oldsmar incident; IEC 62443-3-2 and 62443-3-3; The Open Group, Open FAIR Body of Knowledge; Carnegie Mellon SEI, Introducing OCTAVE Allegro; Forrester, The Forrester Wave: Cyber Risk Quantification Solutions, Q2 2025; vendor methodology documentation from Axio, SAFE, KPMG CRI, Balbix, ThreatConnect, X-Analytics, Zscaler, Kovrr, and Mastercard.