ICS Network Security. Defend the network that cannot be taken down.
ICS network security is the practice of segmenting, monitoring and controlling access to an industrial control network, in a way that never interrupts the process it 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.
What makes an ICS network different from an IT network
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 every control has to be judged on what it does when it fails, not only 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 make an ICS network indefensible
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 the 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 network visibility and monitoring: seeing traffic without touching the process
You cannot defend traffic you cannot see, and the obvious way to see it, scanning, is the one thing an ICS network cannot safely absorb. The two approaches have different failure modes, 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. |
Adding controls without adding a single point of failure
The moment a control sits in the path of production traffic, its uptime becomes the plant's uptime. That is not an argument against in-path enforcement, it is a requirement on how you deploy it.
- 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 enforcement point, four controls
Trout Access Gate is a physical appliance that puts compute on the wire, in the data path, next to the industrial assets. It plugs into the existing LAN, discovers what is there, and enforces the four controls this page describes, without an agent on any equipment, without rewiring, and without production downtime.
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 the order to do them
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 | No standing VPN 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. |
| NIS2 | Risk management, access control and incident reporting across essential entities. | Per-session records that make an incident report factual rather than reconstructed. See NIS2 compliance. |
| 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.
ICS network security questions
agents installed on your controllers
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 because 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: 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.