Penetration testing in OT: how to test a plant without breaking it

The rules of engagement that matter

• Scope by zone. The internet-facing estate, the corporate network, the industrial DMZ, the supervisory network and the controllers are different places with different rules. Write down which techniques are allowed in each.
• Windows. Active testing on plant systems happens in agreed maintenance windows, not whenever the tester is free.
• Stop conditions. For every active step, what would make you stop, who can call it, and how quickly. The operations lead holds the stop button, not the tester.
• Operations and engineering in the room. They know what the process is doing right now, and they are the ones who will notice if it changes.
• Safety systems out of scope for active testing. Safety instrumented systems are reviewed and, if needed, tested in a lab. Never attacked in place.
• Vendors informed. If the OEM holds the support access, they need to know a test is coming, and their support line needs to be open.

Passive first: what you learn without sending a packet

Most of an OT test's value comes before any active step. A network tap or mirror port shows every device that talks, on which protocols, to whom. Configuration exports from firewalls, switches, controllers and HMIs show what is permitted, what is default, and what is stale. Documentation and interviews show where the remote access really lands.

By the end of passive discovery a good team can already draw the attack path: the vendor VPN that terminates on an engineering workstation, the domain trust between office and plant, the historian that is on both networks, the shared account used by three contractors. Active testing then confirms the path rather than searching for it.

Active testing, in the right place

• Internet-facing estate: full testing. Remote access portals, VPNs, exposed services and anything OT-related reachable from outside. This is where most real intrusions begin.
• Corporate network, assumed breach: full testing, with care around anything that touches the plant. The goal is the path from a compromised office laptop to the OT boundary and across it.
• Industrial DMZ and supervisory level: deliberate, in windows, one system at a time, with rollback ready. Jump hosts, historians, HMIs and engineering workstations.
• Controllers, safety systems and field devices: lab only. Spare units or representative equipment, where a crash costs nothing and the finding is still real.

The lab

A lab is not a lesser test. A finding proven on the same controller model and firmware as the plant is evidence; a finding asserted from a version number is opinion. Labs range from a bench with a spare PLC and HMI to a segmented replica of a site. For firmware and device testing, the lab is the only responsible place to work.

What the lab cannot prove is the path. That is why lab work follows passive discovery and boundary testing, not the other way round.

What a good report contains

• The attack path as a story: where the tester started, each step, what was needed, how long it took, and what they could do at the end.
• Findings ranked by consequence to the process, not by CVSS. An unauthenticated write to a plant controller outranks a critical web vulnerability on a reporting server.
• Evidence: screenshots, captures and lab reproduction, so the engineer who has to fix it believes it.
• What monitoring saw. If you have detection, the test is the best exercise it will get. The report should say which steps were seen, which were not, and why.
• A remediation plan sequenced by risk and by outage window, and a retest once the work is done.

The regulatory drivers

In India, the CEA power sector regulations require vulnerability assessment and penetration testing before any new or replaced critical system goes live, with details to CSIRT-Power within thirty days of commissioning, and CERT-In's audit guidelines expect testing that includes OT. In Australia, the SOCI regime lets the government require vulnerability assessments of systems of national significance, and a CIRMP that claims to manage cyber risk needs evidence that the controls work. IEC 62443-2-1 expects an asset owner's programme to include periodic testing, and NIST SP 800-115 is the general method a test should follow.