Technical field guide
The sections below preserve the service-specific depth behind ICS Penetration Testing, edited for the current national practice and its documented engagement model. Methods are selected for the source, authorization, system state and assigned specialty. No single tool or artifact establishes a conclusion, and legal, regulatory or certification decisions remain with the responsible authority.
ICS penetration testing begins with operating authority
An industrial control system test can affect a physical process, not only data. Written scope therefore identifies the process owner, target assets, operating window, excluded actions, safety constraints, stop conditions, communications and recovery support. The test team and operators agree on what evidence will be sufficient before an active step is attempted.
Production testing is not the default proof method. Architecture review, passive traffic analysis, configuration review, a digital twin, spare hardware or a hardware-in-the-loop setup may answer the question with less operational risk. When limited validation is authorized on production, it should use the least disruptive action capable of confirming the control behavior.
IT-to-OT boundaries and remote access
Common attack paths cross identity systems, jump hosts, vendor access, dual-homed engineering workstations, firewalls and services that exchange data between enterprise and control networks. Testing maps those paths from an authorized starting position and records the credentials, network reachability and configuration conditions required at each step.
Boundary work can cover firewall enforcement, DMZ pivot resistance, jump-server controls, remote-access lifecycle, multifactor authentication, session recording, file-transfer controls and separation between administrative roles. A reachable port is not automatically an exploitable path, and a blocked test does not establish that every path is blocked. Coverage and assumptions remain explicit.
Industrial protocols and controller-facing tests
Protocols such as Modbus TCP, DNP3, EtherNet/IP, OPC UA, PROFINET, BACnet and IEC 61850 have different security models and deployment histories. Some implementations rely heavily on network trust; others support authentication, signing or encryption that may be disabled or misconfigured. Tests must be protocol-aware and tied to the actual device, firmware and configuration.
Potential checks include unauthorized reads, restricted writes against a test instance, command replay, certificate and trust configuration, role enforcement, session handling and protocol exposure across a zone boundary. Controller writes, state changes, flooding and denial-of-service activity require explicit approval and ordinarily belong in an isolated environment.
Lab, digital twin and hardware-in-the-loop validation
A replica can support deeper testing without placing a live process at risk, but it is evidence about the replica. The report documents how topology, logic, firmware, configuration and hardware differ from production. Findings are then expressed as tested behavior plus the conditions that would need to match before the same path could affect the live system.
Hardware-in-the-loop work can test real controllers, HMIs or gateways with simulated process inputs. A digital twin can support attack-path and control validation at broader scale. Neither removes the need for careful configuration comparison, operator review and a controlled remediation plan.
Evidence, remediation and retesting
Each reported finding identifies the authorized path, preconditions, evidence, operational consequence, safety considerations and affected assets. Remediation may involve segmentation, identity controls, remote-access changes, protocol allow-listing, configuration hardening, monitoring, a vendor fix or equipment replacement. Retesting uses the original path and records whether the control removed, reduced or merely displaced the exposure.