What can safely be tested on a live OT network

Start from the priority order, not from the toolkit

An IT penetration test exists to protect data. An OT assessment exists to protect a process, and the process protects people. NIST SP 800-82r3 states the order without hedging: for operational technology, “Human safety is paramount, followed by protection of the process.” It then adds the sentence that should open every set of rules of engagement: “Any security measure that impairs safety is unacceptable.”

That is not a slogan. It changes which findings are worth chasing. A missing patch on a controller that cannot be patched for another eighteen months is a fact, not a finding. A vendor tunnel that terminates below the demilitarised zone is a finding, because it can be closed this week. The methods below are ordered by what they cost the process, and that ordering is deliberate: the cheapest ones are also, in most estates, the most productive.

Methods that run while the process runs

Passive traffic capture

A tap or a switch SPAN port copies traffic without generating any. NIST describes passive scanning as adding no additional traffic to the network, “which is ideal for sensitive devices found on OT networks that may exhibit unexpected behavior when directly probed”. From a capture you get the devices that are talking, the protocols in use, the direction of every flow, credentials sent in plain text, and often manufacturer, part number and firmware version.

Be honest about the limits, because vendors of monitoring products rarely are. Passive capture “cannot identify devices that are not actively communicating, nor can it inspect encrypted traffic”, and “a passive scan will often take days to complete due to its dependence on existing network traffic”. A standby controller, a maintenance laptop that appears once a quarter and a device on a non-IP fieldbus will all be invisible. Passive capture gives you a very good inventory of the live plant, not a complete inventory of the plant.

Architecture, data-flow and firewall-ruleset review

This is documentary work: network drawings, firewall configuration exports, routing tables, remote-access designs, then a walk of the plant to check whether reality matches. It touches nothing and it routinely produces the highest-severity findings in an OT report, because the serious problems in industrial estates are structural.

NIST is specific about what to look for at the boundary. Firewall rules should “only permit connections between adjacent levels, tiers, or zones”, and an architecture using the Purdue model should “implement firewall rules and connection paths that prevent Level 4 devices from directly communicating with Level 2, 1, or 0 devices”. It also flags the direction people forget: “Allowing outbound connections from lower levels, tiers, or zones could represent a significant risk if unmanaged. Organizations should consider making outbound rules as stringent as inbound rules.”

Offline review of controller projects, logic and configuration

Ask for exports rather than access: controller project files, ladder or structured-text logic, HMI projects, device configuration backups, user and role definitions. Analysed on an isolated machine away from the plant, these produce findings no network technique can reach. Shared engineering passwords embedded in a project. An interlock commented out during a commissioning problem in 2019 and never restored. Logic that no longer matches the piping and instrumentation diagram. A web server and an SSH daemon left enabled on an HMI, which NIST specifically recommends disabling along with their ports when they are not in use.

The organisational catch is that someone has to produce the exports, and on a busy site that person is the same control engineer who is already fully committed. Naming them, and booking their time, is part of scoping the engagement rather than an afterthought.

Testing the enterprise network and the internet-facing edge

Above the demilitarised zone, ordinary penetration testing applies with one added constraint. NIST puts it plainly: “If penetration testing is performed on non-OT networks, extra care is taken to ensure that tests do not propagate into the OT network.” In practice that means an agreed set of source addresses, a hard scope boundary at the DMZ, and a check of the firewall logs afterwards to prove nothing crossed it.

This is also where real intrusions begin. In May 2023 SektorCERT recorded twenty-two Danish energy operators compromised in a few days through internet-facing Zyxel firewalls, initially via CVE-2023-28771 and later two further vulnerabilities announced during the campaign. The attackers reached industrial control systems, and several companies had to move to island mode operation. Not one of those compromises required a technique that is dangerous to a process. They required a device on the internet with an unpatched flaw.

Engineering workstation and historian review

The engineering workstation is the highest-value host in most plants. It holds the projects, the controller credentials and, very often, a direct route to every device on the control network. Review it authenticated, after taking and verifying a full image, and check the one thing that decides its blast radius: whether it is also joined to the office domain.

The historian and the demilitarised zone around it deserve the same attention with a strict read-only rule. Writing to a historian corrupts the record the plant uses to explain its own behaviour to a regulator, so exclude writes in the rules of engagement and issue read-only credentials specifically for the test.

