OT/ICS/SCADA penetration testing assesses the security of the systems that run physical processes — PLCs, controllers, SCADA servers and HMIs — where a mistake can halt production or endanger people. The defining discipline is safety and availability first: we lead with passive techniques on production-critical layers, restrict active exploitation to replicas or maintenance windows, and agree stop conditions before we start. Testing is structured around the Purdue Model and aligned to IEC 62443, NIST SP 800-82 Rev 3 and, for Saudi operators, the NCA OTCC (penetration testing control 2-10). It is essential for energy, oil & gas, utilities, water and manufacturing — the sectors where cyber risk becomes physical risk, as Triton, Industroyer and Stuxnet each demonstrated.
// 01 What is OT/ICS/SCADA penetration testing?
OT/ICS penetration testing is a safety-first security assessment of the operational technology that controls physical processes — the programmable logic controllers (PLCs), remote terminal units, SCADA servers, human-machine interfaces (HMIs) and industrial networks found in refineries, power stations, water plants and factories. Its purpose is to find the weaknesses an attacker could use to disrupt or manipulate a physical process, and to prove that risk without ever causing the disruption itself.
That last point is the whole discipline. In enterprise IT, a penetration test can crash a server and everyone shrugs. In OT, the same mistake can stop a production line, trip a substation, or interfere with a safety system that exists to prevent an explosion. So OT testing is governed by a single rule — demonstrate risk, don't cause disruption — and every technique is chosen to respect the physical process behind the network.
// 02 How is OT penetration testing different from IT?
The priorities invert. IT security ranks confidentiality first; OT ranks safety and availability first, because the consequence of failure is physical. That single change reshapes the entire methodology.
| Dimension | IT penetration testing | OT / ICS penetration testing |
|---|---|---|
| Top priority | Confidentiality | Safety & availability |
| Default technique | Active scanning & exploitation | Passive-first (traffic mirroring, no transmit) |
| Active testing venue | Production is normal | Replicas, test benches, or maintenance windows |
| Legacy systems | Patched routinely | Decade-old PLCs that a scan can crash |
| Stop conditions | Rarely needed | Defined and agreed before testing starts |
| Tester credentials | OSCP, CREST | GICSP, IEC 62443, SANS ICS knowledge |
In practice this means an OT engagement opens by passively mapping the network — copying traffic through a SPAN port or tap to inventory assets, protocols and communication flows without sending a single packet to a controller. Active testing, where it happens at all, is scheduled into planned outages with operations staff present, or performed against a duplicate of the environment. An ordinary Nmap scan has been enough to knock legacy controllers offline, so nothing touches a production-critical device without deliberate, agreed justification.
// 03 The Purdue Model: how a test traverses IT to OT
OT networks are segmented using the Purdue Model, which layers the environment from the physical process up to enterprise IT. A realistic OT penetration test models the attacker's path through these layers — and the single most important control it evaluates is whether the boundary between IT and OT actually holds.
| Level | Layer | What lives here |
|---|---|---|
| L0 | Physical process | Sensors, actuators, valves, motors |
| L1 | Basic control | PLCs, RTUs, IEDs, Safety Instrumented Systems (SIS) |
| L2 | Supervisory control | SCADA servers, HMIs, engineering workstations |
| L3 | Site operations | MES, historians, batch systems |
| L3.5 | Industrial DMZ (IDMZ) | The IT/OT boundary — jump hosts, data diodes, patch relays |
| L4–L5 | Business & enterprise IT | ERP, corporate network, cloud, internet |
The engagement typically models a foothold in enterprise IT (L4/L5), then tests whether an attacker can pivot through the industrial DMZ at Level 3.5 and descend into L3, L2 and ultimately the controllers at L1. A well-designed IDMZ means there is no direct path from the business network to the control layer — and proving or disproving that is the heart of the test. The deeper the level, the more the methodology shifts to passive-only. Colonial Pipeline illustrated the model's logic in reverse: the operator shut the pipeline because an intrusion in IT left them unable to be certain it had not reached OT.
// 04 Which standards govern OT security testing?
OT testing is anchored to a small set of established standards, and mapping findings to them is what makes a report useful to an auditor or regulator.
The primary OT standard
A zones-and-conduits model with four security levels (SL1 casual through SL4 nation-state). Part 3-3 defines 100+ system requirements under seven foundational requirements; part 3-2 covers risk assessment.
Guide to OT Security (Rev 3)
The 2023 revision broadened scope from ICS to all OT and codifies that testing methods must respect operational and safety constraints.
Saudi OT controls
OTCC-1:2022 — 4 domains, 23 subdomains, 47 controls. Penetration testing sits at control 2-10 in the Cybersecurity Defense domain. Mandatory for critical national infrastructure operators.
North American utilities
Mandatory, enforceable controls for the Bulk Electric System — electronic security perimeters, systems security management and recovery.
For Saudi operators specifically, the OTCC applies to government entities and private-sector operators of critical national infrastructure, with a Facility Identification Tool assigning heavier obligations to higher-impact sites. Vendors accessing OT environments often also need to satisfy Saudi Aramco's SACS-002 and SABIC's CyberTrust supply-chain requirements. We map every finding to the OTCC control references your assessor expects — and to the parallel NCA ECC where it applies.
// 05 Which protocols and weaknesses do we test?
Most OT protocols were designed decades ago for isolated, trusted networks, so many lack authentication, encryption and integrity checking by design. That is not a bug to be patched — it is the environment, and testing has to account for it.
| Protocol | Typical use | Security posture |
|---|---|---|
| Modbus (TCP/RTU) | Most widespread PLC/sensor protocol | No auth, no encryption by design |
| DNP3 | Electric & water utilities | Insecure by default without Secure Authentication |
| EtherNet/IP (CIP) | Manufacturing (Rockwell) | Older versions lack authentication |
| PROFINET | Siemens / European automation | Trusts link devices; spoofable on a flat segment |
| S7comm | Siemens S7 PLCs | Proprietary; historical RCE/DoS, weak auth |
| OPC-UA | Modern interoperability | Secure if configured — only in SignAndEncrypt mode |
| IEC 60870-5-104 | European power substations | No native security; abused by Industroyer |
// 06 Common OT vulnerabilities and what they've caused
The weaknesses we find most often are rarely exotic. They persist because OT systems live for decades and sit in the seams between engineering and IT.
Flat networks & a weak IT/OT boundary
Little segmentation between control layers, or an industrial DMZ eroded by remote-access and monitoring exceptions — a single IT foothold reaches the controllers.
Default & shared credentials on PLCs/HMIs
Vendor defaults and shared engineering passwords with no MFA on devices that can reprogram the physical process.
Vendor VPNs & legacy remote support
Always-on remote-support tooling and vendor VPN accounts — the exact vector that began the Colonial Pipeline incident, via a legacy account without MFA.
Unpatched Windows HMIs
Engineering workstations and HMIs on Windows XP/7 that cannot be patched without vendor re-validation, holding the software that programs the PLCs.
These are not theoretical. Stuxnet (2010) crossed from IT into an isolated OT network and physically destroyed roughly a thousand centrifuges. Industroyer (2016) abused the IEC-104 protocol to operate substation breakers and black out part of Ukraine. Most relevant to this region, Triton/Trisis (2017) targeted a Saudi petrochemical plant's Safety Instrumented System — the last-line safety layer — the first malware written to attack the systems that exist to prevent physical catastrophe. The lesson across all three is why OT testing exists: in these environments, a cyber weakness is a physical-safety weakness.
// 07 Which industries need OT/ICS penetration testing?
Any organisation where software controls a physical process, and especially those designated as critical national infrastructure in the GCC.
Energy, oil & gas, petrochemicals
Refineries, upstream and downstream, pipelines — the Saudi Aramco and SABIC ecosystem, and the exact sector Triton targeted in the Kingdom. See penetration testing for oil & gas.
Electric utilities & water
Generation, transmission and substations; water and wastewater SCADA — Industroyer-class and DNP3 exposure.
Manufacturing
Discrete and process plants running PROFINET and EtherNet/IP, where IT/OT convergence has quietly removed the old air gap.
Transport & smart cities
Rail, ports, aviation ground systems and building/city automation — now explicitly in scope under NIST 800-82 Rev 3 and the OTCC.
// 08 Frequently asked questions
What is OT/ICS penetration testing?
A safety-first security assessment of the operational technology that runs physical processes — PLCs, SCADA, HMIs and industrial networks — prioritising availability and safety, leading with passive techniques, and never risking disruption of a live process.
How is it different from IT penetration testing?
The priorities invert to safety and availability first. Testing leads with passive traffic analysis, restricts active work to replicas or maintenance windows, and defines stop conditions up front. "Demonstrate risk, don't cause disruption."
What standards apply?
IEC 62443 (SL1–SL4, zones and conduits), NIST SP 800-82 Rev 3, NERC CIP for North American utilities, and Saudi NCA OTCC control 2-10 for critical national infrastructure operators.
Can you test without disrupting production?
Yes — that is the core discipline. Production-critical layers are tested passively, active exploitation runs against replicas or maintenance windows, and every engagement has agreed stop conditions and rollback plans.
// 09 Standards & references
- IEC 62443 series (ISA/IEC) — security levels, zones and conduits, system and component requirements.
- NIST SP 800-82 Revision 3 (September 2023) — Guide to Operational Technology (OT) Security.
- Saudi NCA Operational Technology Cybersecurity Controls, OTCC-1:2022 — penetration testing control 2-10 (Cybersecurity Defense domain); confirmed via the NCA OTCC control set.
- NERC CIP — Critical Infrastructure Protection standards for the North American Bulk Electric System.
- Incident references: Stuxnet (2010), Industroyer/CrashOverride (2016), Triton/Trisis (2017), Colonial Pipeline (2021).