OT Network Testing for ICS SCADA and Critical Infrastructure

OT / ICS SECURITY TESTING

OT Network
Testing
Purdue, NIST, and Critical Infrastructure

OT network testing validates whether industrial control environments can resist cyber risk without disrupting safety, uptime, process integrity, or critical operations.

Updated May 2026

ICS + SCADA Security

Redbot Security Research

Executive Overview

Operational Technology network testing is different from traditional IT penetration testing. OT environments support physical processes, industrial equipment, safety systems, critical infrastructure, utilities, manufacturing lines, water treatment, energy operations, transportation systems, building automation, and other environments where uptime and safety are primary requirements.

A strong OT assessment validates cyber risk without creating operational instability. Testing must respect production constraints, change windows, vendor dependencies, legacy protocols, fragile devices, safety instrumented systems, engineering workflows, and the reality that patching or scanning cannot always be performed the same way it is in enterprise IT.

Real incidents show why this matters. Oldsmar demonstrated how remote access abuse could reach water treatment controls. Ukraine power grid attacks showed cyber operations causing real electric disruption. TRITON/TRISIS targeted safety instrumented systems. Stuxnet manipulated industrial process logic. Colonial Pipeline showed how an IT-side incident can create major operational consequences for critical infrastructure.

Redbot Security supports OT and critical infrastructure validation through ICS / SCADA penetration testing, advanced cybersecurity solutions, red team testing, MITRE ATT&CK adversary simulation, internal and external penetration testing, and manual penetration testing.

01

Why OT Network Testing Matters

OT systems were historically designed for reliability, availability, deterministic operation, and safety. Many were not originally designed to operate in connected environments with cloud management, remote access, vendor portals, shared identity systems, internet-connected monitoring, and IT/OT convergence.

As plants, utilities, and industrial operators connect OT environments to business networks, remote support, enterprise identity, data historians, cloud analytics, and third-party vendors, the attack surface expands. A weakness in IT, identity, VPN, remote access, segmentation, or vendor access can become a pathway toward operational systems.

OT Security Concern	Why It Matters
Safety and Process Integrity	Cyber activity can affect physical processes, equipment behavior, environmental conditions, and personnel safety.
Legacy Systems	Older PLCs, HMIs, engineering workstations, and protocols may lack modern authentication, encryption, or logging.
Remote Access	Vendor support, remote desktop, VPNs, jump hosts, and shared accounts can create high-impact access paths.
IT/OT Convergence	Enterprise compromise can become OT risk when segmentation, monitoring, and identity boundaries are weak.
Patch Constraints	Operational downtime, vendor certification, safety requirements, and compatibility constraints can delay patching.
Detection Gaps	OT activity may not be logged, centrally monitored, or interpreted with process-aware context.

OT testing must protect operations first.

The goal is to validate cyber risk while preserving uptime, safety, process integrity, and plant confidence.

02

OT and Critical Infrastructure Incident Lessons

OT incidents and near-misses show that industrial cyber risk is not theoretical. Attackers may target remote access, engineering workstations, safety systems, HMIs, PLC logic, IT dependencies, business systems, and vendor pathways.

Incident	Operational Lesson	Testing Priority
Oldsmar Water Treatment	Unauthorized remote access reached a SCADA interface and attempted to alter chemical treatment settings.	Validate remote access, MFA, shared accounts, operator visibility, alerting, and workstation access control.
Ukraine Power Grid Attacks	Coordinated cyber activity contributed to electric disruption and showed the importance of segmentation and response readiness.	Review IT/OT boundaries, operator workstations, remote command paths, backup operations, and incident playbooks.
TRITON / TRISIS	Safety instrumented systems were targeted, raising the stakes from disruption to potential safety consequences.	Protect SIS networks, engineering stations, safety controllers, management access, and change-control evidence.
Stuxnet	Industrial process manipulation can target PLC logic and engineering workflows, not only enterprise data.	Review engineering workstations, removable media, PLC logic change control, vendor tools, and offline transfer paths.
Colonial Pipeline	An IT-side ransomware incident drove operational shutdown decisions with major critical infrastructure consequences.	Validate business network resilience, identity security, segmentation, remote access, response decision paths, and recovery planning.
Internet-Exposed OT Devices	Publicly reachable OT interfaces, weak passwords, and exposed industrial protocols continue to create avoidable risk.	Identify internet exposure, vendor access, protocol leakage, weak authentication, and asset ownership gaps.

