Separating the control network from everything else
Most control networks were flat when they were built and have been connected to progressively more things since, one reasonable request at a time.
Control system networks were historically isolated, and the isolation was physical: separate cables, separate switches, no route to anywhere else. That is rarely the current situation.
Over years, connections accumulate for good reasons — the historian needs to feed a business report, maintenance needs device diagnostics, a vendor needs remote access, the ERP system needs production figures. Each is justified individually and the aggregate is a control network reachable from the corporate network and, through it, from further afield.
The layered model
The reference architecture used across the industry, reflected in the IEC 62443 series, separates the environment into levels: the enterprise network, a demilitarised zone between enterprise and control, the control network itself, and the field level below it.
Remote-work controls may need to distinguish genuine activity from artificial presence signals. For a related reference, see Monitask mouse jiggler detection software.
Security decisions should also be checked against NIST guidance on operational technology security.
The essential property is that no traffic passes directly between the enterprise network and the control network. Anything that has to cross does so via a system in the intermediate zone, with each side connecting only to that system.
If a workstation on the office network can open a session to a controller, the segmentation is decorative regardless of how the diagram is drawn.
What belongs in the intermediate zone
The systems that both sides need: a replicated historian that the business reads, an update server, a jump host for remote access, an antivirus distribution point.
The pattern is duplication rather than sharing. The control network historian replicates to a copy in the intermediate zone, and business users read the copy. Nobody from the business queries the control network directly.
Zones and conduits within the control network
Segmentation is not only about the boundary with the enterprise. Within the control environment, dividing into zones by function or by unit — with controlled conduits between them — limits how far a problem propagates.
The practical benefit appears during an incident: a malware infection or a broadcast storm confined to one zone is a unit problem rather than a site problem.
Start with an accurate diagram
Most sites cannot produce a current network diagram for their control system, which makes segmentation impossible to assess.
Building one is the first task, and it should be derived from what is actually connected rather than from the design. The usual findings are undocumented connections, devices nobody knew were there, and at least one link that bypasses the intended path entirely.
The connections that appear later
Segmentation degrades through additions. A vendor is given a connection for a support session and it remains. A wireless access point is installed for convenience. A laptop that moves between networks provides a path in a different form.
The controls are procedural: network changes go through the same change process as anything else, temporary connections carry an expiry, and periodic scanning verifies what is actually connected against what should be.
Removable media and portable equipment
Segmentation addresses network paths and not the physical ones. A USB drive or an engineering laptop carried between environments crosses every boundary.
The practical measures are a defined process for transferring files in, scanning on dedicated equipment before transfer, and control over which laptops connect to the control network. These are unpopular and they address a genuinely common transfer route.
Monitoring the boundary
Segmentation that is not monitored degrades silently. Logging at the boundary — what crossed, from where, to where — provides both the detection of unexpected traffic and the record needed after an incident.
For most sites the realistic starting point is firewall logging with periodic review rather than continuous monitoring, which is considerably better than nothing and considerably easier to sustain.
Standards and expectations
The IEC 62443 series provides the reference framework for industrial system security, and sectors frequently have specific regulatory expectations layered on top of it. Which apply depends on jurisdiction and industry.
The practical value of the standard for most sites is as a structure for the assessment rather than as a certification target: it provides a vocabulary and a set of questions that make the conversation with IT and with management coherent.
Assessing what you have before changing it
Segmentation projects that begin with new firewall rules and no prior assessment reliably break something, because the traffic that exists is not the traffic the design assumed.
The sequence that works is to observe first: monitor traffic at the intended boundary, in permissive mode, long enough to see what actually communicates. The result is invariably more than expected and includes connections nobody could account for.
Rules built from observed traffic, with the unexplained flows investigated rather than blocked blindly, produce a segmentation that holds.
Wireless and vendor-supplied equipment
Packaged equipment frequently arrives with its own connectivity: a wireless gateway, a cellular modem, a remote monitoring appliance supplied as part of a compressor or an analyser.
These bypass the site's network architecture entirely and are often unknown to the control systems group, because they were procured as part of a mechanical package.
Making network connectivity a review item in equipment procurement is the preventive measure. Finding what is already installed requires a physical survey, which is worth doing once.
What segmentation does not do
Segmentation limits network paths. It does not address portable media, engineering laptops, insider access, or supply chain compromise in delivered equipment.
Presenting it as the security measure rather than one of several creates a false sense of completeness. It is a foundational control and it needs the others alongside it.
Working with the IT organisation
Control network segmentation sits at a boundary owned by two groups with different priorities, different change cadences and different tolerance for downtime.
Arrangements that work define ownership explicitly: who owns the boundary devices, who may change rules, what notice is required, and what the escalation path is when a change breaks a control function.
The most common failure is an IT-initiated change applied on a normal IT schedule that interrupts a control system dependency, and it is prevented by a change process that spans both, not by better firewalls.
Documenting the architecture as built
A segmentation design document describes the intent. What matters operationally is what is actually configured, and the two diverge through changes made under pressure.
Periodically exporting the actual configuration of boundary devices and comparing it against the design is the check. Differences are either undocumented changes or errors, and both are worth knowing about.