OT/ICS Penetration Testing: Safe Methods for SCADA Networks

OT/ICS penetration testing is an authorized, controlled attempt to find and prove how an attacker could reach and affect industrial control systems such as SCADA servers, HMIs, engineering workstations and controllers. Unlike an IT pentest, it puts safety and availability ahead of coverage. Testers start with architecture review and passive traffic analysis, test the IT/OT boundary and remote access only with approval, and keep live controllers out of active testing, using test benches or replicas instead. The result is a prioritized list of exposures that could cause loss of view or control of a physical process.

What Is ICS Penetration Testing?

"OT penetration testing", "SCADA penetration testing" and "ICS penetration testing" describe the same discipline at different scopes. The method in this guide is built on public guidance from NIST, CISA and MITRE, and it contains no exploit steps or commands.

An ICS penetration test simulates a realistic attacker against an industrial environment to answer one question: could someone get from where they start (the internet, a vendor connection, the corporate network) to a position where they can change or blind the process? Testers validate the paths they find with the least intrusive evidence that proves them, and they stop short of anything that could move equipment.

It is not the same as an OT security assessment. An assessment reviews architecture, configurations and policies against a standard. A penetration test adds controlled proof that weaknesses can be chained. Most good OT engagements combine both, and many begin as an assessment and earn their way to active testing.

OT, ICS and SCADA: what the terms mean

NIST's Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3 uses this broader "OT" framing and covers industrial control, building automation, transportation and physical access systems. NIST released SP 800-82 Rev. 4 as an initial public draft on September 21, 2026, with comments open through November 30, 2026; Rev. 3 remains the final version until then.

Why OT Testing Differs From IT Testing

In IT, the main concerns are usually confidentiality and integrity of data. NIST SP 800-82 Rev. 3 states that for OT the primary concerns include safety, fault tolerance and the protection of people, equipment and the environment, and that "any security measure that impairs safety is unacceptable." That one sentence changes how every phase of a test is designed.

The caution is grounded in real incidents. NIST SP 800-82 Rev. 3 records accidental events in which a simple ping sweep on an active SCADA network caused a robotic arm in standby to swing 180 degrees, and another sweep caused a semiconductor fabrication control system to hang, destroying $50,000 worth of wafers. In a third case, a penetration test of a natural gas utility's corporate IT network strayed into a segment connected to the SCADA system and locked it up, leaving the utility unable to send gas through its pipelines for four hours.

Vendor and warranty terms are a practical constraint too. NIST advises following vendor recommendations for controllers and other systems with time-dependent code, and notes that vendors may test security software only against specific supported versions. Before a test, check support agreements for anything that could be voided by installing software, changing configurations or connecting test equipment, and involve the vendor when the agreement requires it.

Why It Matters Now: Volt Typhoon and Exposed OT

The threat is no longer theoretical. In CISA advisory AA24-038A (February 7, 2024), CISA, NSA, FBI and international partners reported that the PRC state-sponsored group Volt Typhoon had compromised IT environments of critical infrastructure organizations, primarily in the Communications, Energy, Transportation Systems and Water and Wastewater Systems sectors. The agencies assessed with high confidence that the actors were pre-positioning on IT networks "to enable lateral movement to OT assets to disrupt functions," and had kept access in some victim IT environments for at least five years.

Three details from the advisory map directly onto an OT test plan:

• IT is the path to OT. The actors focused on gaining the ability to reach OT assets from IT, which is why the IT/OT boundary is the center of most OT tests.
• Default vendor credentials. They were observed testing access to domain-joined OT assets using default OT vendor credentials.
• Documentation is a target. In one compromise, they collected diagrams and documentation for OT equipment, including SCADA systems, relays and switchgear.

Attackers using simple tools are active as well. In May 2025, CISA, FBI, EPA and DOE published Primary Mitigations to Reduce Cyber Threats to Operational Technology, warning that internet-connected OT devices "are quickly found by searching for open ports on public IP ranges" and that targeted systems used default or easily guessed passwords. New product vulnerabilities also arrive constantly through CISA's ICS advisories, which list affected products, versions and vendor mitigations.

For industry-level context, see our manufacturing cybersecurity statistics and energy and utilities cybersecurity statistics.

Safety-First Rules of Engagement

The rules of engagement (RoE) are the most important document in an OT test. They decide what may be touched, when, by whom and what happens if something looks wrong. NIST's OT discussion of penetration testing (control CA-8) says testing "is used with care on OT networks," suggests a "replicated, virtualized, or simulated system" as a compensating approach, and recommends scheduling tests during planned OT outages where production systems must be involved.

About digital twins and test benches. A replica is the safest place to prove that a controller or protocol weakness is real. Its value depends on fidelity: the same firmware, configuration and logic as production. When the replica differs, label findings as "validated on bench" and confirm the production configuration by review rather than by testing.

