ICS / SCADA SECURITY TESTING

ICS / SCADA
Penetration Testing
Where to Start

Industrial control system testing must validate cyber risk while protecting uptime, safety, process integrity, production reliability, and critical infrastructure operations.

Updated May 2026

OT + Critical Infrastructure

Redbot Security Research

Executive Overview

ICS and SCADA penetration testing is not the same as traditional IT penetration testing. Industrial environments control physical processes, production systems, energy operations, manufacturing lines, water treatment, building automation, transportation systems, safety systems, and other critical functions where downtime can create operational, financial, environmental, or safety consequences.

The right starting point is not aggressive scanning or exploit attempts against live controllers. The right starting point is a safety-first assessment plan that understands the environment, identifies the systems that matter most, maps trust boundaries, reviews remote access, validates segmentation, and determines where controlled testing can be performed without disrupting operations.

ICS / SCADA testing should answer practical questions: can enterprise IT reach OT systems? Can vendors access more than they should? Are HMIs, engineering workstations, historians, PLCs, and remote access paths properly segmented? Are shared accounts, stale access, unmanaged assets, exposed protocols, and weak monitoring creating real operational risk?

Redbot Security supports industrial and critical infrastructure environments through ICS / SCADA penetration testing, OT network testing, advanced cybersecurity solutions, red team testing, internal and external penetration testing, and manual penetration testing.

01

What Is ICS / SCADA Penetration Testing?

ICS / SCADA penetration testing is a controlled security assessment of industrial control environments. It evaluates the systems, networks, identities, remote access pathways, workstations, applications, and operational processes that support industrial automation and control.

Unlike standard IT testing, ICS testing must account for operational constraints. Some systems are fragile, legacy, vendor-managed, safety-critical, or difficult to patch. Certain active scans or exploit techniques that are acceptable in IT can be unsafe in production OT environments.

A mature assessment blends architecture review, passive discovery, configuration review, segmentation testing, remote access validation, credential and identity review, workstation hardening checks, detection review, and carefully approved active testing where safe.

ICS testing starts with safety and scope.

Before any technical validation begins, the team must understand what systems are in scope, what cannot be touched, who owns each process, and what conditions would require testing to stop.

02

Why ICS Testing Is Different From IT Testing

IT environments usually prioritize confidentiality, integrity, and availability. OT environments still care about those goals, but safety, reliability, uptime, and process integrity often come first.

An overly aggressive IT-style test could disrupt an industrial device, overwhelm a fragile controller, interfere with a production line, trigger alarms, or create operator confusion. That is why OT testing must be planned, phased, and coordinated with operations personnel.

Testing Dimension	Traditional IT	ICS / SCADA
Primary Concern	Data, systems, applications, identity, and business continuity.	Safety, uptime, process integrity, production reliability, and operational continuity.
Scanning Approach	Active scanning is common when approved.	Passive discovery is often preferred first. Active testing must be carefully approved.
Patch Expectations	Patching can often be scheduled regularly.	Patching may require vendor certification, downtime, safety review, or maintenance windows.
Asset Lifespan	Systems may be replaced every few years.	Industrial systems may remain in operation for decades.
Failure Impact	Data loss, downtime, revenue loss, compliance impact.	Physical disruption, equipment damage, environmental impact, safety consequences, production loss.
Testing Team	Security and IT are usually primary stakeholders.	Security, IT, OT, engineering, operations, safety, vendors, and plant leadership must coordinate.

03

Where to Start With ICS / SCADA Penetration Testing

The safest starting point is a structured readiness process. Before testing controllers, HMIs, engineering workstations, or industrial protocols, the organization should understand its architecture, assets, zones, data flows, access paths, and operational constraints.

Starting Step	Purpose
Define Scope and Safety Boundaries	Identify approved systems, excluded systems, fragile devices, safety constraints, plant contacts, and stop conditions.
Map the Architecture	Document Purdue zones, industrial DMZs, remote access paths, vendor access, historians, SCADA, HMIs, PLCs, and enterprise connections.
Review Asset Inventory	Identify known and unknown assets, owners, firmware, operating systems, vendor support status, and communication paths.
Validate Segmentation	Confirm that enterprise IT, industrial DMZ, OT management, SCADA, and controller networks are appropriately separated.
Assess Remote Access	Review VPNs, jump hosts, vendor portals, remote desktop, shared accounts, MFA, session logging, and deprovisioning.
Plan Safe Technical Testing	Select passive, low-impact, or lab-based validation techniques before considering active production tests.

This approach lets teams identify the highest-risk pathways without putting production systems under unnecessary stress.

04

Start With the Purdue Model and Trust Boundaries

