What is an OT penetration test?

An OT penetration test is an authorised security assessment of the networks and systems that control physical processes: PLCs, HMIs, SCADA servers, historians, engineering workstations and the boundary between them and the corporate IT network. It combines active testing of the IT and DMZ layers with passive discovery, configuration review and bench or staging tests for the control layers, so that the process is never put at risk.

Is it safe to penetration test a live SCADA or ICS environment?

It is safe when the method matches the level. Enterprise IT and the industrial DMZ can be tested actively in agreed windows. Supervisory and control layers are assessed passively, by configuration review, and on staging systems or spare units; active testing against live controllers is not done. Every activity below the DMZ runs with operations present, a stop criterion and a rollback plan.

What is the difference between an OT pentest and an IT pentest?

An IT pentest prioritises confidentiality and can tolerate a service disruption; an OT pentest prioritises availability and safety and cannot. OT adds legacy protocols without authentication, devices that cannot be patched, vendor warranty constraints and equipment that may crash on ordinary scanning. The techniques overlap at the IT boundary; the method below it is different.

Does NIS2 require penetration testing of OT systems?

NIS2 does not name penetration testing, but Article 21(2)(f) requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures, and for an energy, water, transport or manufacturing entity those measures include the industrial environment. A testing programme that covers only the office network leaves the supervisor's main question unanswered.

What is the Purdue model and why does it matter for testing?

The Purdue model divides an industrial network into levels, from the physical process (Level 0) and controllers (Level 1) up through supervisory control (Level 2), site operations (Level 3), an industrial DMZ (Level 3.5) and enterprise IT (Levels 4 and 5). It matters because the level determines the method: active testing is appropriate at Levels 3.5 and above, limited at Level 3, and replaced by passive and offline methods at Levels 2 and below.

Can you test our PLCs or controllers directly?

Yes, on the bench or on a staging system, not on live production. Spare units, a factory acceptance test setup or a vendor digital twin allow firmware, configuration and protocol behaviour to be examined fully. Findings are then confirmed on production by inspection of version and configuration, which carries no operational risk.

1 November 2026 · 10 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)

OT and ICS penetration testing: how industrial control systems are tested without putting the process at risk

A penetration test on an office network tolerates a crashed service. A penetration test on a water treatment plant or a production line does not. This guide explains what operational technology is, why it is tested differently from IT, where in the Purdue model active testing is safe, how a controlled engagement runs, which frameworks apply and what the deliverable should contain.

Scope an OT or network penetration test

What OT, ICS and SCADA mean

Operational technology (OT) is the hardware and software that monitors and controls physical processes: valves, pumps, motors, conveyors, turbines, switchgear. Industrial control systems (ICS) are the OT components that do the controlling. SCADA (supervisory control and data acquisition) is the architecture that lets operators supervise many controllers across a site or a region from a central point. In practice the terms overlap and vendors use them loosely; a tester needs to know the components rather than the labels.

The components recur across sectors. PLCs (programmable logic controllers) execute the control logic next to the process; RTUs (remote terminal units) do the same at remote sites. A DCS (distributed control system) coordinates continuous processes in plants such as refineries and power stations. HMIs (human-machine interfaces) are the screens operators work from. Historians store process data for analysis and compliance. Engineering workstations hold the software that programs the controllers, which makes them the most sensitive machines in the environment. Safety instrumented systems (SIS) sit apart to bring the process to a safe state when something goes wrong.

Who runs OT: energy, drinking water and waste-water utilities, oil and gas, chemicals, pharmaceuticals, food and beverage, manufacturing, rail and port operators, airports, hospitals (building management, medical gas), data centres (power and cooling) and any large building with a building management system. Many organisations that consider themselves IT-only run OT in their facilities without a security owner for it.

Why OT penetration testing differs from IT penetration testing

The techniques overlap. The constraints do not. Five differences change how an engagement is scoped and run.

Availability and safety come before confidentiality

In IT the classic order is confidentiality, integrity, availability. In OT it is reversed: the process must keep running and must not harm people, equipment or the environment. A test that reveals a weakness by stopping a controller has caused the incident it was meant to prevent.

Legacy protocols were never designed for a hostile network