These cases are different, but the pattern is consistent: weak access paths, poor segmentation, insufficient monitoring, and unsafe operational assumptions can turn cyber weaknesses into physical, safety, or continuity risk.

03

Purdue Model: OT Security Zones and Testing Context

The Purdue Enterprise Reference Architecture is commonly used to discuss industrial network segmentation. It separates enterprise IT, operations management, supervisory control, local control, and physical process layers.

OT testing should understand which systems live at each level and how traffic, identity, data, and vendor access move between levels.

Purdue Level	Typical Systems	Testing Focus
Level 5	Enterprise IT, corporate applications, internet access, email, identity systems.	Validate whether enterprise compromise can reach OT pathways.
Level 4	Site business planning, production scheduling, reporting, business systems.	Review business-to-OT data flows, user access, and segmentation.
Level 3.5	Industrial DMZ, jump hosts, patch repositories, remote access brokers, data transfer systems.	Test controlled access paths, firewall rules, logging, and trust boundaries.
Level 3	Operations management, historians, engineering management, OT domain services.	Validate identity, backups, remote administration, asset visibility, and monitoring.
Level 2	HMIs, SCADA servers, operator workstations, batch systems.	Review operator access, HMI exposure, workstation hardening, and application trust.
Level 1	PLCs, RTUs, IEDs, controllers, safety devices.	Use extreme caution; validate exposure, segmentation, protocol access, and change-control paths.
Level 0	Sensors, actuators, physical process equipment.	Testing is usually indirect and focused on safe process-impact analysis.

The Purdue model is not a perfect map of every modern OT network, especially with cloud, IIoT, remote access, and vendor-managed platforms, but it remains useful for understanding trust boundaries.

04

NIST SP 800-82 and Safe OT Testing Principles

NIST SP 800-82 Rev. 3 emphasizes that OT systems have unique performance, reliability, and safety requirements. That means OT assessments must be planned differently than standard IT penetration tests.

Safe testing should prioritize passive discovery where appropriate, documented rules of engagement, production impact analysis, maintenance windows, vendor coordination, recovery planning, and clear stop conditions.

Safe Testing Principle	Operational Purpose
Protect Safety First	No test should endanger personnel, public safety, environmental controls, or process stability.
Preserve Availability	Testing should avoid destabilizing fragile devices, industrial protocols, or time-sensitive operations.
Coordinate With Operations	Operators, engineers, vendors, and safety teams should understand timing, scope, and escalation paths.
Use Passive Methods First	Asset discovery, traffic review, configuration review, and architecture analysis often reduce risk before active testing.
Define Exclusions	Safety systems, fragile PLCs, live process controllers, or sensitive production networks may require special handling.
Validate Recovery	Backups, images, vendor contacts, rollback plans, and response procedures should be ready before testing.

OT testing is not about proving how disruptive a tester can be.

Mature OT testing proves where risk exists while maintaining operational confidence and respecting industrial constraints.

05

OT Network Testing Scope

OT assessments should be scoped around the environment’s actual architecture, safety requirements, business impact, and operational tolerance. Testing may include architecture review, segmentation validation, remote access review, passive asset discovery, firewall analysis, identity review, workstation hardening, and controlled validation of attack paths.

