OT Pen Testing — Worth the Risk?

Every IT security program eventually does a penetration test. It's table stakes — auditors expect one, the board expects one, and the security team wants the validation. So when an organization extends a cybersecurity program into operational technology, the first instinct is often to extend the pen-test cadence to plant networks too.

That instinct is usually wrong. Or, more carefully: it's right about some activities and dangerously wrong about others. The reason is not that OT networks are uninteresting or impervious — quite the opposite. The reason is that the blast radius of getting it wrong in OT is measured in dollars per minute of downtime, in safety incidents, and sometimes in human lives. An IT red team can knock a corporate intranet offline for an afternoon and write a sheepish incident report. An OT red team that takes down a feedwater pump can hurt people.

The instinct comes from confusing two different exercises

When most people say "pen test" in an IT context, they actually mean a bundle of different activities lumped under one label: external port scanning, internal vulnerability scanning, social engineering, authenticated configuration reviews, web app testing, and active exploitation. The deliverable is usually one report.

In OT, those activities have wildly different risk profiles. Lumping them is what gets you in trouble.

• Passive enumeration of the plant network — listening on a SPAN port, reading PCAPs, parsing engineering-station configurations offline. Low risk, high value. You should always do this.
• Configuration review of OT firewalls, jump hosts, and historian databases — read-only, with the operator watching. Low risk, high value. Do this.
• Active scanning of the level-2 OT network — using nmap, even with --safe-checks, against PLCs and HMIs running on twenty-year-old firmware. Medium-to-high risk. Many devices crash on unexpected packets, and "crash" in OT means a plant trip. Test this in a lab first or don't do it.
• Exploitation of confirmed vulnerabilities on production OT assets. No. Almost never the right move. Find another way to demonstrate impact.

The question isn't "should we pen test OT?" — it's "what's the actual outcome we want?"

If the outcome is compliance evidence, you usually don't need active exploitation. A documented configuration review, passive traffic analysis, asset inventory, and a tabletop exercise covers the same ground for IEC 62443 or NIST SP 800-82 audits without bricking anything.

If the outcome is finding exploitable paths, you do need active testing — but not on the production environment. You need a lab. A lab replica of the actual control system, or at least the same vendor/firmware versions, and you test there. The findings transfer to the production environment as likely vulnerabilities to compensate for; you do not need to prove them by exploiting production.

If the outcome is training the SOC to detect OT-specific attack patterns, that's a purple-team exercise, not a pen test. You generate the indicators in a lab and replay them through the OT NIDS that's monitoring production. The blue team gets the signal, nothing on the plant floor moves.

When active production testing actually makes sense

There are narrow situations where you do active testing on a live OT network. Maintenance windows, with operations engineering co-piloting every command, and with the explicit goal being safety-relevant: confirming that a network segmentation control actually drops the packets it's supposed to drop, for example. You agree in advance what "abort" looks like, you have a rollback plan, and you treat the activity with the same rigor as a controls modification.

What you don't do is hand the engagement to an external pen test firm that has done excellent work on IT systems but has never met a Modbus PLC, and then turn them loose during normal operations. That is how pipelines go down.

What I recommend to plant owners

The pattern that's worked best in my engagements:

1. Start with asset visibility. You can't pen test what you can't see. Passive discovery — SPAN ports, OT-aware NIDS in detection mode — gets you 80% of the inventory in a couple of weeks with zero risk to operations.
2. Configuration review and passive analysis. Pull the configurations, walk the firewall rules, read the architecture diagrams, look at backed-up PLC logic. Map what you find to the foundational requirements of IEC 62443. Nine times out of ten, the most valuable findings come from this step, not from active exploitation.
3. Tabletop exercises with operations. Run through three or four credible attack scenarios with the people who actually run the plant. The conversations expose more about real exposure than any nmap output will.
4. Lab-based active testing. If you have the budget and a representative test bench, exploit there. Document what you learned. Use it to drive compensating controls on the live system.
5. Production-side active testing only if necessary, only in maintenance, only with operations. And only for safety-relevant validation, not for "let's see what breaks."

The blunt summary

Pen testing in OT is worth it if you're testing the right things. Most of the value of an OT security assessment comes from techniques that don't carry the risk profile most people associate with "pen test." Insist on the assessment outcomes; be skeptical of the assessment style imported wholesale from IT. The people maintaining the plant will thank you, and so will the public.

This article touches on themes I cover at length in Chapter 14 of the OT Cybersecurity Professional course — cybersecurity controls, asset visibility, NIDS placement, and the difference between IT and OT testing strategy. See the curriculum.