Modbus/TCP, DNP3, Profinet, EtherNet/IP and IEC 61850 were designed for reliability on isolated networks. Most carry no authentication and no encryption; a device accepts a command because it arrived. OPC UA added security features, but older OPC Classic deployments remain common. The tester's job is to show where these protocols are reachable from, not to send commands to live controllers.

Patching is rare and controlled by the vendor

A PLC may run for fifteen years on its original firmware. Patching needs a maintenance window, a vendor-qualified version and often a re-validation of the safety case. Findings therefore need compensating controls (segmentation, monitoring, access restriction) rather than the IT reflex of 'update it'.

Vendor warranties and support contracts constrain what may be touched

Many integrator and vendor contracts void support if third-party software runs on, or unapproved traffic is sent to, their equipment. Scoping must involve the asset owner's control engineers and, where necessary, the vendor, before any active test.

Fragile devices react badly to ordinary scanning

Standard IT scanners send traffic that embedded devices were never tested against; controllers have been crashed by port scans and malformed packets, which is why NIST SP 800-82 warns against active scanning of production control networks. Passive methods and offline analysis replace much of the active toolkit.

The Purdue model: where testing is safe

The Purdue reference model, used by ISA-95 and IEC 62443, divides an industrial network into levels. The level determines the method.

Level	What lives there	How it is tested	Active testing on production?
Level 4 and 5: enterprise IT	Corporate network, ERP, e-mail, internet connectivity	Standard IT penetration test: external, internal, Active Directory	Yes, as for any IT network
Level 3.5: industrial DMZ	Jump hosts, patch and antivirus relays, data brokers, remote-access gateways	Active testing of the boundary from both sides; this is where IT-to-OT compromise is stopped, or is not	Yes, in agreed windows
Level 3: site operations	Historians, MES, engineering workstations, OT domain controllers, backup servers	Careful active testing of Windows and Linux hosts; configuration review; credential and remote-access review	Limited, in change windows, with operations present
Level 2: area supervisory control	HMIs, SCADA servers, alarm servers, local operator stations	Passive traffic analysis, configuration and account review, read-only queries; active testing only on staging or a twin	Only with an explicit go/no-go per system; never during production runs
Level 1: basic control	PLCs, RTUs, controllers, protocol gateways	Firmware and configuration review offline, bench testing on spare units, passive observation of protocol traffic	No. Bench or digital twin only
Level 0: the physical process	Sensors, actuators, drives, instruments	Documentation review and physical inspection; safety instrumented systems reviewed with the safety engineer	No

The safe method: how a controlled OT engagement runs

Six steps separate an OT penetration test from an IT test pointed at a factory.

1. Scoping with operations, not only IT

The kick-off includes the plant manager, control engineers, the safety officer and the IT security owner. Together they list every zone, every asset class, the production calendar, the safety-critical systems that are out of scope for anything active, and the vendor constraints. The output is a written scope with a method per zone and a named go/no-go authority.

2. Passive discovery first

The asset inventory is built from a mirrored switch port or a network tap, reading traffic rather than generating it. This reveals the real device list (usually larger than the documented one), protocol flows, who talks to whom, unexpected connections to IT or the internet, and credentials crossing the wire in cleartext. Tools built for industrial protocol parsing are used; standard IT scanners are not pointed at Level 1 or 2.

3. Boundary and IT-side testing

The IT network, the industrial DMZ and the remote-access paths are tested actively with standard methods. The question is whether an attacker who compromises a workstation at Level 4 can reach Level 3 or below, and through what: a dual-homed host, a shared account, a vendor VPN, a firewall rule that was meant to be temporary.

4. Staging, digital twin or bench for the control layer

Where controller or HMI behaviour must be tested, it is tested on a staging environment, a factory or site acceptance test setup, a vendor-provided digital twin, or a spare unit on a bench. Findings are then confirmed on production by inspection of configuration and firmware version, never by repeating the test against the live device.

5. Change windows, stop criteria and rollback

Any activity that touches Level 3 or lower runs in a planned maintenance window with operators at the console, a written stop criterion (an alarm, a latency threshold, a process deviation) and a rollback plan. The tester stops first and asks questions afterwards.

6. Findings rated for process consequence, not CVSS alone

