Can SCADA testing be done without disrupting operations?

Yes. GDF's SCADA assessments use a passive-first approach that collects and analyzes network traffic without generating any probe packets that could affect operational technology systems. Active testing, where used, is limited to IT-side components and is conducted during agreed maintenance windows in coordination with operations staff. GDF Miami never actively scans PLCs or RTUs without explicit approval and documented safety planning.

What regulations require ICS security assessments?

NERC CIP standards require cybersecurity assessments and vulnerability management for bulk electric system assets. The EPA and America's Water Infrastructure Act require water utilities to conduct risk and resilience assessments covering cybersecurity. TSA cybersecurity directives require pipeline operators to implement testing and validation programs. CFATS covers high-risk chemical facilities. Nuclear operators must comply with NRC 10 CFR 73.54 cybersecurity requirements. GDF's assessments are structured to produce findings that map directly to these frameworks.

How are SCADA systems different from IT systems?

SCADA and ICS systems prioritize availability and deterministic performance over confidentiality, use specialized industrial protocols not found in IT networks, often run on hardware and operating systems that cannot be patched or replaced on IT timescales, and control physical processes where failures can cause safety incidents or environmental damage. These differences require assessment methodologies, tools, and timing that are specifically designed for operational environments rather than adapted from standard IT security practices.

What are the most common SCADA vulnerabilities?

The most frequently identified SCADA vulnerabilities include inadequate IT/OT network segmentation that allows lateral movement from corporate systems to control networks, default or shared credentials on engineering workstations and HMIs, unencrypted industrial protocol traffic carrying commands and data, uncontrolled vendor remote access with persistent always-on connections, and engineering workstations running end-of-life operating systems that cannot receive security patches.

Operational Technology

SCADA Security Testing Under a Safe-Testing Protocol

Testing a SCADA environment badly is worse than not testing it at all. Aggressive scanning crashes legacy controllers, active exploitation against a live process loop is a safety event, and generic pentest methodology misprioritizes findings that never reach the plant’s consequential logic. Testing scoped to the environment, executed under a joint safe-testing protocol, produces the record the operator, the regulator and the insurer actually need.

What SCADA Testing Actually Delivers

Exploitable-finding list on components that actually matter. Findings that reach the HMI, the historian, the engineering workstation, the RTU population or the specific communications paths the plant relies on. Not scanner alerts on unreachable devices.
Communications-integrity assessment. Whether the paths between HMI, historian, RTUs and field devices actually authenticate the origin of the commands and telemetry they carry, or whether they trust the network to enforce that boundary.
Reproducible test cases the engineering team can re-run. Every finding is documented with the specific inputs, the observed behavior and the isolated environment in which it was reproduced.
Remediation aligned to the operational calendar. Recommendations sequenced against the operator’s actual change windows and firmware-upgrade cadence, with compensating controls documented for gaps that cannot be closed inside the current cycle.
Regulator- and insurer-ready documentation. Reports structured so the record maps directly into the applicable compliance framework.

The Safe-Testing Protocol

Every SCADA engagement runs under a joint safe-testing protocol agreed with the operations team before testing starts. The protocol is documented, signed and rehearsed, and it is treated as the authoritative rule set for the engagement.

Passive discovery first. Continuous network observation and asset inventory carry the discovery load. Active testing is reserved for specific findings that require confirmation.
Isolated environment for active testing where feasible. Mirrored HMI, historian, engineering workstation and RTU pairs configured to match the production environment’s software and firmware state. Active exploitation runs against the mirror, not against the live process.
Authorized windows for any live-environment active testing, with the operations team on standby, rollback plans documented and tested, and specific abort conditions defined in advance.
Safety-instrumented-system exclusion by default. Nothing goes into or against an SIS without engineering review and explicit written authorization, and never during operations.
Vendor coordination where the test may involve firmware-level interaction with a specific device family, so the vendor is aware and can support the operator if any unexpected behavior emerges.

What SCADA Testing Actually Covers

HMI security

Application-level testing of the HMI itself: authentication and session handling, authorization boundary enforcement between operator and engineering roles, input handling on operator-facing forms, and the security of the paths through which the HMI reaches the historian and the engineering environment.

Historian security

Testing of the historian tier for its role as a bridge between OT and IT, including the authentication of writes to the historian, the authorization of reads back into OT, and the specific integrations that reach into enterprise IT reporting and analytics platforms.

Engineering workstation security

Testing focused on the engineering workstation as one of the highest-consequence positions in the OT environment: whoever controls the engineering workstation controls the programming path into the controllers. Authentication, application allow-listing, USB and removable-media handling, and the trust relationships the workstation has with the vendor tooling.