The Purdue model is a useful starting framework for understanding ICS and SCADA segmentation. It helps separate enterprise systems, industrial DMZs, operations management, supervisory control, local control, and the physical process.

Modern OT environments may not perfectly follow Purdue because of cloud analytics, IIoT, remote monitoring, vendor-managed platforms, and converged infrastructure. Still, the model helps teams identify where trust boundaries should exist.

Purdue Level	Typical Systems	Testing Focus
Level 5	Enterprise IT, email, identity, business applications, internet access.	Determine whether enterprise compromise can create OT access paths.
Level 4	Business planning, reporting, scheduling, enterprise operations.	Review data flows, user access, and business-to-OT dependencies.
Level 3.5	Industrial DMZ, jump hosts, patch servers, remote access brokers, file transfer systems.	Validate firewall rules, jump host enforcement, monitoring, and data transfer restrictions.
Level 3	Historians, OT management systems, engineering services, OT domain services.	Assess identity, backups, privilege, management access, and monitoring coverage.
Level 2	SCADA servers, HMIs, operator workstations, batch control systems.	Review authentication, workstation security, HMI exposure, and operator access controls.
Level 1	PLCs, RTUs, IEDs, controllers, safety devices.	Use extreme caution. Validate exposure, approved communication paths, and change-control routes.
Level 0	Sensors, actuators, physical equipment, process outputs.	Testing is usually indirect and focused on process-impact awareness.

For deeper OT zone and NIST-aligned context, review OT Network Testing: Purdue, NIST, and Critical Infrastructure.

05

Safe ICS / SCADA Testing Methodology

Safe ICS testing is built around controlled validation. The engagement should begin with documentation review, passive discovery, interviews, architecture validation, configuration review, and safe boundary testing before any active testing touches sensitive OT systems.

Testing Phase	What Happens	Why It Is Safer
Planning and Rules of Engagement	Define scope, contacts, timing, escalation, stop conditions, and excluded systems.	Prevents surprise activity and protects operations.
Architecture Review	Review diagrams, zones, firewalls, remote access, vendors, and data flows.	Finds risk without touching fragile systems.
Passive Discovery	Observe traffic, asset behavior, protocols, and communication paths.	Reduces risk compared to active probing.
Configuration Review	Assess firewall rules, jump hosts, accounts, backups, logging, and workstation hardening.	Identifies control gaps with limited operational impact.
Controlled Validation	Test approved access paths, segmentation, authentication, and monitoring.	Validates risk without unsafe exploitation.
Reporting and Retesting	Document findings, operational risk, remediation guidance, and validation after fixes.	Turns assessment results into defensible risk reduction.

The best OT test is controlled, coordinated, and useful.

ICS / SCADA testing should help operators reduce risk without creating the type of disruption the test is meant to prevent.

06

Remote Access and Vendor Pathways

Remote access is one of the most important places to start because vendors, integrators, engineers, and operators often need access to industrial systems. If these pathways are weak, an attacker may bypass segmentation and reach systems that were never intended to be exposed.

Remote Access Control	Validation Objective
MFA Enforcement	Confirm MFA is required for VPNs, jump hosts, remote desktop, vendor portals, and privileged access.
Named Accounts	Eliminate shared vendor or operator accounts that prevent individual accountability.
Jump Host Control	Validate that remote users must pass through monitored, hardened, and approved access brokers.
Session Recording	Confirm privileged sessions are logged, reviewed, and attributable to a specific user.
Time-Bound Access	Verify vendor and contractor access is limited to approved windows and approved assets.
Deprovisioning	Review whether former vendors, contractors, employees, and integrators retain access.

Remote access abuse has appeared in real-world OT incidents. Testing should confirm that remote pathways are not the easiest route into production systems.

07

Engineering Workstations, HMIs, and PLC Access

Engineering workstations and HMIs are high-value assets because they often provide direct or indirect access to industrial process control. They may contain project files, PLC logic, vendor tools, credentials, configuration backups, historian access, and trusted routes to controllers.

Testing should validate how these systems are accessed, protected, backed up, monitored, and used. The goal is to understand whether a compromised workstation could lead to process manipulation or broader OT compromise.

Review local administrator rights and shared engineering accounts.

Validate workstation patch status and vendor-supported hardening.

Assess removable media controls for USB drives, laptops, and offline transfers.

Review PLC project file storage, backup protection, and logic change procedures.

Validate operator workstation lock policies, authentication, and HMI access controls.

Confirm engineering changes are logged, approved, attributable, and recoverable.

Engineering workstation compromise is one of the most serious OT pathways because it can connect cyber access to process-level change.

08

Segmentation and Monitoring Validation

