OT Network Segmentation for Embedded Systems
Many embedded and operational technology devices cannot defend themselves. They run old software, lack authentication, and cannot be patched, yet they control physical processes that must keep running. When the device cannot be hardened, the network has to carry the load, and segmentation is the most effective tool there is. Here is how it protects fragile OT and embedded systems.
When the Device Cannot Be Fixed
A great deal of OT and embedded equipment was built for a trusted network and a long service life. The devices have weak or no authentication, run software that has not been updated in years, and often cannot be patched without halting a process that must not stop. Hardening the device itself is frequently impossible, yet it still has to be protected.
This is the situation segmentation is made for. If you cannot make the device strong, you can control who is allowed to talk to it, and that is what segmentation does. It accepts the device’s weakness as a given and builds the defense into the network around it, often the only practical option for equipment that will remain in service, unpatchable, for a decade or more.
What Segmentation Does
Segmentation divides a network into zones and controls the traffic between them, so a device only receives communication from the systems that legitimately need to reach it. A fragile controller placed in a tightly controlled zone is shielded from the broad exposure that would otherwise let any compromised machine on the network attack it directly.
The effect is to shrink each device’s reachable attack surface to almost nothing. A PLC that historically would answer any device on a flat network instead answers only its supervisory system across a controlled boundary. The device did not change, but who can reach it did, and that alone removes most of the attackers who could have exploited its weaknesses.
Zones and Conduits
The standard model, from ISA/IEC 62443, organizes OT networks into zones, groups of devices with similar security needs, connected by conduits, the controlled pathways between them. Traffic flows between zones only through conduits that enforce what is allowed, turning an implicit free-for-all into an explicit, reviewable policy.
The deeper a zone sits, the more fragile and critical its devices and the tighter its conduits. The control zone, holding the PLCs and controllers that run the physical process, is the most protected, reachable only through narrow conduits carrying only the traffic the process requires. The model makes the protection proportional to the fragility.
The Reference Architecture
The widely used Purdue model layers an industrial network from the physical process at the bottom through control, supervisory, and operations levels up to enterprise IT at the top, with controlled boundaries between layers. Following an established architecture matters because ad-hoc segmentation tends to leak: a documented model makes the intended boundaries explicit, so deviations, a controller reachable from IT, a remote-access path that bypasses the layers, stand out and can be corrected. It is both a design target and an audit reference.
The Critical IT and OT Boundary
The single most important boundary is between enterprise IT and the OT network, because IT is connected to the internet and email and everything that gets compromised first, while OT runs the physical process. A breach of the office network reaching the control system is the path behind many of the most serious industrial incidents.
This boundary deserves the strongest controls: a demilitarized zone between the two, strict firewalling, and ideally no direct path from IT to the control zone at all. Data that IT needs from OT, production figures, historian data, should be pushed to a DMZ that IT reads, rather than letting IT reach into the control network. Keeping the office breach from becoming a process breach is the highest-value thing segmentation does.
Verify What Can Actually Reach What
Segmentation that exists on a diagram but not in reality is common, so it has to be verified by testing what can actually reach what. Scanning from one zone to confirm that only the intended hosts and ports in another are reachable turns the policy from an assumption into a measured fact.
# from the supervisory zone, confirm only the intended control-zone access exists
nmap -sS -p- 10.20.0.0/24 # should show only expected PLC ports, nothing more10.20.0.10 502/tcp open modbus # expected # no other hosts or ports reachable from this zone, so the conduit is enforcing policy
A scan that returns only the expected device and protocol confirms the conduit is doing its job; one that reaches more than it should reveals a gap. This matters because segmentation degrades in predictable ways, a dual-homed engineering laptop that bridges office and control, a temporary firewall rule never removed, a device on the wrong switch, a vendor VPN tunnelling past the zones, and every one of them is invisible on the architecture diagram. Only periodic testing from each zone shows whether the intent survived contact with daily operations.
Remote Access, the Common Weak Point
Remote access is where segmentation most often breaks down. A vendor support connection, an engineer’s remote login, or a convenience VPN can punch straight through the carefully designed zones, giving an outside path to the control network that bypasses the layered defenses entirely, and attackers target exactly these connections. It has to be controlled as rigorously as the architecture it crosses: routed through the DMZ, strongly authenticated, limited in what it can reach, monitored, and disabled when not in use.
Monitor the Boundaries
Segmentation pairs naturally with monitoring the traffic that crosses conduits, because that traffic is constrained and predictable. OT traffic is often far more regular than IT traffic, the same devices exchanging the same protocols on a steady rhythm, which makes anomalies stand out. Watching the boundaries for anything unexpected, an unusual protocol, a new source, a command that should not occur, turns the controlled boundaries into observation points where a deviation is a clear signal rather than noise.
A Worked Example
Picture a water treatment site with PLCs controlling pumps and chemical dosing, a SCADA workstation supervising them, a historian collecting data, and an office network for staff. A flat network would let a phishing email on the office side reach a dosing PLC directly. Segmentation places each system in its own zone, with conduits between:
| Zone | Subnet | What lives there | Conduit |
|---|---|---|---|
| Enterprise IT | 10.0.0.0/24 | Staff PCs, email, internet | None direct to OT; reads historian via DMZ |
| DMZ / historian | 10.10.0.0/24 | Data historian | Push-only from supervisory |
| Supervisory / SCADA | 10.20.0.0/24 | HMI, engineering workstation | Only Modbus to named control hosts |
| Control zone | 10.30.0.0/24 | PLCs and RTUs, most protected | Inbound only, from supervisory |
With this layout, the office breach that used to reach a PLC now stops at the enterprise boundary, because there is no conduit from IT into the control zone, only a one-way push of historian data through the DMZ. The dosing PLC answers only the SCADA workstation, over only the control protocol. The same fragile controller is now reachable by exactly one host instead of the entire network.
Defense in Depth with a Fragile Core
Segmentation is the strongest tool for protecting devices that cannot protect themselves, but it works best as one layer among several: strong IT and OT separation, controlled and monitored remote access, hardening of whatever devices can be hardened, and process-level monitoring as a backstop. For an operator stuck with unpatchable legacy equipment, this layered, network-centric approach is usually the realistic path to acceptable risk, so a single weak controller is no longer a single point of failure for the whole operation.
Where This Fits
Designing and verifying segmentation for OT and embedded environments, and finding the remote-access and drift gaps that undermine it, is specialized work within a facility or product security assessment. If you run fragile devices that the network has to protect, and want your segmentation tested, that is the kind of work we do at Berkner Tech.
