For more than 20 years, OT environments have been dependent on patches as their primary control. The big challenge however has always been the patching cycle. And that challenge has become bigger and bigger at an increasingly rapid pace.
The race is already over
Two timelines have been moving in opposite directions for a decade, and they have now separated far enough that the argument is settled.
On one side, attacker speed. Unit 42's most recent incident response reporting, drawn from more than 750 major engagements across more than 50 countries, found that the fastest quarter of intrusions reached data exfiltration in roughly 72 minutes, four times faster than the year before. Vulnerability scanning is now automated within minutes of a CVE becoming public. In a controlled laboratory simulation, an AI-driven agent ran a complete ransomware chain from initial compromise to exfiltration in 25 minutes.
On the other side, your patch cadence. A controller commissioned in 2011 with a twenty-year design life. A vendor that certifies firmware on its own schedule, sometimes never. A maintenance window that opens twice a year. A safety case that has to be revalidated before anything is touched. None of that is negligence. It is what it means to run a plant where the wrong change hurts someone.
You are not going to win a speed contest against automation with a process that is governed by a safety review. Stop planning as though you might.
The expiry date has come and gone for network segmentation as a compensating control
For twenty years the industry has described network segmentation in OT as a compensating control: the thing you put in place while you wait for the patch that will properly fix the problem.
That description is now obsolete. If the patch will not arrive inside the attacker's window, and across large parts of an industrial estate it will never arrive at all, then containment is not compensating for anything. Containment is the control. Everything else in your program is compensating for the fact that you have not contained.
This is the Zero Trust argument applied to an environment that has always been treated as an exception: assume compromise, verify explicitly, keep the blast radius small, and inspect the traffic you have been calling internal because it happens to be behind a firewall.
The uncomfortable implication is a budget one. A compensating control gets project funding once. A primary control needs an operating budget, an owner, and a place in the org chart, forever.
What operating segmentation actually requires
Where most organizations do have a segmentation drawing for their OT environment, far fewer have it actually implemented. The gap between them is where the next incident is going to happen. Closing that gap is less about technology than most vendors would like you to believe.
Four things are needed to turn segmentation from a project into a control, none of which are a product:
Control 01 · Inventory
A living inventory. You cannot write a policy for a device you cannot name. In OT this is harder than in IT, because the device will not run an agent, may not answer a scan, and may fall over if you scan it wrong. Passive identification from the traffic itself is usually the only safe route, and it needs to run continuously rather than as a one-off assessment, because the estate changes underneath you.
Control 02 · Protect Surface
A defined unit of protection. This is where the Protect Surface does the work. A Protect Surface is the smallest thing genuinely worth defending, described in terms of its data, applications, assets and services rather than in terms of a subnet. In an industrial environment it is almost always much smaller and much more specific than a VLAN. The safety instrumented system is one. The historian is another. So is the engineering workstation that can push logic to a controller, which is usually the single most dangerous device on the plant floor and almost never treated that way. Each surface gets its own set of legitimate flows and its own policy, and each one has an owner who can answer questions about it.
Control 03 · Observation
Continuous observation. Once east-west traffic is being inspected, it produces signals, and signals that nobody watches are just storage cost. This is the part that quietly decides whether the program works, because it is also how you detect the drift: the new gateway, the flow that was not in the design, the device that moved.
Control 04 · Ownership
Organizational change. A segmentation project gets funded. An integrator maps the network, designs zones, writes policy, hands over a set of diagrams, and leaves. For about six months the drawings match the plant. Then a line gets retooled. A vendor drops in a remote-access gateway so they can support a machine without flying someone in. A temporary link between two cells is added during a shutdown and never removed. An engineering laptop that was supposed to live in one zone starts appearing in three.
Eighteen months later the policy still enforces something, but it no longer enforces the thing you designed. Nobody notices, because nothing broke. Segmentation fails silently. Unlike a patch, which is either applied or not, a segment can be quietly wrong for years while showing green.
That is the difference between a project and a control. A project has a completion date. A control has a heartbeat.
Be honest about the limits
Anyone who tells you that a network change delivers complete microsegmentation of an industrial cell has not looked closely at what runs on the wire. Real-time and Layer 2 industrial protocols do not behave like IP traffic and are frequently not redirectable through a policy enforcement point at all. Cyclic control traffic is latency-sensitive, so routing it through an inspection point is not always safe. A lot of installed industrial switching hardware cannot do the port-level isolation that finer-grained enforcement depends on, which makes it a hardware replacement rather than a configuration change.
None of this argues against segmentation. It argues for scoping it honestly, starting where the risk actually concentrates, which is normally the IT to OT crossover and remote access rather than the deterministic traffic inside a cell, and never promising the board something the physics will not deliver.
And be honest about the running cost too. Continuous ownership is not free: it means someone's time to watch the signals, tooling to inspect east-west traffic, and a standing line in the budget rather than a one-off project spend.
Where to start
Take one cell or one line and answer three questions. What is actually on this segment. What does it legitimately need to communicate with. What do we lose, in production terms, if it stops.
That gives you your first Protect Surface. Run the resulting policy in monitoring mode long enough to see a full production cycle before you enforce anything, because the fastest way to end an OT security program is to stop a line in week one. Then repeat, and put the surfaces under someone's continuous ownership rather than in a document.
Twelve months from now, the question that determines whether your plant is genuinely more resilient will not be which controls you deployed. It will be whether anyone has looked at them since.
If you don't have the people to keep looking, that is a service someone can run for you.
Not sure where your OT segmentation actually stands versus your drawings? Send us what you have, a diagram, an asset list, a policy export, whatever exists, and we'll tell you honestly where the gaps are and what to fix first.
Get your current setup reviewedFAQ
Why can't patching be the primary control in OT?
Because attacker speed has outpaced the OT patch cycle for good. Unit 42's incident response data shows the fastest quarter of intrusions reaching data exfiltration in roughly 72 minutes, while OT maintenance windows are measured in months or years. A process governed by a safety review cannot win a speed contest against automation.
Is network segmentation still just a compensating control?
No. If the patch will not arrive inside the attacker's window, containment is not compensating for anything, it is the control itself. Everything else in an OT security program is compensating for the fact that containment has not happened.
What is a Protect Surface in an OT context?
The smallest thing genuinely worth defending, described in terms of its data, applications, assets and services rather than a subnet. In an industrial environment this is usually much smaller and more specific than a VLAN, such as a safety instrumented system, a historian, or an engineering workstation that can push logic to a controller.
Can network segmentation fully isolate OT protocols?
No. Real-time and Layer 2 industrial protocols often cannot be redirected through a policy enforcement point, and latency-sensitive cyclic control traffic is not always safe to route through an inspection point. Scope segmentation honestly, starting where risk concentrates: the IT to OT crossover and remote access.
Where should a team start with OT segmentation?
Take one cell or one line and answer what is on it, what it legitimately needs to communicate with, and what is lost in production terms if it stops. Run the resulting policy in monitoring mode through a full production cycle before enforcing anything, then repeat and give each Protect Surface a continuous owner.