Testing Area	Validation Objective
Asset Visibility	Identify OT systems, protocols, vendors, firmware, operating systems, unmanaged assets, and unknown connections.
Segmentation	Validate separation between enterprise IT, industrial DMZ, OT management, SCADA, HMIs, and controllers.
Remote Access	Review VPNs, jump hosts, vendor tools, shared accounts, MFA, session recording, and access approvals.
Engineering Workstations	Assess hardening, removable media controls, PLC programming tools, project files, backups, and privilege paths.
HMIs and SCADA	Review authentication, authorization, workstation exposure, application trust, and operator access paths.
Historians and Data Flows	Validate how OT data moves to business systems, cloud platforms, analytics tools, and reporting networks.
Identity and Privilege	Review shared accounts, local admins, OT domain services, vendor identities, password vaulting, and least privilege.
Logging and Monitoring	Validate whether OT activity, remote access, firewall events, engineering changes, and authentication are visible.

Scope should be approved by both cybersecurity and operations leadership before testing begins.

06

Segmentation and IT/OT Boundary Testing

Segmentation is one of the most important OT controls. If ransomware, stolen credentials, or malware from the business network can reach OT systems, the organization may face operational disruption even if controllers are not directly compromised.

Boundary testing validates whether enterprise systems, remote users, vendors, cloud platforms, and support tools can reach sensitive OT assets.

Segmentation Check	Risk Reduced
IT to OT Firewall Rules	Prevents broad enterprise access into OT networks and reduces ransomware propagation paths.
Industrial DMZ	Controls data transfer between business systems and OT systems without direct trust.
Jump Host Enforcement	Centralizes administrative access, logging, MFA, approval, and session recording.
Vendor Access Restrictions	Limits third-party reach to approved systems, approved times, and monitored sessions.
OT Egress Controls	Reduces unauthorized outbound access, command-and-control paths, and unmanaged cloud connections.
Protocol Filtering	Restricts industrial protocol access to authorized paths and expected devices.

For related attack-path context, review Chaining Low-Risk Findings Into Breaches.

07

Remote Access and Vendor Risk

Remote access is a major OT risk area because support vendors, integrators, engineers, and operators may require access to production environments. The Oldsmar incident reinforced how remote access abuse can directly affect SCADA operations.

Testing should validate whether remote access is tightly controlled, monitored, time-bound, authenticated, approved, and limited to required systems.

Remote Access Risk	Testing Objective
Shared Accounts	Identify accounts used by multiple users or vendors without accountability.
Missing MFA	Validate MFA for VPN, remote desktop, jump hosts, privileged access, and vendor portals.
Always-On Vendor Tunnels	Review persistent remote access paths that bypass approval windows or monitoring.
Unrecorded Sessions	Assess whether remote activity is logged, reviewed, and attributable to an individual.
Broad Network Reach	Confirm vendors can access only approved assets and not entire OT networks.
Weak Deprovisioning	Review whether former vendors, contractors, and employees retain access.

Remote access should be treated as a high-risk OT control.

Every remote pathway into OT should have strong identity, approval, segmentation, logging, and ownership.

08

Engineering Workstations, HMIs, PLCs, and SCADA

Engineering workstations and HMIs are high-value assets because they often provide visibility and control over industrial processes. They may store project files, PLC logic, vendor tools, credentials, configuration backups, and access to controllers.

Testing these systems requires careful coordination. The objective is to validate exposure, access control, hardening, backup integrity, change control, and monitoring without affecting production control.

Review engineering workstation hardening, local admin access, and installed vendor tools.

Validate PLC logic change-control procedures and backup protection.

Assess removable media controls and offline transfer procedures.

Review HMI authentication, session handling, workstation locks, and operator access rights.

Validate whether controller networks are reachable only from approved engineering paths.

Confirm that changes to logic, recipes, setpoints, and configurations produce reviewable evidence.

Stuxnet and TRITON show why engineering and safety systems deserve special attention. OT testing must include process-aware risk review, not only host vulnerability checks.