About passive discovery. NIST explains that passive scanning adds no traffic to the network and can reveal manufacturers, part numbers and firmware versions, but it cannot see devices that are not communicating and often needs days of capture. NIST also cautions that active scans "may cause device instability or interfere with the device process state." Plan passive capture long enough to cover normal operating cycles.

The Purdue Model and IEC 62443 Zones and Conduits

Testers need a map of trust boundaries before they can test them. Two models provide it.

The Purdue model

The Purdue model organizes an industrial environment into levels, from the physical process up to the enterprise. NIST SP 800-82 Rev. 3 lists it alongside ISA-95 levels and the IIoT three-tier model as industry-recognized ways to organize OT segmentation, and recommends firewall rules that only permit connections between adjacent levels, for example preventing Level 4 devices from talking directly to Levels 2, 1 or 0.

Real plants rarely match the model exactly. Flat networks, dual-homed workstations, cellular modems and cloud connections all cut across levels, and finding those shortcuts is one of the most valuable things a test does.

IEC 62443 zones and conduits

The ISA/IEC 62443 series sets requirements and processes for secure industrial automation and control systems, shared across asset owners, product suppliers, integrators and service providers. Its parts include 3-2 (security risk assessment for system design), 3-3 (system security requirements and security levels), 2-4 (requirements for IACS service providers), 4-1 (secure product development lifecycle) and 4-2 (technical requirements for components).

CISA and partner agencies summarize the two core ideas in their August 2025 asset inventory guidance for OT owners and operators, which draws on IEC 62443-3-2:

• A zone is a grouping of logical or physical assets that share common security requirements based on factors such as criticality and consequence, for example all machines that control one production line.
• A conduit groups the cyber assets dedicated to communications between zones and ensures that only authorized traffic passes between them.

For a tester, this turns into a simple scoping rule: every conduit is a test case. For each one, confirm what traffic is allowed, whether anything else gets through, how it is monitored and whether it can be bypassed. Where an organization has set target security levels for its zones under 62443-3-3, findings can be reported against those targets instead of a generic severity scale.

The OT/ICS Penetration Testing Process

A safe OT test moves from low-risk to higher-risk activity, and each step needs the previous one to be complete. The six phases below follow that order. Use the penetration testing methodology you already know for the IT parts; the OT parts are where the safety rules apply.

1. Architecture review
2. Passive discovery
3. IT/OT boundary testing
4. Remote access and jump-host testing
5. Engineering workstation, HMI and historian testing
6. Protocol assessment at a conceptual level, proven on a bench

Phase 1: Architecture review

Start on paper. Collect network drawings, the asset inventory, firewall rule sets, remote access designs, vendor connection lists, data flows to business systems and the safety system architecture. Interview the people who run the plant, because the "as-operated" network often differs from the drawings. The Volt Typhoon advisory explicitly recommends an accurate "as-operated" OT network map that identifies IT and OT interdependencies.

Outputs: a zone and conduit map, a list of trust boundaries to test, the out-of-scope list and draft rules of engagement. Many serious findings, such as an unexpected IT-to-Level 2 route or a forgotten vendor modem, appear in this phase before a single packet is sent.

Phase 2: Passive discovery

Capture traffic from switch mirror ports or network taps in each zone and compare what you see with the inventory. CISA's asset inventory guidance treats an accurate inventory as the foundation of OT security, and passive data is how a test checks it. Look for:

• Devices that are not in the inventory, including laptops, modems and wireless bridges
• Conversations that cross zones without passing through the expected conduit
• Clear-text industrial protocols carrying commands, and who sends them
• Remote access sessions, file transfers and connections to the internet or vendor networks
• Firmware and model information that can be matched to CISA ICS advisories

Phase 3: IT/OT boundary testing

This is where most real attack paths live, and it is usually where active testing begins. With approval and inside the agreed window, test from the corporate network toward the DMZ and from the DMZ toward Level 3 and below. Confirm that only documented flows pass, that the DMZ really terminates connections rather than routing them through, and that shared services such as Active Directory, file shares, backups and antivirus or patch servers do not create a bridge.

Credentials are a large part of this phase. The Volt Typhoon actors used elevated credentials taken from IT to target OT, so check whether IT accounts or reused passwords work on OT systems and whether the OT domain trusts the corporate domain. Techniques here overlap with internal penetration testing and network penetration testing; the difference is the destination and the stop conditions.

Phase 4: Remote access and jump-host testing

Remote access is how vendors, integrators and engineers reach OT, and it is a frequent entry point. CISA's primary OT mitigations call for a private connection, a VPN with a strong password and phishing-resistant multifactor authentication, least privilege by asset and role, and disabling dormant accounts. The Volt Typhoon advisory adds that all IT-to-OT paths should pass through an intermediary such as a firewall, bastion host, "jump box" or DMZ that is closely monitored.

