ICS network security. Secure the control network without stopping the process.
ICS network security means segmenting, monitoring and controlling access to an industrial control network. Done right, it never interrupts the process the network carries.
Last updated:
An ICS network carries the traffic that runs a physical process, so the usual IT playbook inverts: availability comes first, a scan can stop a line, and a patch window may not exist.
Securing one comes down to four moves:
- Segment it, so a compromised workstation cannot reach a controller
- Control access by identity rather than by IP, so every session is attributable
- See the traffic, using passive capture rather than active probing
- Record what happened, so an incident or an audit has evidence
Trout Access Gate does all four in front of the equipment, with no agent on a PLC, no re-IPing, and no production downtime.
How an ICS network differs from IT.
An ICS network connects PLCs, RTUs, HMIs, engineering workstations, historians and safety systems. It looks like an Ethernet network and behaves nothing like one, because four properties of the process leak into the network design.
Availability outranks confidentiality
In IT, you take a service down to fix it. Here, downtime is the incident. A control loop that misses its scan cycle can trip a line, spoil a batch, or move a process toward an unsafe state. So judge every control on what it does when it fails, as well as on what it blocks.
The protocols assume a trusted wire
Modbus/TCP on port 502, DNP3 on 20000, OPC UA on 4840, S7comm on 102 and EtherNet/IP on 44818 were designed for an isolated cable run. Most carry no authentication and no encryption, so anything that can reach the port can issue a command.
The assets cannot host a control
A twenty-year-old controller cannot run an agent, cannot be patched during production, and often cannot survive an active vulnerability scan. Whatever protects it has to live somewhere else, in front of it.
Timing is part of the specification
A PLC scan cycle that normally finishes in 10ms and spikes to 50ms after a network change causes control instability and missed readings before it causes any alert. Latency is a safety property here, not a performance metric, so anything placed in the path has to be measured against it.
Five design mistakes that weaken ICS networks.
Most control networks are not attacked through a clever exploit. They are attacked through a design decision that was reasonable when the plant was commissioned and was never revisited.
| Mistake | What it costs you | What to do instead |
|---|---|---|
| One flat network | A single compromised engineering workstation reaches every PLC, HMI and historian on the floor. | Segment by function and criticality, not by switch closet. Start with the assets whose loss stops production. |
| Legacy assets treated as accepted risk | Unpatchable devices sit on the same broadcast domain as everything else, and the risk register says so in writing. | Put a compensating control in front of the asset. Auditors and cyber insurers accept a documented control, not an accepted risk. |
| Remote access bolted on | A vendor VPN drops a third party into the OT network with broad reach and no per-command record. | Broker vendor sessions through a proxy that is scoped to one asset, one protocol and one time window. See OT remote access. |
| Security designed for a static plant | Every new line, cell or acquired site needs a VLAN redesign, so the security model is skipped to hit the schedule. | Choose enforcement that adds assets without re-IPing or re-cabling, so growth does not create exceptions. |
| Visibility bought as a scan | An active scan meant to find assets crashes a controller, and scanning is banned for the next five years. | Discover passively from traffic already on the wire. Reserve active probing for a lab or a maintenance window. |
ICS network segmentation: where boundaries go.
Segmentation is the highest-value control on an ICS network and the one most often deferred, because the classical version of it means a network redesign. It helps to separate the reference model from the enforcement mechanism.
The reference model: zones and conduits
IEC 62443 groups assets with a shared security requirement into a zone, and calls every permitted path between zones a conduit. The Purdue model gives you the classical levels, and the industrial DMZ gives you the broker between the plant and the enterprise. This is the vocabulary an auditor expects, and the map you draw before you buy anything. See zones and conduits in practice.
Why VLANs stop being enough
A VLAN separates broadcast traffic. It does not decide who may reach a specific controller, and it does not record what they did once they got there. Two devices in the same VLAN are mutually reachable by design, which is exactly the condition that lets one infected workstation walk the floor.
Microsegmentation without a redesign
The practical objection to segmentation is that it means re-IPing a running plant. It does not have to. An on-premise proxy placed beside the network can take over the traffic to a given asset or subnet, so a boundary appears where there was none, without changing addresses, rewiring, or stopping production. See OT microsegmentation.
Segment the path, not only the perimeter
Most real intrusions arrive through an authorised path: a vendor session, an engineering workstation, a remote support tool. Boundaries only help if the path through them is itself brokered, authenticated per user, and scoped per command.
ICS security monitoring without touching the process.
You cannot defend traffic you cannot see. ICS security monitoring has to watch the control network continuously, and the obvious way to see it, scanning, is the one thing an ICS network cannot safely absorb. Passive and active approaches fail in different ways, so most plants need both, applied in different places.
| Dimension | Passive monitoring | Active monitoring |
|---|---|---|
| Method | Reads a copy of traffic from a SPAN port or TAP | Sends probes and queries to devices |
| Risk to the process | None. It never puts a packet on the control network | Real. Probes have crashed PLCs and RTUs in production |
| What it finds | Assets that talk, protocols in use, flows, anomalies against a baseline | Silent assets, firmware versions, misconfigurations, open ports |
| Blind spot | A device that never transmits is invisible | Cannot run continuously in production |
| Where to use it | Continuously, everywhere, as the default | In a lab, on a test bench, or inside a maintenance window |
Once traffic is visible, the useful signals are boring on purpose: a new pair of endpoints that never spoke before, a write to a register that is normally read-only, an Modbus function code the site has never used, a session outside working hours. Flow records (NetFlow and IPFIX) are enough to establish a baseline and to spot volume, path and latency changes. Deep packet inspection is what tells you which command was actually sent. Baseline first: an alert that fires without a normal to compare against is noise, and noise on an OT network gets muted within a week.
- Establish a baseline before you set a single threshold. Two weeks of normal production is the minimum useful window, and it has to include a shift change and a weekend.
- Watch latency as a security signal, not just a performance one. A scan cycle that drifts from 10ms to 50ms after a change tells you something entered the path.
- Send the events somewhere that keeps them. A SIEM feed turns a monitoring tool into evidence you can produce a year later.
- Tie every flow to a person where you can. A flow record identifies a machine. An access record identifies who was sitting at it, which is the difference between an alert and an investigation.
What a defensible ICS network looks like.
A reference architecture is worth having because it makes the same decisions repeatable across sites. The four layers below are the minimum that survives an audit and an incident.
| Layer | Purpose | How it is built without downtime |
|---|---|---|
| Boundary | Separate the enterprise from the plant, and the plant from each critical cell. | An industrial DMZ at the top, then per-cell boundaries created by an on-premise proxy placed beside the existing network, with no re-IPing. |
| Access | Decide who may reach which asset, over which protocol, and for how long. | Identity-bound sessions tied to Active Directory or Entra ID, with MFA enforced at the network layer for devices that cannot do it themselves. |
| Observation | Know what is on the network and what it is doing. | Passive discovery and flow capture from traffic already in the path, exported to the SIEM the security team already runs. |
| Evidence | Prove after the fact who did what. | Tamper-evident session records: user, asset, protocol, commands, duration, retained for the period your regulator names. |
Add controls without a single point of failure.
When a control sits in the path of production traffic, its uptime becomes the plant's uptime. So the way you deploy it has to protect availability.
- Deploy beside the network first, then steer traffic. Put the enforcement point in place with no impact, verify it sees what you expect, then move assets behind it one at a time, or full subnets when you are ready.
- Run it with failover. Redundant units with automatic failover mean one fault never stops the process. Test the failover on a schedule, not on the day it is needed.
- Give operators a documented break-glass path, and log the break-glass itself. An undocumented bypass will be created under pressure anyway; a designed one leaves a record.
- Measure the latency you add, at commissioning and after every change. Publish the number to the controls engineers. Trust in the control depends on it.
- Keep enforcement local. A control that depends on a cloud service to authorise a session fails when the link does, which is the moment you most need the plant to keep running.
One appliance enforces all four controls.
Trout Access Gate is a physical appliance that puts compute on the wire, next to the industrial assets. It plugs into the existing LAN, discovers what is there, and enforces the four controls this page describes. Nothing is installed on any equipment, nothing is rewired, and production does not stop.
01Discover
Learn the assets and flows passively from the traffic already on the wire, so an inventory exists before any change is made.
02Segment
Create boundaries around assets and subnets by taking over their traffic, with no VLAN redesign and no new addresses.
03Authenticate
Bind every session to a named user through your directory, with MFA at the network layer for controllers that cannot authenticate anyone themselves.
04Record
Keep a tamper-evident record of who connected, to which asset, over which protocol, and what commands ran.
Because the compute sits on site and in the path, the same appliance can also run the services that used to justify opening a hole in the network: protocol gateways, DNS and NTP, file transfer, a historian or a dashboard, next to the assets rather than across a boundary.
ICS security best practices, in order.
Run these in sequence. Each step is useful on its own, and each one makes the next cheaper.
| # | Action | What good looks like |
|---|---|---|
| 01 | Inventory what is actually on the network | A passive list of every device, protocol and flow, including the assets nobody remembered were connected. |
| 02 | Draw zones and conduits | Assets grouped by security requirement, every permitted path named and justified, in IEC 62443 vocabulary. |
| 03 | Close the flat network around your crown jewels | The assets whose loss stops production sit behind a boundary, before you attempt a site-wide redesign. |
| 04 | Broker every remote and vendor session | The VPN ends at the gate, with no standing route into the OT network. Sessions are scoped per asset, per protocol and time-boxed. |
| 05 | Bind access to identity | Every session maps to a named person in your directory, with MFA, including sessions to devices that support neither. |
| 06 | Baseline the traffic | Two weeks of normal production, covering a shift change and a weekend, before any threshold is set. |
| 07 | Export events to the SIEM | Access and flow events land in the tool the security team already watches, with retention that matches your regulator. |
| 08 | Prove the failure mode | Failover tested, break-glass documented and logged, added latency measured and published to the controls team. |
What the standards ask for.
The frameworks that apply to industrial networks converge on the same four controls, with different names. This is what maps to what.
| Framework | What it asks of the network | The control that satisfies it |
|---|---|---|
| IEC 62443 | Assets grouped into zones with defined conduits, and access restricted at each boundary. | Segmentation plus brokered, identity-bound access at every conduit. |
| NIST SP 800-82r3 | Compensating controls where a device cannot host a control of its own. | An in-path proxy providing authentication, least privilege and logging for unpatchable assets. |
| TSA pipeline security directives | IT and OT segmentation, access control, continuous monitoring and incident reporting for critical pipeline owners. | Per-session records that make an incident report factual rather than reconstructed. |
| NERC CIP | Interactive remote access routed through an Intermediate System, with MFA and session records. | The proxy is the Intermediate System, and it records every session. See NERC CIP. |
| CMMC and NIST 800-171 | Boundary protection and audit records covering specialized OT assets. | A defined enclave boundary plus retained session evidence. See CMMC for OT. |
What to do this week.
- Run a passive inventory and count how many devices on the control network nobody expected to find.
- List every path a third party can take into the OT network today, and how many of them produce a per-command record.
- Pick the one asset whose loss stops production, and put a boundary in front of it before attempting anything site-wide.
- Ask your monitoring vendor what happens to a PLC if their tool probes it. If the answer is unclear, keep it passive.
Common questions about ICS network security.
agents installed on your controllers
An ICS network is the network that connects the equipment running a physical process: PLCs and RTUs that drive machines, HMIs that operators use, engineering workstations that program the controllers, historians that store process data, and safety systems. It usually runs on standard Ethernet, but it carries industrial protocols such as Modbus/TCP, EtherNet/IP, S7comm, DNP3 and OPC UA, and it is built for timing and uptime rather than for security.
ICS network security is the practice of protecting the network that connects industrial control systems: PLCs, RTUs, HMIs, engineering workstations, historians and safety systems. It differs from IT network security in three ways. Availability comes first, most control protocols carry no authentication, and the assets themselves usually cannot host an agent or be patched. The controls therefore live in front of the equipment rather than on it: segmentation, identity-bound access, passive visibility and session recording.
ICS is the umbrella term for industrial control systems. SCADA is one architecture within it, used where assets are spread across a wide geography such as a pipeline, a water district or a grid. The security problems overlap heavily, but SCADA adds the risk of long-haul links and remote sites with no staff, so brokered remote access and link resilience matter more. Everything on this page applies to both. See ICS vs SCADA security for the full comparison.
Draw zones and conduits first, then create the boundaries with an on-premise proxy placed beside the existing network rather than by re-addressing it. The appliance takes over traffic to a chosen asset or subnet, so a boundary appears where there was none, with no new IP plan, no rewiring, and no stoppage. Move assets behind it one at a time, or a full subnet at once when you are confident.
Passive monitoring is the default because it never puts a packet on the control network, so it cannot disturb a controller. Active probing finds things passive monitoring cannot, such as a silent device or a firmware version. But it has crashed PLCs in production, so it belongs in a lab or a maintenance window. Most plants run passive continuously and active rarely and deliberately.
No. A VLAN separates broadcast traffic, but every device inside one remains mutually reachable, and a VLAN records nothing about who connected to what. It is a useful traffic-engineering boundary and a weak security boundary. The control that closes the gap is per-user, per-asset, per-command access with a session record.
You do not secure it on the device. You place a compensating control in front of it. That is a proxy that authenticates the user, allows only the commands that user needs, keeps the controller off the flat network, and records the session. Both IEC 62443 and NIST SP 800-82r3 accept this pattern, and it is what auditors and cyber insurers expect in place of an accepted risk. See PLC security.