Can ICS penetration testing be done safely on live production systems?

Active exploitation against live production ICS assets is generally not appropriate because a failed or uncontrolled exploit can cause safety incidents, process shutdowns, or equipment damage. GDF Miami conducts ICS penetration testing through three safe environment methodologies: digital twin testing (software simulation of the target environment), hardware-in-the-loop testing (physical PLCs and RTUs in an isolated lab), and isolated test networks using decommissioned production equipment. These approaches allow thorough, aggressive exploitation testing while ensuring zero risk to live operations. Limited active reconnaissance on the production network may be conducted during agreed maintenance windows with explicit written approval from operations and safety teams.

What is a digital twin penetration test for ICS?

A digital twin penetration test replicates the target ICS environment in software simulation, accurately modeling the production network topology, protocol configuration, PLC logic, and HMI setup. GDF's testers execute the full attack kill chain against this virtual replica, including protocol-specific exploitation techniques that would be unsafe to use against live equipment. Findings are documented with sufficient technical detail to confirm that the same exploitation path would succeed against the corresponding production system. Digital twin testing enables destructive exploit scenarios too risky for live environments, allows multiple test iterations without scheduling production downtime, and can accommodate scenarios that model future architecture changes before they are deployed.

How is ICS penetration testing different from standard IT penetration testing?

ICS penetration testing differs from IT penetration testing across every dimension. The primary constraint is that the test must not cause the harm it is meant to simulate protecting against: a failed exploit on a live PLC controlling a chemical reactor or power grid segment can cause a safety incident, not just a crashed server. ICS environments have zero tolerance for production disruption, run legacy hardware that cannot be patched on IT timescales, and use specialized industrial protocols including Modbus, DNP3, OPC UA, EtherNet/IP, PROFINET, BACnet, and IEC 61850 that require separate expertise. Testing requires coordination with security teams, operations staff, control engineers, and safety officers. Findings are evaluated not just for CVSS score but for operational impact on physical processes. Remediation recommendations include compensating controls for the significant proportion of ICS vulnerabilities that cannot be patched.

What industrial protocols does GDF Miami test during an ICS penetration test?

GDF Miami tests the range of industrial protocols encountered in operational technology environments. Modbus TCP and RTU testing covers unauthenticated read and write commands to coils and registers, memory map enumeration, and replay attacks. DNP3 testing addresses master station spoofing, unauthorized outstation control, unsolicited response flooding, replay attacks, and Secure Authentication weaknesses. OPC UA testing covers authentication bypass, certificate trust abuse, session hijacking, and access control misconfigurations. EtherNet/IP and CIP testing covers CIP command injection and unauthorized PLC programming via native CIP commands. PROFINET testing covers DCP enumeration and device manipulation. BACnet testing covers property read and write without authentication. IEC 61850 and GOOSE testing, which is especially hazardous on live systems, is conducted exclusively in isolated lab environments with relay test sets.

Operational Technology

ICS Penetration Testing for Airport, Port, Utility and Manufacturing Environments

ICS penetration testing is not IT pentest with different targets. It is a distinct discipline anchored on safe-testing protocol, operational-calendar coordination, and the specific attack surface each ICS environment actually carries. Testing that respects the plant, executed against the environments that matter most (airport ground systems, port terminals, utilities, manufacturing) and reported for the audiences that will have to act on the record.

What ICS Pentest Actually Delivers

Reachable exploit paths from realistic starting positions. The interesting question is what an attacker with a specific starting position (compromised IT foothold, compromised vendor account, opportunistic maintenance access, physical proximity) can actually reach in the ICS environment.
Chained findings, not device-by-device lists. High-consequence outcomes in ICS environments almost always require chaining. The report presents the reachable outcomes and the chains that produce them, not a scanner-style catalog.
Architectural remediation guidance. Findings closed at the architectural level survive vendor firmware changes and personnel turnover. Findings closed by device-level configuration have to be maintained forever.
Compliance-ready documentation. Reports structured so the record supports the specific framework the operator is accountable to (NERC CIP, TSA, EPA, USCG MTSA, FAA and EASA cybersecurity guidance, IEC 62443 or the applicable sector standard).
Testimony-ready analyst. The tester who performed the work is available for the operator’s regulator engagement, board reporting or any subsequent litigation matter.

Why ICS Pentest Is Not IT Pentest

