OT and ICS Penetration Testing Is Not a Network Assessment
Industrial control systems run refineries. They manage water treatment plants. They operate manufacturing floors and power substations and pipeline pressure systems. When someone asks what the security implications of a compromised ICS are, the answer is not "data exfiltration." It is "people could get hurt" or "the plant goes offline" or both.
Testing the security of OT and ICS environments requires a fundamentally different approach than testing enterprise IT networks. The methodology that finds vulnerabilities in an Active Directory environment can take down a production line if applied without modification to a SCADA system. The tools that are standard issue for a network pentest may crash PLCs when they issue unexpected packets. The risk calculus is different in every dimension.
Most organizations commissioning an OT security assessment do not understand this. Many firms selling OT security assessments do not fully account for it either.
What "OT" Actually Covers
Operational technology is a broad term for the hardware and software that monitors and controls physical processes. Industrial control systems are a subset: SCADA (Supervisory Control and Data Acquisition) systems, distributed control systems, programmable logic controllers (PLCs), remote terminal units, and the historian servers and human-machine interfaces that connect them.
These are not the systems that run email. They run the things that move, heat, cool, pump, generate, and physically do things in the real world. The security model appropriate for a file server is not appropriate for a PLC controlling a compressor. The consequences of getting this wrong extend well beyond a breach notification letter.
OT environments are also old. Twenty-year-old controllers are common. Legacy serial communication protocols - Modbus, DNP3, Profibus - designed long before security was a design consideration are still widely deployed. Systems that were never intended to be networked have been connected to corporate IT networks, and sometimes to the internet, through integration projects that prioritized connectivity over security. The result is a broad attack surface built on equipment that was never designed to be hardened in the first place.
Why Standard Pentest Methodology Does Not Transfer
A network penetration tester's default tooling is aggressive by design. Port scanners send packets to every host on the range. Vulnerability scanners probe services with malformed requests to elicit error conditions. Credential testers send authentication attempts at volume.
Apply any of these without modification to an OT network and you will likely see consequences that do not appear in an enterprise IT assessment. PLCs have limited processing capacity. They are designed to execute deterministic control loops, not to handle unexpected network traffic. A port scan can consume enough of a PLC's CPU to disrupt the control loop. A vulnerability scanner probing an ICS device with unexpected payloads can crash it outright or cause erratic output to the physical process it controls.
These are not hypothetical scenarios. There are documented cases of assessments crashing control systems that had been running continuously for years. The plant has to restart. Production stops. In some contexts, an uncontrolled shutdown creates safety hazards of its own.
An OT penetration test requires working from architecture documentation before touching anything. Network diagrams, asset inventories, communication flow documentation. The test must be scoped with the engineering team's involvement, not just the security team's. Any scanning must be passive where possible, and active probing must be reviewed against specific device models to verify it will not cause disruption. There are techniques appropriate for Modbus polling or EtherNet/IP enumeration that gather useful information without sending anything a device has not seen in normal operation.
The testing window matters too. An OT test run during a planned maintenance window, when systems are in a known safe state, is fundamentally different from one run during active production. Most IT pentests do not require scheduling around industrial operations. OT ones do.
The Purdue Model and Why Segmentation Fails in Practice
The traditional OT network architecture follows the Purdue Model, which defines layers from the enterprise network at the top down through manufacturing operations and to field devices at the bottom. The security intent is that each layer communicates only with adjacent layers, keeping the plant floor isolated from the corporate network.
In practice, the Purdue model describes what organizations intended to build in the 1990s. What they actually built since then includes remote access paths added for vendor support, historian connections bridging layers, engineering workstations with both IT and OT network interfaces, and wireless access points installed for operational convenience without security review. A flat OT network sitting behind a single firewall from the corporate environment is not rare. It is the norm in most industrial environments that have not undergone a recent architecture assessment.
This means the entry point for an OT compromise is often the corporate network, not the plant floor directly. An attacker who compromises a domain-joined engineering workstation may have access to both environments. The firewall between them is only as good as the rules on it, and those rules were often written by IT teams who did not fully understand the OT context on the other side.
One of the most valuable things an OT penetration test can surface is the actual segmentation state, not the intended one. Which hosts have routes to both sides? Which protocols are permitted through the boundary? What does lateral movement from the IT environment toward OT actually look like in this specific facility?
What a Good OT Assessment Actually Produces
An OT penetration test run well involves practitioners who understand industrial protocols, can read PLC ladder logic, know which enumeration techniques are safe for which device families, and have experience communicating findings to operational engineers who care about uptime above almost everything else.
The deliverable is not a vulnerability list sorted by CVSS score. CVSS scores are built for IT systems and do not translate meaningfully to OT contexts. A low-severity CVE in an isolation valve controller represents a completely different risk profile than a high-severity CVE in a corporate web server, and treating them equivalently produces a remediation roadmap that misses the point.
The deliverable is a threat model specific to the environment, realistic attack paths that account for the operational constraints of the facility, and remediation guidance that the operations team can actually implement. Telling a production facility to patch their PLCs on a quarterly cycle is not actionable advice for systems that require vendor involvement, extended maintenance windows, and sometimes equipment replacement because no firmware update exists.
Before commissioning an assessment of an industrial environment, ask the vendor specifically how they handle the methodology question for OT systems, which protocols they have tooling for, and whether they coordinate assessment windows with operations teams. The answer will tell you quickly whether you are buying an OT assessment or an IT network test delivered to an unusual network.
The stakes in OT security are different from anything else on the penetration testing menu. Treat the assessment accordingly.