Segmentation reduces the likelihood that a compromise in one zone spreads into another. Monitoring helps operators and security teams see when something unusual is happening. Both must be validated.

An OT assessment should test whether the intended segmentation actually works and whether logs provide useful evidence for investigation and response.

Control Area	What to Validate
IT / OT Firewall Rules	Confirm only approved traffic crosses from enterprise networks into industrial environments.
Industrial DMZ	Validate that data transfer occurs through controlled systems rather than direct trust.
Protocol Restrictions	Confirm industrial protocols are only allowed between expected systems.
Remote Access Logs	Review MFA events, session activity, vendor access, failed logins, and unusual timing.
Engineering Change Logs	Confirm controller changes, project downloads, uploads, and configuration changes are visible.
Alert Escalation	Validate that suspicious OT activity reaches the right operations and security teams.

Segmentation and monitoring should be tested from realistic starting points, such as a compromised enterprise workstation, vendor VPN, jump host, or engineering workstation.

09

Reporting, Remediation, and Retesting

ICS / SCADA findings must be written in a way that operations, engineering, IT, security, leadership, and vendors can act on. A useful report does not simply list vulnerabilities. It explains operational risk, affected zones, compensating controls, safe remediation options, and validation steps.

Report Element	Why It Matters
Operational Impact	Explains how a weakness could affect safety, uptime, process integrity, or production.
Attack Path Context	Shows whether a finding can be used to move from IT, remote access, or a workstation into OT systems.
Compensating Controls	Provides alternatives when patching or replacement is not immediately feasible.
Owner Assignment	Clarifies whether remediation belongs to operations, engineering, IT, security, facilities, or vendors.
Safe Remediation Guidance	Recommends steps that reduce risk without creating operational instability.
Retesting Evidence	Confirms that fixes were implemented and that the attack path was reduced or closed.

Strong OT reporting supports risk reduction, compliance evidence, budget planning, vendor accountability, and executive decision-making.

10

How Redbot Helps Organizations Start Safely

Redbot Security helps organizations begin ICS / SCADA penetration testing with a safety-first approach that validates risk without putting operations under unnecessary stress.

The objective is to identify the highest-risk access paths, segmentation weaknesses, remote access gaps, workstation exposures, identity issues, logging gaps, and remediation priorities in a way that operations teams can trust.

Redbot Testing Area	Validation Focus
Readiness and Scoping	Define scope, exclusions, safety rules, operating constraints, contacts, and stop conditions.
Architecture Review	Map Purdue zones, remote access, industrial DMZs, vendor pathways, and critical asset flows.
Safe Discovery	Use passive and low-impact methods to identify assets, protocols, and exposure.
Segmentation Validation	Confirm that IT, DMZ, OT management, SCADA, HMI, and controller networks are separated appropriately.
Remote Access Review	Evaluate VPNs, jump hosts, vendor access, MFA, session logging, shared accounts, and deprovisioning.
Reporting and Retesting	Deliver operationally useful findings, remediation guidance, and validation that fixes reduced risk.

Redbot helps industrial organizations move from uncertainty to a practical, staged OT security testing program.

Frequently Asked Questions

Where should an organization start with ICS / SCADA penetration testing?

Start with scope, safety boundaries, architecture review, asset visibility, remote access review, segmentation validation, and passive discovery before performing any active testing against sensitive OT systems.

Is ICS penetration testing safe?

ICS penetration testing can be safe when it is carefully scoped, coordinated with operations, uses passive methods first, avoids unsafe active testing, defines stop conditions, and respects production constraints.

How is SCADA testing different from normal IT testing?

SCADA testing prioritizes safety, uptime, process integrity, legacy system constraints, vendor dependencies, and operational continuity. It requires more planning and coordination than standard IT testing.

What systems are usually included in ICS / SCADA testing?

Testing may include industrial DMZs, jump hosts, remote access systems, historians, HMIs, SCADA servers, engineering workstations, OT domain services, firewall rules, and approved controller communication paths.

Should PLCs be actively tested?

PLC testing must be handled with extreme caution. In many production environments, direct active testing against controllers should be avoided or limited to lab systems, maintenance windows, vendor-approved methods, or carefully controlled validation.

Why is remote access important in OT testing?

Remote access is important because vendors, engineers, and operators may use VPNs, jump hosts, remote desktop, or support tools that can become high-impact pathways into OT systems if not tightly controlled.

How does Redbot Security perform ICS / SCADA testing?

Redbot Security performs ICS / SCADA testing using safety-first scoping, architecture review, passive discovery, segmentation validation, remote access review, workstation assessment, reporting, remediation guidance, and retesting.