Safety constraints are non-negotiable. Any test that can affect a live process is out of scope by default, and comes back in only under an explicit safe-testing protocol with engineering review, operations awareness and defined abort conditions.
Legacy devices are fragile. Standard active-scanning techniques crash controllers that have been running continuously for a decade. Discovery leans on passive observation, and active interrogation is scoped to devices documented to tolerate it.
Operational calendars govern the test. Testing runs in windows the operator can authorize, coordinated with the change process the environment already follows.
Consequence framing is different. A finding that reaches setpoint-write capability on a specific PLC is more consequential than a finding that produces a domain-admin equivalent on an isolated engineering workstation. Ranking that reflects this reality requires ICS-specific consequence modeling.
Compliance framing is different. The applicable framework, the audit expectations and the acceptable evidence formats differ from IT. Reports structured against the operator’s specific framework produce a defensible record.

Methodology

Written scoping covering the environment, the starting positions to be simulated, the specific attack objectives, the safe-testing protocol and the abort conditions.
Passive discovery anchoring the reachable-inventory picture and the communication-profile baseline.
External and IT-boundary testing from the simulated starting position, escalating toward the OT boundary.
Boundary crossing under safe-testing protocol where the attack chain reaches into the OT environment, with active exploitation scoped to devices and paths the protocol authorizes.
OT-internal testing against the specific devices and paths the environment carries, with active testing on isolated-mirror environments where feasible and live-environment testing only under the authorized-window protocol.
Chain construction and consequence modeling against the specific plant architecture, safety instrumentation and process-critical logic.
Reporting and remediation guidance anchored on architectural change first, device-level change second.
Verification testing after remediation, using the same reachability chains that surfaced the original findings.

Protocol-Specific Testing

Testing scope adapts to the specific protocol families deployed. Each protocol carries a distinct authentication and integrity profile in the field, and the useful test is anchored on the deployed configuration rather than the protocol’s theoretical capability.

Modbus (TCP, RTU, ASCII): the widest-deployed protocol family and the one most often deployed without authentication. Injection, replay and spoofing testing anchored on the specific reachable positions.
DNP3: secure authentication support present in the standard, deployed in a subset of environments. Testing focused on whether the deployed configuration actually enforces authentication or whether it is running in the legacy unauthenticated mode.
IEC 61850: substation and generation environments. GOOSE and SV traffic integrity testing, MMS access-control testing, and the specific attack surface of the deployed IED families.
IEC 60870-5-104: utility and telecontrol environments outside the North American substation profile. Testing anchored on the deployed configuration.
OPC UA: newer deployments with rich authentication and integrity support. Testing focused on whether the deployed configuration actually uses the security profile the standard supports.
OPC Classic: legacy DCOM-based environments still present in many plants. Testing anchored on the DCOM attack surface and on the specific paths through the OPC gateway.
BACnet: building-automation environments, including the OT-adjacent building automation in industrial, port, airport and healthcare facilities.
Proprietary and vendor protocols: Rockwell, Siemens, Schneider, ABB, Emerson and other vendor-specific protocol families. Testing anchored on the specific vendor family in play.

Case in point

FAA-adjacent airport ground-systems pentest chained from maintenance interface to operations

A South Florida airport operator retained us for a scoped penetration test of the ground-systems control environment supporting a specific terminal apron. The environment included aircraft ground support systems, apron building-management systems, fuel-distribution monitoring, and the operator-side portion of the passenger boarding bridge control networks. The engagement was scoped against the applicable airworthiness cybersecurity framework and against the operator’s TSA and airport-security obligations, with a joint safe-testing protocol agreed with the operations team and with the aviation authority representatives who had oversight of the airworthiness-adjacent scope.

Passive discovery identified a maintenance interface on one class of ground-support device that was reachable from a specific portion of the operator’s enterprise IT network. The interface used a documented default credential set that the vendor had not rotated during commissioning. Under the safe-testing protocol, controlled interrogation of the interface confirmed authenticated access, and mapping from that position identified a communications path into a segment carrying the apron building-management traffic. A subsequent finding on the building-management gateway (a certificate-validation gap that had been publicly reported for the vendor’s device family but had not been remediated) permitted controlled onward access to the operator-side portion of the passenger boarding bridge network segment.

Active exploitation stopped at the boundary of any system with potential airworthiness-adjacent impact, per the protocol. The report documented the reachable path from the enterprise IT foothold through the maintenance interface to the airworthiness-adjacent segment, and the specific architectural and configuration changes required to close each step. Remediation was executed across the following two change windows: default credentials rotated on the maintenance interface, network segmentation rebuilt at the enterprise-to-ground-systems boundary, and the building-management gateway firmware updated to the version that addressed the certificate-validation gap. The subsequent verification test confirmed each step was closed, and the report and remediation record were preserved for the airworthiness authority’s subsequent review.

