OT/ICS Security

An OT/ICS security service protects the equipment that runs a physical process, from the controllers on the line up to the operator consoles. The work covers asset discovery, splitting the network into zones, control over remote access, passive traffic monitoring and a response plan, with controlled security testing as one stage rather than the whole job. Scope follows the process, because a plant values availability and worker safety first.

An OT schedule is built around the plant maintenance calendar, because access to controllers often exists only during a shutdown. Passive discovery and asset inventory run alongside normal production, while network changes and active attempts wait for a service window. Across several halls or distributed sites the job splits into visits, and its length depends on how much time plant engineers can give it.

Duties arising from NIS2 apply to the organisation as a whole, so control systems fall in scope alongside office infrastructure. The rules name no single technical standard; they require risk management, access control, continuity and incident reporting, and the ISA/IEC 62443 standards are commonly used to show those duties are met on the OT side. Sector and organisation size decide whether a plant is in scope at all.

A single plant runs OT security around one network and one maintenance team, so an asset inventory, separation of production traffic from office traffic and control over vendor remote access close most of the risk. A group of factories adds shared zone standards, one set of access rules for integrators and central event collection from sites with uneven levels of automation. Coordination then weighs more than technology, because every plant keeps its own shutdown calendar.

The usual misstep is commissioning OT work without the maintenance and automation engineers who answer for the line. The provider then gets access to the network but not to knowledge about the process, so weaknesses land in a report with nothing said about what fixing them does to production. What follows is a list nobody implements, because every change needs approval from people left out at the start.

Preparation means gathering the documentation the plant already holds: network diagrams, controller lists, configuration backups and a record of remote access granted to integrators and machine builders. Someone from the maintenance team also has to be named, able to explain the process, authorise entry to a control cabinet and confirm the next planned shutdowns. The more of that material exists up front, the less time goes into rebuilding the picture of the network.

An OT audit report is best ordered by process impact rather than by technical severity, because part of the findings close through segmentation without touching a controller. Fixes that need no shutdown, such as removing unused crossings between zones or cleaning up remote service accounts, go first. The rest becomes a work plan tied to specific maintenance dates, together with a decision on who watches for anomalies once the project ends.

Most OT work runs without touching the line, because discovery relies on listening to a copy of network traffic rather than querying controllers. Risk appears with active testing and changes to network configuration, so those are scheduled into a shutdown, a test bench or a configuration copy. The condition is a written agreement stating which methods are allowed and on which devices.

On a small budget the highest return comes from an inventory of the control network and tidy remote access, since neither needs new hardware. Money after that usually goes to separating production traffic from the office network and to configuration backups for controllers, which shorten recovery after a failure. Anomaly monitoring and a full zone design can wait until those basics hold.

A contract for OT work should name the devices and segments in scope, the methods allowed on a running line and the person at the plant who approves every active attempt. It should also set out what happens if the process looks affected: who calls a stop, how contact works outside business hours and who restores a configuration. Continuous monitoring adds alert response times and the route for passing events to the maintenance team.