01 // Control systems
SCADA, HMI & Engineering Systems
Review authentication, exposed services, configuration weaknesses, remote administration paths and security-relevant dependencies around supervisory and engineering systems.
OT/ICS Security
Testing for
Operational Risk
Assess the security of industrial networks, SCADA, PLCs, HMIs, remote access and IT/OT boundaries with a methodology built around operational safety. Grey Shield combines manual assessment, controlled validation, evidence-backed reporting and practical remediation guidance.
OT SECURITY REVIEW // ILLUSTRATIVENOT A CLIENT SYSTEM
ASSESSMENT MODECONTROLLED
PRIMARY FOCUSATTACK PATHS
PROCESS PRIORITYAVAILABILITY
✓ PASSIVE-FIRST WHERE REQUIRED · TESTS AGREED BEFORE EXECUTION
Manual assessmentHuman-led review rather than a raw automated scan.
Operationally awareRules of engagement and testing depth are agreed around the environment.
Actionable reportingEvidence, impact and remediation guidance your team can use.
RetestingFixes can be verified after remediation when included in scope.
Overview
OT Security Needs a Different Testing Model
OT/ICS environments connect digital systems to physical processes. That changes how a security assessment should be planned: the objective is to demonstrate realistic security risk without treating a production control system like an ordinary IT server.
Grey Shield's approach starts with scope, architecture and operational constraints, then selects passive, configuration-review or controlled active techniques for each part of the environment. Where application or API layers are in scope, manual testing can be applied to those interfaces as well.
Our reporting is designed to help both technical and operational stakeholders understand what was exposed, how an attack path could develop, what the business or operational impact could be, and what should be fixed first.
Need the methodology first? Review the Grey Shield penetration testing methodology, then request a scoping conversation so the assessment can be matched to your environment.
Assessment scope
What We Assess
The exact scope depends on the architecture, equipment, operational constraints and written rules of engagement. Typical assessment areas include:
02 // Field systems
PLCs, RTUs & Controllers
Assess reachable interfaces, configuration and access-control weaknesses using techniques appropriate to the device and agreed operational risk.
03 // Network
IT/OT Segmentation
Review zones, conduits, firewall policy, jump hosts and other boundaries to identify unnecessary paths between enterprise and operational networks.
04 // Access
Remote & Vendor Access
Assess VPNs, remote administration, jump servers and other external or third-party access paths that can introduce risk into OT environments.
05 // Protocols
Industrial Communications
Where authorised and appropriate, review industrial protocol exposure and security properties as part of the broader environment assessment.
06 // Connected systems
OT Management & API Layers
Where these components are in scope, assess web interfaces, APIs, authentication and business-logic paths that support OT management or connected industrial applications.
How we work
A Safety-Conscious Assessment Process
Testing depth is determined by the environment. Active techniques are not assumed to be safe simply because they are standard in IT pentesting.
PHASE 01
Scope & Rules of Engagement
Document assets, boundaries, test windows, contacts, stop conditions and systems that require passive-only assessment.
Required before testingPHASE 02
Architecture & Asset Review
Understand the OT architecture, trust boundaries, remote access paths, critical systems and available documentation before choosing techniques.
Context firstPHASE 03
Passive Discovery
Where appropriate, use passive observation and traffic analysis to understand assets and communications without generating disruptive traffic.
Low-impactPHASE 04
Controlled Security Testing
Validate agreed attack paths, configuration weaknesses, access controls and boundaries using techniques approved for the environment.
Scope controlledPHASE 05
Impact & Attack-Path Analysis
Connect individual weaknesses into realistic paths and explain their technical and operational significance without overstating impact.
Evidence basedPHASE 06
Report, Remediate & Retest
Deliver prioritised findings and remediation guidance, then verify fixes through retesting when the retest is included in the agreed engagement.
Fix verificationCoverage model
From Enterprise IT to the Control Layer
The Purdue Model can help teams reason about where boundaries and dependencies exist. It should be treated as an architecture reference, not a promise that every level will receive the same testing technique.
L4
EnterpriseBusiness and corporate systems
Scope dependentL3
OperationsSite operations and supporting systems
Scope dependentDMZ
IT/OT BoundaryFirewalls, jump hosts and controlled conduits
High focusL2
ControlSCADA, HMI and supervisory systems
Technique dependentL1
ControllersPLCs, RTUs and control devices
Technique dependentL0
FieldSensors, actuators and physical process interfaces
Safety firstIT/OT attack paths
Trace realistic routes from enterprise or remote-access exposure toward operational zones where that testing is authorised.
Segmentation and boundary review
Identify unnecessary communication paths, weak trust boundaries and access-control gaps that increase lateral-movement risk.
Protocol and device exposure
Assess relevant industrial communications and device interfaces according to their safety and operational constraints.
Operational context
Prioritise findings using the environment's availability and process impact rather than treating every technical weakness equally.
Deliverables
What You Receive
Reporting should help security, engineering and operations teams move from a finding to a practical remediation decision.
Executive Summary
Clear summary of material findings, affected areas, risk themes and recommended priorities for leadership.
Technical Findings
Evidence-backed findings with affected assets, reproduction or validation details where appropriate, severity and impact context.
Remediation Guidance
Practical recommendations that account for configuration, architecture and operational constraints rather than simply listing CVEs.
Retest & Closure
Verification of remediated findings after fixes are deployed when retesting is included in the agreed scope.
Related Grey Shield resource
View Case Studies
See how Grey Shield approaches security engagements
Review the testing methodology, learn about Grey Shield, or browse the case studies for the evidence that is currently available.
FAQ
Common Questions
What is OT/ICS security testing?
It is an authorised assessment of operational technology and industrial control environments to identify weaknesses across networks, remote access, configurations, industrial protocols, SCADA/HMI systems and IT/OT boundaries.
Will testing disrupt production?
The testing approach should be selected around operational risk. Passive techniques can be used where appropriate, while active testing of production systems should be explicitly scoped, authorised and scheduled with the responsible operations team.
What systems can be included?
Depending on scope, an assessment may include industrial networks, SCADA servers, HMIs, PLCs, RTUs, engineering workstations, remote access paths, segmentation controls and relevant industrial communication protocols.
Can web or API testing be included?
Yes, where an OT environment includes web interfaces, APIs or management applications and those components are explicitly included in scope. The testing method is then adapted to the relevant application attack surface.
What do we receive after the assessment?
Depending on the agreed scope, deliverables can include an executive summary, technical findings, evidence, risk context, remediation guidance and retesting of remediated issues.
How is the assessment scoped?
Scoping considers assets, architecture, safety and availability requirements, permitted techniques, testing windows, contacts, stop conditions and the objectives of the engagement before testing begins.
Start with scope
Test the Weaknesses.
Respect the Process.
Tell Grey Shield what you operate, what you want assessed and what operational constraints matter. We'll use that information to determine the appropriate assessment scope and testing approach.