OT Penetration Testing

Also known as:OT Pentest · ICS Penetration Test · SCADA Penetration Test

OT Penetration Testing is the authorized security assessment of operational technologyOperational TechnologyHardware and software used to monitor or control physical equipment, machinery, and industrial processes. environments — SCADA systems, distributed control systems (DCS), programmable logic controllers (PLCs), human-machine interfaces (HMIs), and the industrial protocols that connect them. The goal is to identify exploitable weaknesses in systems that control physical processes before an adversary can leverage them to cause operational disruption, safety incidents, or environmental damage.

Unlike conventional IT pentests, OT assessments operate under strict safety constraints: a misplaced packet on a Modbus segment can halt a production line or trigger a safety shutdown. This demands specialized knowledge of industrial protocols, process safety, and the operational context of every device under test.

Who commissions this test?

OT penetration tests are typically commissioned by plant managers, OT security officers, or CISOs in organizations that operate industrial infrastructure. In practice, the request often originates from compliance or risk management departments responding to regulatory requirements such as the German IT-Sicherheitsgesetz, the EU NIS2 Directive, or sector-specific standards like IEC 62443. In critical infrastructure (KRITIS) sectors — energy, water, manufacturing, transportation — plant operations leadership and the OT security team usually co-own the engagement.

Test objectives

The primary objectives are to assess the resilience of industrial control systems against targeted cyberattacks, to evaluate network segmentationNetwork SegmentationSeparates network segments to control access and limit lateral movement. between IT and OT zones, and to identify attack paths that could allow an adversary to move from corporate IT into production networks. Secondary objectives often include validating detection capabilities in OT-specific monitoring tools and verifying that safety instrumented systems (SIS) cannot be undermined through network-based attacks.

What is tested?

Testing covers the full OT stack: SCADA servers and historian databases, DCS controllers, PLCs and remote terminal units (RTUs), HMIs and engineering workstations, as well as the industrial protocols binding them together — Modbus TCP/RTU, OPC UA and OPC DA, PROFINET, DNP3, BACnet, EtherNet/IP, and IEC 60870-5-104. Network infrastructure within the OT zone (managed switches, industrial firewallsFirewallControls network traffic based on defined rules and security policies., data diodes), remote access gateways, and the IT/OT demilitarized zoneDemilitarized ZoneA separate network segment for publicly accessible services located between internal and external networks. are also in scope. Where applicable, wireless field networks (WirelessHART, ISA100.11a) and serial-to-Ethernet converters are assessed.

Common findings

  • Default or factory credentials on PLCs, RTUs, and HMIs that were never changed after commissioning
  • Flat networks with no segmentation between IT and OT, or between safety and control zones
  • Industrial protocols running without authentication or encryption (Modbus, OPC DA, BACnet)
  • Outdated firmware on controllers that cannot be patched because of production uptime requirements
  • Legacy Windows systems (XP, Server 2003) running HMI or historian software in OT zones with no compensating controls
  • Exposed engineering workstations with direct PLC programming access from the corporate network
  • Insecure remote access — VPNVirtual Private NetworkProvides an encrypted tunnel over an untrusted network. or RDP tunnels into OT segments with weak authentication and no multi-factor
  • Missing or misconfigured OT-specific intrusion detection
  • Unmonitored USB ports on HMIs and engineering stations

Typical engagement workflow

Initial inquiry — The organization reaches out, often prompted by a regulatory audit, an incident at a peer company, or an upcoming IEC 62443 certification. The pentesting team gathers high-level information about the industrial environment, sector, and regulatory context.

Scoping conversation — A detailed discussion with plant management, OT security, and IT security to understand the industrial processes, criticality levels, acceptable risk during testing, and any safety constraints. This step is critical: the tester must understand which actions could affect physical safety.

Proposal and approval — A formal proposal is drafted that specifies the testing approach, explicitly lists prohibited actions (e.g., writing to PLC registers, modifying safety controller logic), and defines the maintenance windows available for active testing. The proposal is reviewed by plant management, OT engineering, and legal.

Scope definition — Systems, network segments, protocols, and physical locations are documented. OT pentests often define a tiered scope: passive reconnaissance against the full OT network, active scanning limited to non-critical segments, and controlled exploitation only on designated test systems or during planned maintenance windows.

Letter of engagement — Signed authorization covering legal protection, emergency contacts, and a safety stop procedure. In OT environments, this document typically includes a dedicated safety escalation chain and an immediate halt protocol.

Additional authorizations — If cloud-connected SCADA or remote monitoring platforms are in scope, provider-specific testing permissions are obtained.

Information exchange — Depending on the Black-Box, Gray-Box, or White-Box approach, the client provides network diagrams, asset inventories, protocol documentation, firmware versions, and access to engineering workstations. Gray-Box is the most common approach in OT because purely blind testing carries unacceptable safety risk.

Kick-off call — Final alignment with all stakeholders: plant operators, shift supervisors, OT engineering, IT security, and the pentest team. Emergency procedures, communication channels, and the testing schedule are confirmed.

Execution — Testing typically begins with passive network analysis (traffic capture, protocol identification, asset discovery) before progressing to active probing during agreed maintenance windows. The pentest team maintains continuous communication with plant operations. Any anomaly is immediately reported. Safety-critical systems are tested only with explicit real-time approval from operations staff.

Vulnerability assessment and rating — Findings are collected, verified, and rated using frameworks appropriate to OT environments (e.g., CVSS with environmental metrics reflecting OT impact, or IEC 62443 security levels).

Final report — The report documents each finding with technical evidence, an assessment of operational and safety impact, and actionable remediation guidance tailored to OT constraints (where patching may not be feasible, compensating controls are recommended).

Presentation — Results are presented to stakeholders including plant management, OT engineering, IT security, and executive leadership. The presentation translates technical findings into operational risk language.

Project closure — Lessons learned, remediation timelines, and recommendations for follow-up testing or monitoring improvements are agreed.

Who should commission this test — and when?

Operators of critical infrastructure — energy generation and distribution, water and wastewater utilities, manufacturing, chemical processing, transportation — are the primary audience. In Germany, KRITIS operators face explicit obligations under the IT-Sicherheitsgesetz and BSI-Kritisverordnung. The NIS2 Directive extends similar requirements across the EU. IEC 62443 compliance programs require periodic security assessments of industrial automation and control systems.

OT pentests should be performed after significant OT network changes, new SCADA or DCS deployments, integration of IT and OT networks, migration from serial to Ethernet-based protocols, and on a regular cycle (annually or biannually). A first-time assessment is especially valuable after years of organic growth where security was secondary to operational availability.

  • Operational TechnologyOperational TechnologyHardware and software used to monitor or control physical equipment, machinery, and industrial processes.: The hardware and software that monitors and controls physical processes and industrial equipment.
  • OT SecurityOperational Technology SecurityProtects industrial control, production, and process control systems.: The discipline of protecting industrial control systems and operational technology from cyber threats.
  • Penetration TestingPenetration TestingAuthorized, methodical testing of a system for exploitable weaknesses, to find them before real attackers do.: Authorized, methodical testing of systems for exploitable weaknesses.
  • Network SegmentationNetwork SegmentationSeparates network segments to control access and limit lateral movement.: Dividing a network into isolated zones to limit lateral movement and contain breaches.
  • BACnet SecurityBACnet SecurityProtection of BACnet communication in building automation and control systems.: Security mechanisms and vulnerabilities specific to the BACnet building automation protocol.