CVSS v4.0 scores technical severity. OT findings also carry a consequence rating: what happens to the process, to people and to the environment if this path is used. A medium CVSS finding that reaches a safety system is a top-priority finding, and the report says so.

Frameworks and regulation that apply to OT testing

Three sources define what good OT security looks like and what a regulator will ask to see. Where ISO 27001:2022 applies, OT assets in scope fall under the same A.8.8 vulnerability management expectations as IT.

IEC 62443

The international standard series for industrial automation and control system security. IEC 62443-3-2 defines the zones-and-conduits risk assessment that a test should map to. IEC 62443-3-3 sets system security requirements and the four security levels (SL 1 to 4) against which a system is assessed. IEC 62443-4-1 covers the secure development lifecycle for component vendors and is the document to cite when asking a supplier how their product was tested. A penetration test is one of the ways an asset owner verifies that a zone meets its target security level.

NIST SP 800-82 Rev. 3

The Guide to Operational Technology (OT) Security, revised in 2023, is the most widely used practical reference. It explains OT architectures, threats, risk management and recommended controls, and is explicit that active testing of production OT must be approached with caution and preferably performed on representative test systems. Its control overlay maps to NIST SP 800-53, which helps organisations that already run the NIST framework for IT.

NIS2 and the Dutch Cyberbeveiligingswet

Energy, transport, drinking water and waste water are sectors of high criticality under Annex I of the NIS2 Directive; manufacturing of medical devices, electronics, machinery and vehicles, and food production, fall under Annex II. Article 21(2) requires risk-management measures including supply-chain security (point d) and policies and procedures to assess the effectiveness of those measures (point f). For OT-heavy entities, a documented testing programme that covers the industrial environment and not only the office network is what the supervisor will expect to see. In the Netherlands the Directive is implemented through the Cyberbeveiligingswet.

What OT penetration tests typically find

Patterns repeat across sectors. Most are architectural rather than exotic, which is good news: they are fixable with segmentation and access control rather than with firmware.

Flat networks: no industrial DMZ, so a compromised office workstation can reach HMIs and controllers directly
Dual-homed hosts: engineering workstations or historians with one interface in IT and one in OT, bypassing the firewall entirely
Default or shared credentials on HMIs, controllers, switches and vendor accounts, sometimes printed in the manual
Remote access without multi-factor authentication: vendor VPNs, cellular modems on controllers, consumer remote-desktop tools installed for convenience
Unsupported operating systems on Level 2 and 3 hosts, with no compensating isolation
Cleartext industrial protocols reachable from zones that have no operational need to talk to controllers
Engineering software and controller write access available from any host on the supervisory network, not only from authorised workstations
No monitoring at Levels 1 to 3, so none of the above would be noticed while it is being exploited
Undocumented assets: devices on the network that no one owns, often installed by a contractor years ago

What the deliverable should contain, and how HackersHub tests OT

An OT penetration test report should give the asset owner four things: an asset inventory delta (what was found versus what was documented), a zone-and-conduit map against IEC 62443-3-2 showing where the real boundaries are, findings with both a CVSS v4.0 score and a process-consequence rating, and a remediation roadmap sequenced to maintenance windows, since most fixes cannot happen on a Tuesday afternoon. For NIS2 entities the report should also state scope and method in terms the supervisor can file.

HackersHub scopes OT engagements with the operations team from the first call. Our testers hold at least OSCP, with OSWE and CREST-certified testers on the team, and work from PTES and NIST SP 800-115 for the IT and boundary layers and from NIST SP 800-82 and IEC 62443 for the industrial layers. Controller and firmware analysis is handled on the bench through our hardware security testing practice. Michael van Mameren, Lead Penetration Tester (OSCP), signs off every OT scope, including the written list of systems that will not be touched actively under any circumstances.

The report includes an executive summary, CVSS-scored findings with evidence, an attack narrative and prioritised remediation, and a verification retest of medium and higher findings within 90 days, scheduled around your production calendar rather than ours.

Frequently asked questions

Responsible for an industrial environment?

We scope OT engagements with your operations team, test the IT boundary actively, assess the control layers without touching production, and report findings by process consequence as well as CVSS. Talk to an expert.

Scope an OT penetration test Talk to an expert