How is OT penetration testing different from IT penetration testing?

The asset at the end of the wire

An IT penetration test ends at a server, a database or a domain controller, something that stores or processes information. An OT penetration test ends at a valve, a pump, a breaker or a furnace. The IP address under test is not the target. It is an interface to something with mass, pressure, temperature or voltage on the far side of it, and the whole engagement has to be designed around that fact from the first packet.

That asset is usually a programmable logic controller (PLC), a remote terminal unit (RTU), a distributed control system (DCS) node, a human machine interface (HMI), or a safety instrumented system (SIS) controller, speaking a protocol built for determinism, not for an adversary. On a plant floor it is at least as likely to answer on an engineering protocol such as Modbus TCP, DNP3, EtherNet/IP's Common Industrial Protocol, Siemens S7comm or OPC UA as it is to run a web server at all, see the port reference for the numbers and the ports that should never be probed. These were built as engineering protocols for a closed wire, and most of the devices speaking them were never designed to be reached by a stranger.

Patch windows measured in years, not weeks

An IT estate patches monthly, sometimes weekly for anything internet-facing. An OT estate patches when the plant is not running, and for a continuous process site that can mean once every two to five years, at the shutdown or turnaround when the unit is offline for maintenance regardless, the cadence refinery turnarounds typically follow. A fix published today can sit on the plant floor for years, not from negligence, but because there is no scheduled moment to apply it without stopping production.

The hardware outlives the patch cadence by even more. A twenty to thirty year service life is the standard planning horizon for core PLC hardware, and controllers commissioned in the 1990s are still comfortably inside that window. A test that assumes an IT refresh rate, three to five years and the box is retired, is testing a fiction.

The advisory pipeline does not close that gap. CISA published twelve new ICS advisories in a single release on 11 December 2025, and Dragos found that 25 percent of the ICS advisories it tracked through 2025 shipped with no vendor patch or mitigation at all. A finding with nowhere to go is not the exception here. It is a quarter of the catalogue.

Availability first: why exploitation is usually the wrong goal

The CIA triad does not just reorder for OT, it inverts. NIST's guide to operational technology security puts availability and integrity ahead of confidentiality for control systems, because a leaked setpoint is an embarrassment and an interrupted one is a process upset. Taking an IT server offline for an hour produces a ticket. Taking a controller offline for a second can produce a trip, a spill, a scrapped batch or worse.

That changes what success means for the tester. An IT engagement aims to get code running where it should not: a shell, a privileged token, a full chain proven end to end. On a plant network, firing the write that turns a weakness into a forced output is usually the wrong goal: the finding's value was already proven before the write, and sending it adds risk without adding information. Triton, the malware that reached Schneider Electric Triconex safety instrumented system controllers at a Saudi petrochemical plant in 2017, is the clearest illustration: it triggered an unplanned shutdown while trying to reprogram the very system built to prevent a worse one.

What replaces exploitation is a pair of proofs. Reachability asks whether the tested zone can get a packet to the target across the segmentation meant to stop it. Controllability asks whether, if that packet arrived, the attacker could change what the device does, established through a passive read, a configuration export, or a cross-check against the vendor's own advisory, not through the write itself. Both are provable without touching the process, and proving them is the deliverable. Sending the write is a decision for the plant's own engineers, not the tester.

The Purdue model is the axis of the whole engagement

Ask an OT engagement where it is allowed to run and the answer comes back as a Purdue level, not a subnet. The model runs from Level 0, the physical process itself, up through basic control and supervisory control to operations, then to Level 4 and 5, the site business and enterprise networks, where an ordinary IT assessment lives. Between Level 3 and Level 4 sits the demilitarised zone, the one sanctioned conduit meant to be the only path across.

Every scoping decision in the engagement traces back to that ladder: which level the assessment is authorised in, what sits across the DMZ, whether a path exists from Level 4 to Level 1 that the diagram says should not. IEC 62443-3-2 formalises the same idea one layer down, as zones, assets sharing a security requirement, and conduits, the controlled channel between them; an OT finding is very often exactly that: a conduit carrying more than the zone diagram allows.

NERC CIP works from a different axis. CIP applies to the Bulk Electric System, transmission at 100 kV and above plus qualifying generation, not to every asset sitting at Level 1 or 2. A distribution substation below that threshold can carry an identical PLC and an identical Purdue diagram to one inside CIP scope, and none of the compliance obligation. The Purdue level tells you where you are standing. It does not tell you which standard, if any, is watching.

IT penetration testing vs OT penetration testing, side by side

Enumerating everything because enumeration is free is where the two disciplines diverge hardest. On IT, it is close to free. On OT, the evidence an engagement collects is deliberately the cheap kind: a passive protocol read rather than a write that forces an output or changes a setpoint, a distinction Modbus function codes and read-versus-write safety sets out in detail; a CIP Identity object read after a registered EtherNet/IP session rather than the Forward_Open exchange that reserves an I/O connection; a broadcast the device sends on its own rather than a query that makes it answer. Nothing on that list changes the process, and all of it still proves what needs proving.

That last row matters because an OT report is read by two people who need different things from the same page. A finding has to name the Purdue level and the zone it was found in, because that is how a controls engineer locates it on their own diagram. It has to state the process consequence in plant language, not "remote code execution" but "this is the feed pump controller for line 4, and this is what an operator would see if the write had succeeded." It also has to state what was deliberately not attempted, because a report listing only what was done cannot be told apart from one that ran out of scope by accident.

What IEC 62443 and NERC CIP don't tell you

IEC 62443 and NERC CIP describe an architecture. Neither tells you how to test it without becoming the incident you were hired to prevent.

IEC 62443-3-2 says a zone should carry a defined security level and a conduit should be the only path between two zones. It does not say what scan rate is safe for the RTU sitting in that zone, only that a scan is not a protocol read, and the difference has to be established for each device before testing starts, not assumed from the standard. That work lives in the engagement's own reachability testing and the vendor's documentation, and skipping it is guessing at the plant's expense.

NERC CIP is scoped to the Bulk Electric System, and most of a plant's OT footprint sits outside that boundary: generation and distribution equipment below 100 kV, water treatment and manufacturing sites that never touch the bulk grid. A clean CIP posture says nothing about whether that equipment has been tested, and reading it as general OT assurance is the mistake, not a flaw in a standard never written to cover that ground.

Both documents assume the assessor already knows to stop before the write. Neither supplies the judgement about when reachability is sufficient evidence and when a controlled write is warranted. That call belongs to the person running the engagement, informed by the plant's own engineers, made fresh every time rather than read off a page.

Why an unchanged IT methodology is the actual risk

None of this is exotic. It is the ordinary reflexes of a competent IT tester, applied to a network where they stop holding. Scan harder when a host goes quiet, because on IT a quiet host usually means a firewall, while on OT it often means a device mid cycle that will drop off the network under load. Retry a failed login, because on IT that is iteration, while on OT the account behind it may be the one the historian uses to write, and a lockout is a gap in the plant's production record, not a nuisance. Treat every open port the same, because on IT a server is a server, while on OT the next address in the range might be the safety controller for the line.

The real risk in OT penetration testing is rarely the technique. It is an IT methodology built for a network where availability recovers in minutes, applied unchanged to one where it does not. The asset that is not a server, the patch that will not land for years, the goal that stops at proof rather than exploitation, the Purdue level that decides where the tester is even allowed to stand: each point in this guide exists because that substitution keeps happening, usually by people who know better, on the network where it costs the most.

Nexich runs this kind of assessment as an authorised offensive engagement inside the customer's own perimeter, air-gapped by default and read-only on the control networks it touches.