IT/OT Boundary Penetration Testing

The IT/OT boundary is where most consequential ICS pentest findings live. Testing scoped to the boundary specifically (the DMZ, the historian tier, the engineering workstation, the vendor remote-access paths, and the maintenance jumphosts) surfaces the paths through which an IT-side compromise reaches the OT environment. The output is architectural: which changes to the boundary produce a defensible posture, and which do not.

FAA and EASA Airworthiness Cybersecurity Pentest

Aviation-adjacent OT (airport ground systems, connected avionics support systems, aircraft ground support equipment) carries a specific cybersecurity certification framework applicable to the airworthiness pathway the systems support. Testing is structured against the evidence expectations of the applicable certification authority so the report slots into the airworthiness submission rather than sitting alongside it.

FAA guidance: AC 119-1 and the airworthiness authority’s Cybersecurity Aircraft System Information Security Protection (ASISP) framework where applicable.
EASA guidance: ED-202A and ED-203A (RTCA DO-326A and DO-356A equivalents) covering airworthiness security process and methods.
Coordination with the aviation authority representatives where the scope reaches into airworthiness-adjacent systems, including scope definition, safe-testing protocol review, and evidence-format expectations.
Ground-support and airport-facility scope tested under the same discipline as any critical-infrastructure environment, with airworthiness-adjacent portions escalated per the certification framework.

Full Critical Infrastructure Cybersecurity Compliance

ICS penetration testing sits alongside continuous vulnerability management, network assessment, SCADA testing and post-incident forensics as arms of the full Critical Infrastructure Cybersecurity Compliance suite our Miami practice runs for critical-infrastructure operators. Testing engagements are scoped against the specific framework each operator is accountable to (NERC CIP, TSA Security Directives, EPA Cybersecurity Rule, USCG MTSA cyber requirements, FAA and EASA airworthiness cybersecurity guidance for aviation-adjacent scope, IEC 62443, and sector-specific standards) so the pentest record supports the operator’s compliance posture rather than sitting alongside it.

Pentest findings and the associated remediation record map into the specific framework the operator is accountable to, so the record supports both the immediate remediation cycle and the compliance file for the subsequent examination.

Where Our Miami ICS Pentest Practice Runs Deepest

Airport ground systems and aviation-adjacent OT

Airport operator engagements scoped against FAA and EASA cybersecurity guidance, including apron building-management, fuel and de-icing infrastructure, aircraft ground support equipment, and passenger boarding bridge control networks on the operator side.

Port and maritime

Terminal operating systems, crane and gantry control, gate systems, and MTSA-scoped facility environments. USCG MTSA cyber requirement alignment.

Water, wastewater and power

Utility ICS pentest scoped against EPA Cybersecurity Rule (water and wastewater) and NERC CIP (bulk electric system) as applicable, with joint safe-testing protocol executed with the operator’s operations and reliability compliance teams.

Manufacturing, cold-chain and cruise-line shore facilities

Process ICS pentest for pharmaceutical, food-and-beverage and cold-chain manufacturing environments, and for cruise-line shore-facility support environments. IEC 62443 alignment.

Traffic and infrastructure protection testing

Traffic management systems, connected infrastructure, tolling and access-control environments tested with the same discipline, with reporting sequenced against the operational calendar the site actually runs on.

Standards and Standing

Methodology anchors on NIST SP 800-82 Rev.3, IEC 62443, MITRE ATT&CK for ICS, the ISA/IEC Purdue Enterprise Reference Architecture, and the sector-specific standards each operator is accountable to. Testers hold GICSP, GRID, OSCP, OSWE, GXPN and CISSP among other credentials, with specific practical experience in the ICS protocol families and vendor device generations relevant to the environment under test. Reports are structured for authentication under Fla. Stat. § 90.901 and Federal Rules of Evidence 902(13) and 902(14) where the record may later be produced in regulatory or litigation proceedings, and the tester who performed the work is available for deposition and testimony.

Last updated: September 4, 2026

ICS Testing That Respects the Plant

Safe-testing protocol, chained-outcome reporting and architectural remediation guidance. Executed against the environments that matter most: airport ground systems, port terminals, utilities and manufacturing.

Request Consultation Call (786) 219-1210