Test whether each of those controls holds in practice:

• Is every remote path known, including vendor-managed connections and cellular gateways?
• Is MFA enforced on every path, or can some accounts or protocols skip it?
• Can a jump-host session reach more than the specific assets it should?
• Are vendor and former-employee accounts disabled when not in use?
• Are remote sessions logged and watched, and would an operator notice an unexpected session?
• Is any OT remote access portal reachable from the public internet?

Phase 5: Engineering workstation, HMI and historian testing

Engineering workstations are the keys to the plant: they hold the software and project files used to change controller logic. HMIs give operators view and command of the process, and historians are often the most connected OT system because business users need their data. Test these hosts in a window or on replicas:

• Local and domain account hygiene, shared operator logins and administrator rights
• Whether controller programming software and project files are protected and access is logged
• Whether the historian, or its replica in the DMZ, offers a route back into Level 3 or 2
• Removable media, remote desktop and file-sharing paths that bypass the conduit design
• Whether controller logic changes would be detected; the Volt Typhoon advisory recommends integrity checks of controller logic against a known good baseline and keeping controllers out of remote program mode during operation

Phase 6: Protocol assessment at a conceptual level

Industrial protocols were mostly designed for closed, trusted networks. NIST SP 800-82 Rev. 3 notes that "many OT protocols have no authentication at any level," which creates the potential to replay, modify or spoof data, and that integrity checks are not built into most OT protocols. The assessment question is not "can we send a command?" but "what stops an unauthorized system from sending one, and would anyone notice?" Answer it with passive evidence in production and prove anything stronger on a bench.

OPC UA is a good example of why configuration matters. The OPC Foundation describes OPC UA security as a suite of controls including X.509 certificates, message signing and encryption, yet those protections only help when they are turned on and certificates are managed. CISA ICS advisories regularly include OPC UA products as well, so check versions against them.

Optional: adversary emulation in OT

Mature programs sometimes run objective-based exercises that emulate a named threat, such as reaching the engineering workstation from a phishing foothold. The same safety rules apply, and the final objective is usually demonstrated on a replica. See what red teaming is for how objective-based testing differs from a scoped pentest.

Mapping Findings to MITRE ATT&CK for ICS

MITRE ATT&CK for ICS catalogs adversary behavior against industrial systems in 12 tactics (version 20), including two that only exist in OT: Inhibit Response Function and Impair Process Control. Mapping findings to techniques helps defenders build detections and helps leadership see how findings chain together.

MITRE's technique pages describe each of these in detail, including detections and mitigations: Internet Accessible Device (T0883), External Remote Services (T0822), Valid Accounts (T0859), Remote Services (T0886), Exploitation of Remote Services (T0866), Program Download (T0843) and Modify Parameter (T0836).

New to ATT&CK? Start with how the MITRE ATT&CK framework is structured.

Reporting: What a Good OT Pentest Report Contains

An OT report has two audiences: engineers who must fix things without disrupting production, and leaders who must fund and schedule the fixes. A solid penetration testing report for OT includes:

• Scope and rules of engagement: what was tested, what was excluded and which findings were validated on a bench rather than in production
• Attack paths, not just findings: how individual weaknesses chain from a starting point to process-level access
• Operational impact: what an attacker could do to the process, such as loss of view, loss of control or unsafe set points, stated in terms operators recognize
• Safety notes: any finding that touches safety systems flagged for the safety owner
• Remediation that respects operations: fixes that can be done now, fixes that need an outage, and compensating controls until then
• Mappings: zones and conduits, IEC 62443 target security levels where defined, and ATT&CK for ICS techniques
• Asset and inventory corrections: devices and connections found that were not documented
• Retest plan: how each fix will be confirmed

Treat results like any other vulnerability management input, but with OT change management: owners, deadlines and approved maintenance windows.

What to Fix First

OT remediation competes with production schedules, so order matters. The sequence below follows CISA's primary OT mitigations and the Volt Typhoon advisory, and it puts high-impact, low-disruption fixes first.

1. Remove OT connections to the public internet. Identify public-facing assets and remove unintentional exposure.
2. Change default passwords and use strong, unique ones, starting with devices and accounts that can control the process. The Volt Typhoon advisory recommends passwords of at least 15 characters for OT assets where technically feasible, with logged compensating controls where it is not.
3. Secure remote access: private connectivity, VPN with phishing-resistant MFA, least privilege per asset and role, and no dormant accounts.
4. Segment IT and OT: deny connections into OT by default and force required flows through a monitored DMZ, jump host or firewall.
5. Protect engineering workstations and controllers: separate administrative accounts, monitor for unauthorized controller changes, baseline controller logic and lock or limit set points where possible.
6. Practice manual operation and recovery. CISA calls the ability to revert to manual control "vital" after an incident; test backups, restore steps and manual procedures.
7. Close inventory and monitoring gaps that the test exposed, so the next attacker cannot hide where the tester could.