RTU and controller security

Testing scoped to the specific device families deployed in the environment, under the safe-testing protocol. Firmware version identification, known-defect enumeration, communications-integrity testing, and controlled interrogation of the device-specific management interfaces.

Communications-integrity testing

The SCADA protocol landscape (DNP3, Modbus, IEC 61850, IEC 60870-5, BACnet, OPC UA) carries a spectrum of authentication and integrity models, from none to strong. Testing focused on whether the deployed configuration actually enforces the model the operator believes is in place, and on the specific spoofing, injection and replay attacks each protocol’s deployed configuration is vulnerable to.

Remote-access and vendor-access paths

Testing of the paths through which vendors, integrators and remote engineering staff reach the OT environment. Authentication strength, session logging, network scope of the granted access, and the specific privileges each granted identity actually receives once inside.

Case in point

Wastewater SCADA testing that surfaced a spoofed-setpoint vulnerability

A South Florida wastewater utility engaged us for a SCADA security assessment across the treatment-plant control environment and the remote-site telemetry that supported it. Testing ran under a joint safe-testing protocol agreed with the operations team: passive discovery first, active testing only in an authorized isolation window against a mirrored HMI and RTU pair, and no active testing of any device connected to a live process loop.

Testing in the isolation environment identified a communications-integrity gap on the specific RTU-to-HMI path used by a subset of the remote sites. The path used a widely-deployed SCADA protocol in a configuration that did not authenticate the origin of setpoint-change commands. Under the isolated test, a spoofed command originating from a network position adjacent to the RTU could induce the HMI to display and accept a setpoint change that had not been issued by an authenticated engineering session. The failure mode was consistent with published research on the protocol family but had not been raised by the vendor for the specific device generation in play.

The report documented the reproducible test, the specific communications path affected, and the remediation options (authenticated protocol variant available on newer firmware, or compensating-control routing through an authenticated gateway for the current firmware). The utility elected the compensating-control path with a scheduled firmware upgrade during the next approved change window. The follow-up test in the isolation environment confirmed the compensating control blocked the spoofed-setpoint attack, and the subsequent firmware upgrade closed the underlying gap.

Full Critical Infrastructure Cybersecurity Compliance

SCADA testing is one component of the full Critical Infrastructure Cybersecurity Compliance suite our Miami practice delivers, alongside continuous vulnerability management, network assessment, forensic incident response and program-level compliance work. Testing scope, methodology and reporting are anchored on the specific framework the operator is accountable to (NERC CIP, TSA Security Directives, EPA Cybersecurity Rule, USCG MTSA, IEC 62443, and the sector-specific standards each environment carries) so the testing record slots into the operator’s compliance posture.

Testing findings map into the specific framework the operator is accountable to: NERC CIP for bulk electric system entities, TSA Security Directives for pipeline and rail, EPA Cybersecurity Rule for public water systems, USCG MTSA cyber requirements for MTSA-regulated port and vessel facilities, IEC 62443 for industrial automation, and sector-specific standards where they apply. The remediation record is structured to slot into the compliance file rather than require translation.

Where Our Miami SCADA Practice Runs Deepest

Water and wastewater utilities

Treatment-plant and distribution SCADA, remote-site telemetry, and the specific protocol families common in the water sector. EPA Cybersecurity Rule alignment, AWWA G430 and J100 framing.

Power and generation

Substation SCADA, generation control, IEC 61850 environments, and behind-the-meter cogeneration environments. NERC CIP alignment for bulk electric system entities.

Port and maritime SCADA

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

Manufacturing, cold-chain and cruise-line shore facilities

Process SCADA for pharmaceutical, food-and-beverage and cold-chain manufacturing environments, and for cruise-line shore-facility support environments.

Airport and aviation-adjacent SCADA

Airport ground systems, fuel and de-icing infrastructure, and terminal building-automation SCADA. Coordinates with the aviation cybersecurity practice on airworthiness-adjacent scope.

Standards and Standing

Methodology anchors on NIST SP 800-82 Rev.3, IEC 62443, the ISA/IEC Purdue Enterprise Reference Architecture, and the sector-specific standards each operator is accountable to. Testers hold GICSP, GRID, OSCP, GXPN and CISSP among other credentials, and have specific practical experience with the protocol families and device generations in 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 litigation or regulatory proceedings.

Last updated: September 4, 2026

SCADA Testing That Respects the Plant

Passive discovery, isolated-environment active testing, and joint safe-testing protocol discipline. Findings anchored on what actually reaches the plant’s consequential logic. Reports written for the operator, the regulator and the insurer.

Request Consultation Call (786) 219-1210