OT Penetration Testing Without Downtime: How It Is Done

Yes, a plant can be penetration tested without stopping production, if the test is designed for it from the start. Most of the findings in an OT assessment come from passive analysis, configuration review and tests on a bench, not from attacking a running controller. Active tests against live systems are limited to a maintenance window with a safety sign-off, and some things are never done on a live plant at all.

This is how we structure it, and where the lines are.

Why OT is tested differently

In IT, a crashed web server is restarted. In OT, a crashed controller can stop a line, spoil a batch or, if a safety function is involved, hurt someone. Three properties change the method:

• Availability and safety come first. Confidentiality is third. A test that finds every weakness and stops production has failed.
• The stacks are fragile. A PLC from 2009, a fieldbus gateway or a serial-to-Ethernet converter has a network stack that handles its protocol and little else. Unexpected packets can hang it.
• The lifecycle is long. Patches are rare, downtime is scheduled months ahead, and the system you test today will run for another ten years.

NIST SP 800-82 Rev. 3 and IEC 62443 both say the same thing: assess OT systems with methods that respect these properties, and prefer testing representative systems offline over testing production.

What works without downtime

Around three quarters of the findings in a typical OT assessment come from these steps, none of which touches a running controller:

Method	What it finds	Production impact
Passive network capture (SPAN port or TAP)	Asset inventory, protocols in use, cleartext credentials, unexpected connections, IT-to-OT traffic	None
Architecture and zone review	Flat networks, missing conduits between zones, dual-homed hosts, undocumented paths	None
Firewall and switch configuration review	Permissive rules, unused rules, management interfaces on the production network	None
Remote access review	Shared service accounts, VPN boxes with vendor defaults, cellular routers nobody owns	None
Engineering workstation assessment	Local admin for everyone, old project files with passwords, unsigned project uploads, USB policy	Treated like IT, outside shift hours
Offline firmware and project analysis	Hard-coded credentials, missing signature checks, debug services	None; done on copies
Interviews with controls engineers	How changes are made, who has the vendor password, what happens on alarm	None

The typical result: a service VPN with a password printed in the manual, an HMI that reaches the controller from any host in the subnet, a PLC in a mode that accepts a program download without authentication. None of these needs an active attack to be found; see the typical findings for machine builders.

Test benches and twin setups

Active testing belongs on a system that may fail. Three options, in order of preference:

1. A spare controller and HMI with the production project loaded, on a bench at your site or in our lab. The same firmware, the same project, the same network settings. Here we can fuzz, brute-force, upload modified programs and try exploits as aggressively as needed.
2. The vendor’s or integrator’s test rack, often available during a factory acceptance test. The FAT and SAT phases of a new line are the cheapest moment for a full active test; the plant is not yet in production.
3. A twin setup: duplicate network, controllers and HMIs for one segment. Expensive, but for a plant that cannot be stopped it pays for itself with the first finding that would have tripped the line.

For machine builders, the test machine on your own floor is the obvious bench. Fix the findings there and the fix travels to every machine you ship.

What belongs in a maintenance window

Some tests need the real system: the real firewall, the real segmentation, the real remote path. These go into a planned window with a controls engineer present, the safety officer informed and a rollback plan:

• Segmentation tests between zones: can a host in the office network reach the controller, can the HMI network reach the safety system. Done with single, targeted connections, not a scanner sweep.
• Authenticated checks on controllers and HMIs: firmware versions, enabled services, access control settings, read via the vendor’s own tools.
• Controlled scanning with ICS-aware settings: one host at a time, low rate, known-safe probes, immediate stop if the device reacts.
• Remote access path tests: connect as a service technician would and see how far you get.
• Backup and recovery check: can the project be restored to the controller from backup. Finding out during the test is better than finding out during an incident.

What is never done on a live plant

These stay on the bench, no matter how good the window looks:

• Fuzzing of fieldbus or control protocols against production controllers (Modbus, PROFINET, EtherNet/IP, OPC UA, S7). Fuzzing is for the test bench and the lab.
• Unauthenticated write attempts: stop or start commands, mode changes, setpoint or program changes on a running PLC.
• Any active test against a safety instrumented system (SIS) or a safety PLC. Safety systems are reviewed, not attacked.
• Exploit attempts against controllers, drives or HMIs in production, even with a known CVE. The proof of concept runs on the spare unit.
• Brute force, denial of service or load tests against anything that controls a physical process.
• Anything without the written authorisation of the plant owner and the sign-off of whoever is responsible for safety. Zyberum does not start without both.

If a finding on the bench is critical and you need to know whether production is affected, we check it with a read-only method, a version string, a configuration export or a single crafted but harmless request, never with the exploit.

How a downtime-free OT test runs

Phase	Duration	Downtime
Scoping and safety briefing: zones, controllers, exclusions, windows, contacts	Half a day	None
Passive capture and reviews on site	2 to 4 days	None
Bench or twin testing	3 to 6 days	None
Maintenance window tests	2 to 8 hours	Within the window
Report with findings mapped to IEC 62443-3-3 or 4-2 and to the Machinery Regulation’s protection against corruption	2 to 3 days	None
Results presentation and fix planning with the controls team	Half a day	None

Typical effort is 8 to 15 testing days, which is 12,000 to 25,000 euros at market rates, for one plant segment or control system. A test bench on your side is the single biggest saving.

Zyberum tests plants, machines and controllers this way, does the gap analyses against IEC 62443 and trains controls engineers in secure design. We are not a certification body and issue no certificates; the report is the evidence you take into your 62443 conformity work or your Machinery Regulation documentation. See industrial security or book a free consultation with your plant layout at hand.