Why industrial control systems (OT/ICS) are tested differently from IT

In IT an active test is routine. The scanner goes through the addresses, tries to exploit a finding, and when something falls over you restart the service. That approach has no place in industry: an active scan or an exploitation attempt against a live PLC, that is, the programmable controller that runs the production process, can crash it and stop the line. In the wrong place that isn’t a service outage. It is an outage of manufacturing or a risk to the people standing at the machine.

Control units are not built for unexpected traffic. They run for years without a restart, have limited memory, and respond to the commands the process expects of them, not to whatever a scanner sends. An unexpected or overwhelming request can throw them off without a single exploit. So why a scan doesn’t belong on a live device is not a cautious footnote but the default rule.

Specifically, this is about classic vulnerability scanners such as Nessus or OpenVAS. They are designed for an IT network and there they are worth their weight in gold: they go through every port, send a stream of requests and deliberately malformed packets, and assume a stack on the other side that will take the pounding. That way of working is exactly what doesn’t belong in OT. What bothers an industrial device is less one probe than the whole flood it was never built for, so it gets knocked out by the scanning itself, not by some exploit later. The NIST guide to operational technology security warns against active scanning in a live OT network as well. It isn’t a defect of the tool. It is a tool from another world: good on an IT network, not on a production line.

Anyone who simply walks onto the factory floor and scans it like a web server has given away that they have never done OT. Caution here isn’t a limit on the test. It is the condition for the test to happen at all without damage. A test that stops manufacturing isn’t proof of expertise. It is proof of the opposite.

To talk about where to test carefully, you need a map. The Purdue model is a layered arrangement of an industrial network into levels, from office IT at the top through the control systems down to the sensors and actuators at the process itself. It describes where the boundaries between levels should be and where traffic may pass.

The most important one is the boundary between IT and OT. When there is no proper separation between the office network and the control systems, an attacker who has taken over one workstation in the office reaches straight to what runs manufacturing. That missing or leaky segmentation is the first thing we check in OT, before we get to individual devices.

The wired network below that boundary is checked by a separate test. This article stays with the OT layer, but the IT network you cross into OT from meets it from the other side, because the crossing between the two worlds is the most valuable place to check.

Industrial protocols were created at a time when the network was closed and nobody expected an attacker inside it. Modbus and older variants of DNP3 carry commands between the control system and the devices without authentication, so a device obeys anyone who gets into the same segment and speaks the protocol. Whoever is on the network can both intercept a command and spoof one.

It doesn’t mean industry is defenseless by design. The newer variants do think about protection: OPC UA has encryption and authentication, DNP3 has the Secure Authentication extension. It comes down to what actually runs at your site. New and old run side by side, and the weak spot is the oldest layer, the one modernization forgot.

So a test doesn’t start at the devices but at what flows over the network. Passive listening tells you which protocols are running, who talks to whom, and where commands go without authentication, without touching operations at all. Only once it is clear where the weakness sits do we deal with whether and how it can be verified safely.

The basis is passive work. Listening to traffic and analyzing configuration do not intervene in the systems, so operations don’t know about the test. It still reveals the segmentation between zones, the protocols running, and commands without authentication, all without a single active request.

Active steps come up only where they make sense, and only after approval. We plan them into a maintenance window, when the process is shut down or in a mode that can bear the intervention, and we run them in cooperation with your operations team, which keeps a hand on the switch. Where a test or backup environment exists, the risky steps move there. Industrial operations may not have one, and we account for that in advance.

Before every risky step we call and describe what is coming and what could in theory happen. The decision stays with whoever is responsible for operations. We would rather document a finding with the configuration and a description of the impact than with an attempt that would put manufacturing at risk. This procedure isn’t slower for the sake of caution. It is slower because the price of one wrong step is incomparably higher in OT than in IT.

The first step isn’t a test. It is an inventory. Without a list of what actually runs in operations, which devices, which versions, and which protocols, there is no saying what is at risk at all. A current inventory of devices is not a given, and just putting it together turns up things nobody expected to be there.

The second step is segmentation between IT and OT. Separating the office network from the control systems, so that one compromised workstation doesn’t lead straight to a machine, closes the shortest way in. The third is remote access: who reaches maintenance from outside, over which connection, and whether anyone watches it. Remote maintenance by a supplier is the path by which someone from outside gets into the industrial network.

These are steps you can manage without us. When you want to know which of them really holds and how an attacker would get to a machine, you can have the OT environment tested in the careful way this whole article is about. And because the industrial network is becoming a target for ransomware as well, how ransomware moves through a company is worth reading about separately.

Under normal circumstances no, because the work is mostly passive. Listening to traffic and analyzing configuration do not intervene in the systems, so manufacturing doesn’t know about the test. Active steps that could in theory load a device are taken only after approval and in an agreed maintenance window, in cooperation with operations. Before a risky step we call, and the decision stays with whoever is responsible for operations.

OT and IT differ in the order of priorities. In IT the confidentiality of data comes first; in OT it is availability and the safety of operations: the machine has to run and it must not endanger anyone. Add to that old devices that can’t take unusual traffic, and protocols that have no authentication in their basic form. That is why OT involves more listening and less active interference than IT.

A layered arrangement of an industrial network into levels, from office IT at the top through the control systems down to the sensors and actuators at the process itself. It describes where the boundaries between levels should be and where traffic may pass. In practice the most important one is the boundary between IT and OT: when it is missing, an attacker gets from the office straight to what runs manufacturing.