09

OT Logging, Detection, and Response

OT detection must answer operationally meaningful questions. Who accessed the environment? What engineering changes occurred? Which device communicated with which controller? Did a vendor connect outside an approved window? Did an HMI or PLC experience unexpected communication?

Many OT environments collect limited logs or lack centralized correlation. Testing should evaluate whether security and operations teams can see important activity and respond safely.

Detection Area	Validation Objective
Remote Access Logs	Validate individual attribution, MFA events, approval windows, session recording, and vendor activity.
Firewall and DMZ Logs	Monitor IT/OT boundary traffic, denied connections, new flows, and industrial protocol movement.
Engineering Changes	Detect PLC logic changes, configuration updates, downloads, uploads, and unauthorized project modifications.
HMI and SCADA Activity	Review operator logins, setpoint changes, alarm behavior, and workstation access.
Asset and Protocol Monitoring	Identify new devices, unexpected protocols, unauthorized scans, and abnormal industrial communications.
Incident Response Playbooks	Confirm safe escalation, operational decision-making, containment options, and recovery procedures.

Detection should be tested with safe simulations and tabletop validation so both cyber and operations teams understand response roles.

10

How Redbot Tests OT Networks Safely

Redbot Security tests OT networks using a safety-first methodology that validates risk while respecting uptime, process integrity, change windows, and operational constraints.

The objective is to determine whether attackers can move from enterprise IT, remote access, vendor pathways, engineering workstations, industrial DMZs, or misconfigured segmentation into sensitive OT systems.

Testing Area	Redbot Validation Focus
Architecture and Purdue Review	Map zones, conduits, trust boundaries, remote access paths, and critical process dependencies.
Safe Discovery	Use passive review and controlled validation to identify assets, protocols, exposures, and ownership gaps.
Segmentation Testing	Validate IT/OT separation, industrial DMZ controls, firewall rules, jump hosts, and vendor access boundaries.
Identity and Remote Access	Review MFA, shared accounts, privileged access, vendor sessions, deprovisioning, and session logging.
Workstation and HMI Review	Assess operator stations, engineering systems, removable media controls, hardening, and access paths.
Reporting and Retesting	Deliver operationally useful findings, remediation guidance, control evidence, and validation after fixes.

Redbot helps critical infrastructure, manufacturing, utilities, and industrial organizations understand OT cyber risk without putting production operations at unnecessary risk.

Frequently Asked Questions

What is OT network testing?

OT network testing validates whether industrial control environments, including SCADA, HMIs, engineering workstations, PLC networks, remote access, and segmentation controls, can resist cyber risk without disrupting operations.

How is OT testing different from IT penetration testing?

OT testing prioritizes safety, uptime, process integrity, fragile systems, vendor constraints, and operational continuity. It uses carefully scoped and coordinated methods instead of aggressive testing that could disrupt production.

What is the Purdue model in OT security?

The Purdue model is a reference architecture that separates enterprise IT, industrial DMZs, operations management, supervisory control, local control, and physical process levels to help define segmentation and trust boundaries.

Why does NIST SP 800-82 matter for OT security?

NIST SP 800-82 provides guidance for securing operational technology while accounting for OT’s unique performance, reliability, and safety requirements.

What are common OT security risks?

Common OT risks include weak segmentation, unsafe remote access, shared accounts, exposed industrial protocols, insecure engineering workstations, weak vendor access, poor logging, and untested recovery procedures.

Can OT testing be performed safely?

Yes. OT testing can be performed safely when it is carefully scoped, coordinated with operations, uses passive methods where appropriate, avoids unsafe active tests, defines stop conditions, and respects production constraints.

How does Redbot Security test OT networks?

Redbot Security tests OT networks through safety-first architecture review, passive discovery, segmentation validation, remote access review, engineering workstation assessment, identity review, logging validation, reporting, and retesting.