The technique with a body count

Active scanning is not a slightly riskier version of passive capture. It is a different activity: it introduces traffic and interacts directly with devices designed for a narrow, deterministic job. NIST tells OT owners to “exercise extreme caution when permitting active scanning on an operational network due to device sensitivity on the target network”, because active scans “may cause device instability or interfere with the device process state, potentially impacting safety and integrity”, and it recommends scheduling them “during planned OT outages whenever possible”.

The published case files are more persuasive than the guidance. Appendix C of the same document records that while a ping sweep ran on an active SCADA network controlling nine-foot robotic arms, one arm became active and swung through 180 degrees; the controller had been in standby. A second ping sweep, run purely to inventory hosts, hung a system controlling integrated-circuit production and destroyed fifty thousand dollars of wafers. And a natural gas utility that hired an IT consultancy to test its corporate network found that the consultancy “carelessly ventured into a part of the network that was directly connected to the SCADA system. The penetration test locked up the SCADA system, and the utility was not able to send gas through its pipelines for four hours.”

A ping sweep. Not an exploit, not a fuzzer. That is the whole argument.

What each method costs and buys

The compensating control NIST actually names

For the CA-8 penetration testing control, the OT overlay in SP 800-82r3 says testing “is used with care on OT networks to ensure that OT functions are not adversely impacted by the testing process”, and then names the way out: “Example compensating controls include employing a replicated, virtualized, or simulated system to conduct penetration testing. Production OT may need to be taken offline before testing can be conducted.”

A replica is not a consolation prize. It is the only place a tester can be genuinely aggressive, and everything proven there shortens whatever on-site window is eventually booked. Where a full rig is impractical, three cheaper approximations usually exist: the vendor’s own test system, spare controllers held for maintenance, and a virtualised copy of the supervisory layer running the same project files. Each answers a subset of the questions, and each is safer than the plant.

NIST also removed the requirement for an independent penetration testing team from its high baseline, and the reasoning is worth quoting to anyone who insists on it: “Specific expertise is necessary to conduct effective penetration testing on OT systems, and it may not be feasible to identify independent personnel with the appropriate skillset or knowledge to perform penetration testing on an OT environment.” Competence in the process beats independence on paper.

What a plant that never stops can still learn

Operators who say “we can never take a window” often assume this means no assessment is worth commissioning. In practice, most of what an OT report contains comes from work that never touches a controller.

• An asset and conduit inventory as observed, and the list of differences between it and the network diagram.
• Every path in and out of the control network, including the vendor tunnel that predates the current maintenance contract.
• Credential, account and patch-state weaknesses on engineering and supervisory hosts, where the attacker actually lands.
• Logic and configuration flaws found in exported project files, including bypassed interlocks and hard-coded credentials.
• Whether the segmentation that the compliance file claims exists is enforced by a rule or by a habit.
• How long it takes to notice: replay a benign but unusual flow past the monitoring and see whether anyone calls.

What is genuinely lost is proof of exploitability on the real device, and the ability to measure how a controller behaves under stress. Both are worth having. Neither is worth an unplanned trip.

Where to spend the outage you do get

Plants have turnarounds. Aligning the intrusive part of a security programme to an existing outage is cheaper and safer than inventing a new one, and it forces a discipline that improves the work: a fixed device list, backups verified before anyone starts, the vendor reachable, and a return-to-service check signed before the process restarts. Treat it exactly like commissioning, because to the plant that is what it is.

A note on what the report must say

An OT report that lists only what was found is incomplete and, in the wrong hands, misleading. It has to state explicitly what could not be tested safely and what it would take to test it. “We found nothing there” and “we could not look there” are different sentences with different consequences, and a board that cannot tell them apart will believe it has assurance it has not bought. Making the untested residue an explicit deliverable is the single easiest way to keep an OT programme honest, and it is covered in more detail in the rules of engagement guide.

For where the legal obligation to assess comes from, and how much of this is actually required, see NIS2 and OT security testing. For the standard that will shape the remediation programme afterwards, see which part of IEC 62443 applies to you. The approach selector on the home page turns the decisions in this guide into a specific answer for one environment.