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 in the network around it, which is 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 change alone removes most of the attackers who could have exploited its weaknesses.
Zones and Conduits
The standard model, from the ISA/IEC 62443 standard, organizes OT networks into zones, groups of devices with similar security needs, connected by conduits, the controlled pathways between zones. Traffic flows between zones only through conduits that enforce what is allowed, which turns an implicit free-for-all into an explicit, reviewable policy.
ZONE MODEL (simplified)
[ Enterprise IT ]
| conduit (firewall, tightly filtered)
[ DMZ / data historian ]
| conduit (only specific protocols, one direction)
[ Supervisory / SCADA ]
| conduit (only the control protocol, to named devices)
[ Control zone: PLCs, RTUs ] <- most fragile, most protectedThe 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 specific 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. It gives teams a shared map for deciding what belongs where and how traffic should and should not flow between levels.
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. The architecture is both a design target and an audit reference for finding the gaps that erode segmentation over time.
The Critical IT/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.
Verifying the Segmentation
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/ports reachable from this zone -> conduit is enforcing policy
A scan that returns only the expected device and protocol confirms the conduit is doing its job; a scan that reaches more than it should reveals a gap to close. Periodic verification matters because networks drift, a temporary rule becomes permanent, a new device is misplaced, and the segmentation degrades silently unless someone checks.
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. Attackers target exactly these connections.
Remote access 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. An unmanaged remote-access path is a hole in the segmentation, and securing it is often where the real-world risk in an otherwise well-segmented network actually lives.
Monitoring Across Boundaries
Segmentation pairs naturally with monitoring the traffic that crosses conduits, because that traffic is constrained and predictable. Watching the boundaries for anything unexpected, an unusual protocol, a new source, a command that should not occur, catches both attacks and misconfigurations that have opened a gap.
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. Monitoring at the conduits leverages that regularity, turning the controlled boundaries into observation points where a deviation is a clear signal rather than noise lost in the churn of a busy 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/OT separation, controlled and monitored remote access, hardening of whatever devices can be hardened, and process-level monitoring as a backstop. Each layer compensates for the limits of the others.
For an operator stuck with unpatchable legacy equipment, this layered, network-centric approach is usually the realistic path to acceptable risk. The devices remain fragile, but they sit behind boundaries that keep attackers away, paths that are watched, and a process that is independently monitored, so a single weak controller is no longer a single point of failure for the whole operation.
A Worked Segmentation 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 the PLCs in a control zone, SCADA in a supervisory zone, the historian in a DMZ, and the office in enterprise IT, with conduits between each.
ZONE PLAN (water treatment site) enterprise IT 10.0.0.0/24 staff PCs, email, internet | conduit: none direct to OT; reads historian via DMZ only DMZ / historian 10.10.0.0/24 data push-only from supervisory supervisory/SCADA 10.20.0.0/24 HMI + engineering workstation | conduit: only Modbus to named control-zone hosts control zone 10.30.0.0/24 PLCs, RTUs (most protected)
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.
Common Ways Segmentation Quietly Fails
Segmentation degrades over time in predictable ways, and an assessment looks for each. A dual-homed engineering laptop bridges the office and control networks, defeating the boundary the moment it connects to both. A firewall rule added for a temporary project is never removed. A new device is plugged into the wrong switch. A vendor VPN tunnels straight past the zones for support.
Each of these is invisible on the architecture diagram, which is why segmentation has to be verified by testing what can actually reach what, not by reviewing the design. Periodic scans from each zone, an inventory of every cross-boundary path, and tight control of remote access are what keep the segmentation real. The diagram shows the intent; only testing shows whether the intent survived contact with daily operations.
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.