How Often to Test OT

There is no single required cadence for every industry, so tie testing to risk and change:

• After a new IT/OT connection, remote access solution, cloud integration or vendor connection
• Before and after major upgrades, migrations or new control system deployments
• After an incident or a significant new advisory affecting your products
• When a regulator, insurer or customer requires it
• Periodically, with lighter checks such as boundary rule reviews and remote access audits between full tests

Because full OT tests are slow and careful, many organizations rotate through zones and sites rather than testing everything at once.

How to Choose an OT/ICS Penetration Testing Provider

Ask any provider, including us, these questions before you sign:

• How do you write rules of engagement, and who on our side approves each active step?
• What will you never do on a live controller or safety system?
• How do you use passive discovery, test benches and replicas, and how do you label bench-only findings?
• How do you coordinate with our system vendors and integrators?
• How do you report operational impact in terms our engineers and operators use?
• Will you map findings to our zones and conduits, IEC 62443 targets and ATT&CK for ICS?
• How is retesting handled after fixes?

Frequently Asked Questions

What is the difference between ICS and SCADA?

ICS is the broad term for systems that control industrial processes. SCADA is one type of ICS that monitors and controls assets spread over large areas, such as pipelines or power grids, from a central location. Distributed control systems (DCS) and PLC-based control are other types of ICS.

What is the difference between OT and ICS?

OT is the widest category: any programmable system that interacts with the physical world, including building automation, transportation and physical access systems. ICS is the part of OT that runs industrial processes. NIST SP 800-82 Rev. 3 uses OT as the umbrella term.

Is it safe to penetration test SCADA systems?

It can be, when the test is designed for OT. That means passive discovery first, written rules of engagement, test windows, an operator on call, stop conditions, verified backups, safety systems excluded from active testing and controller-level proof on a test bench or replica. IT-style scanning of a live SCADA network is not safe; NIST documents incidents where a ping sweep moved a robotic arm and a pentest locked up a gas utility's SCADA system.

Can you scan PLCs in production?

Avoid active scanning of production PLCs unless a named owner approves a specific, limited action in a planned window. NIST warns that active scans can cause device instability or interfere with process state. Passive traffic analysis can identify most communicating devices, including models and firmware versions, without sending traffic.

What is the Purdue model in OT security?

It is a reference model that organizes an industrial environment into levels: the physical process (Level 0), basic control (Level 1), supervisory control (Level 2), site operations (Level 3), an IT/OT DMZ (often called Level 3.5) and enterprise systems (Levels 4 and 5). Security teams use it to plan segmentation and to decide how cautiously to test each level.

What are zones and conduits in IEC 62443?

A zone is a group of assets that share the same security requirements. A conduit is the controlled communication path between zones that allows only authorized traffic. In a pentest, each conduit becomes a test case.

What does an OT penetration test cover?

Typically six areas: architecture review, passive discovery, the IT/OT boundary, remote access and jump hosts, engineering workstations, HMIs and historians, and a conceptual assessment of industrial protocols such as Modbus, DNP3 and OPC UA, with risky steps proven on a bench.

What is NIST SP 800-82?

It is NIST's Guide to Operational Technology (OT) Security. Revision 3, published in September 2023, is the current final version. Revision 4 was released as an initial public draft on September 21, 2026, with comments due November 30, 2026.

Next Step: Test Your Industrial Network Without Risking the Process

An OT penetration test is worth doing only if it is safe, so start where the risk is lowest: map your zones and conduits, run passive discovery, and check your environment against the fix-first list. Then bring in testers who will respect your rules of engagement for the active steps.

DeepStrike performs OT/ICS penetration testing. Our penetration testing services include manual testing, a detailed report with fix recommendations, re-testing to confirm fixes, an attestation letter and a technical presentation for your engineers. To discuss your environment, test windows and rules of engagement, contact DeepStrike.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

Sources and References

• NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security (September 2023)
• NIST SP 800-82 Rev. 4 (Initial Public Draft): Guide to Operational Technology (OT) Security (September 21, 2026)
• CISA, NSA, FBI and partners: AA24-038A, PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure (February 7, 2024)
• CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology (May 6, 2025)
• CISA, EPA, NSA, FBI and partners: Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators (August 13, 2025)
• CISA: ICS Advisories
• MITRE ATT&CK for ICS matrix
• ISA: ISA/IEC 62443 Series of Standards
• OPC Foundation: OPC Unified Architecture