OT Penetration Testing Guide: Safe ICS Testing

A penetration test that is routine on an office network can stop a production line, trip a safety function or leave a controller in an unknown state when it is pointed at operational technology. Industrial control systems were built for availability and deterministic behaviour, many field devices handle unexpected traffic badly, and the consequence of a mistake is physical rather than a rebooted server. This guide is for asset owners, OT security leads, engineering managers and procurement teams who commission and govern OT penetration tests: how to scope them, what to require of a provider, how to keep the plant safe, what the contract and authorisation must say, and how to handle the findings. It deliberately does not describe testing techniques. For the general model of a penetration test, see the Penetration Testing Guide.

Key takeaways

Safety outranks findings. The test plan exists to protect people, plant and production first; the engineering owner of the process, not the tester, decides what may be touched and when.
Passive first, active only where proven safe. Most of the value of an OT assessment comes from document review, configuration review, interviews and passive traffic capture; active interaction with live control equipment needs explicit, device-level approval.
Test the copy, not the plant. Lab benches, spare hardware, backup or offline systems and digital twins are where risky checks belong, with production limited to what has already been shown harmless.
Specialist providers only. Require OT experience on the named team, familiarity with your vendors and protocols, and alignment with IEC 62443-2-4 for service providers working on industrial systems.
Stop conditions and an operator on the line. Every session needs a named control room contact with authority to halt testing, agreed abort triggers and a rehearsed way to put the process back into a known safe state.

Why OT testing is different

NIST SP 800-82 Rev. 3 (September 2023) frames OT security around "unique performance, reliability, and safety requirements", and its executive summary is direct about testing: patches and changes should be tested under field conditions on a test system where possible, and unused ports and services should only be disabled after testing confirms it will not affect OT operation. The UK CPNI good practice guide on ICS security assessments, drawn from Idaho National Laboratory experience, adds the point most buyers learn the hard way: automated scanning tools can crash or stall field devices and should not be run against production. See the NIST SP 800-82 OT Security Guide for the wider control set.

Factor	Enterprise IT test	OT test
Primary concern	Confidentiality and data	Safety, availability and process integrity
Effect of a crashed device	Service restart, user complaint	Lost production, damaged equipment, environmental release or injury
Device tolerance	Hardened stacks, frequent patching	Legacy firmware, fragile network stacks, long patch cycles tied to outages
Change windows	Weekly or ad hoc	Planned turnarounds, sometimes once a year or less
Who must approve	IT system owner, CISO	Plant or site manager, process engineering, safety, operations and often the equipment vendor
Typical evidence	Exploited vulnerability, access gained	Architecture weakness, reachable path, insecure configuration, demonstrated on a replica where possible

Choosing the assessment type

CPNI separates vulnerability assessment, penetration testing and red teaming, and the distinction matters more in OT than anywhere else because the intrusiveness grows with each step. Most organisations get more from an architecture and configuration review plus a scoped penetration test of the IT/OT boundary than from a full adversary simulation against the control network.

Assessment	What it answers	Typical production impact	When to choose it
Architecture and configuration review	Is the design segmented, are remote access paths and accounts controlled?	None: documents, exports and interviews	First assessment, after major change, before any active work
Passive network assessment	What is actually talking to what, and which unexpected flows exist?	Negligible: mirrored traffic from a SPAN or TAP	To validate the asset inventory and the conduit model
Boundary penetration test (enterprise, DMZ, remote access)	Can an attacker cross from IT or the internet into the control zone?	Low if limited to IT-side and DMZ assets	Annual or after changes to remote access, jump hosts or vendor connections
Control network test on replica or bench	How do our specific controllers, HMIs and engineering workstations hold up?	None to production	When device-level assurance is needed, before procurement or upgrade
Limited active testing in production	Does a specific live control hold?	Real; needs outage window, vendor input and stop conditions	Only where replica testing cannot answer the question and the risk is accepted in writing
Red team or threat-led exercise	Would we detect and respond to a realistic intrusion?	Variable; must stop short of the control layer unless explicitly approved	Mature programmes with OT monitoring in place. See the Threat-Led Penetration Testing Guide.

Small versus large estates: a single-site manufacturer with one integrator may get most value from a review plus a boundary test each year. A multi-site utility or chemicals operator should rotate site-level assessments, keep a standing test environment, and run a passive assessment at every site before any active work.

Scoping an OT test

NCSC guidance on commissioning penetration tests says scoping should include risk owners, technical staff who know the system and a representative of the test team, and that unusual systems and uncommon protocols should be flagged at bid stage so providers can confirm they have the specialist skills. In OT that means bringing process engineering and operations into the room, not just the security team. The general mechanics are in the Penetration Test Scoping Checklist; the OT additions are below.

Zones and conduits: define scope by IEC 62443 zones and conduits or Purdue levels (enterprise, industrial DMZ, supervisory, control, field), and state which levels are in scope for passive work, active work, or not at all.
Asset inventory: provide the current inventory with make, model and firmware for controllers, HMIs, historians, engineering workstations and safety controllers. The joint CISA and partner guidance on OT asset inventory (August 2025) recommends combining physical inspection with a logical survey and vendor manuals; an assessment is a good time to reconcile both.
Protocols: list the industrial protocols in use (for example Modbus TCP, DNP3, EtherNet/IP, S7comm, OPC UA, PROFINET) so the provider can show relevant experience.
Excluded devices: name the safety instrumented systems, protection relays and any device with a known fragile stack, by IP and tag, as excluded from any active interaction. CPNI recommends agreeing excluded devices and addresses at the pre-assessment meeting.
Process state: state what the plant will be doing during the test (running, reduced load, shutdown) and freeze configuration changes for the duration so results are interpretable.
Remote and vendor access: include every remote access path, jump host, vendor VPN and cellular gateway. External remote services and internet-accessible devices are common entry routes (ATT&CK for ICS T0822 and T0883).
Objectives: write questions the test must answer, such as "can a compromised enterprise account reach an engineering workstation?", rather than "test the OT network".

Safety controls and stop conditions

CPNI's guidance is that an assessment plan defines what will be done rather than how, and that an on-call contact authorises each step. Turn that into written controls that the provider signs and the control room holds a copy of.

Hazard review before the test: run the test plan through the site's management of change or a short hazard review, with process safety present, and record the outcome.
Named roles: test lead, OT engineering owner, control room operator on the line for every session, safety representative and a vendor contact for critical controllers. NCSC also recommends a technical contact available at short notice throughout.
Passive-to-active gate: no active interaction with any device until passive results have been reviewed and the device, time and action are approved in writing by the engineering owner.
Abort triggers: agree in advance what stops testing immediately, for example any unexplained alarm, HMI communication loss, controller fault or mode change, unexpected network load, or an operator request. Any party can call a stop; only the engineering owner can restart.
Known safe state: confirm current backups of controller logic and configurations, and that manual operation works. CISA's primary OT mitigations call for routinely tested fail-safe mechanisms, islanding, backups and standby systems so manual operation is safe during an incident; a test window is not the moment to discover they are not.
Timing: schedule any production-side activity in a planned maintenance window or reduced-load period, with escorts on site, and keep a timestamped log of every action so operators can correlate events.
Restoration and close-out: the provider documents every change made, removes every tool, account and file, and the site verifies that devices and network are back to the pre-test baseline.

Test environments and digital twins

NIST SP 800-82 Rev. 3 discusses passive and active scanning and digital twins as distinct assessment approaches in its appendix on OT security capabilities, and CPNI advises that anything risky, especially exploit development, happens only on development or test systems. Buyers should decide which environment answers which question.

Environment	Fidelity	Cost and effort	Good for
Vendor or integrator lab	High for that vendor's kit	Low to the owner, needs vendor cooperation	Device-level testing, validating vendor security claims
Owner bench with spare hardware	High if firmware and logic match production	Moderate; keep it in sync	Repeatable testing, pre-upgrade checks, training
Backup, standby or offline production system	Very high	Requires an outage plan for the standby	Questions that a bench cannot answer
Digital twin or emulation	Varies; network and logic often good, device stacks weaker	High to build, low per test	Architecture and path analysis, response exercises
Production (passive only)	Exact	Low	Traffic and asset discovery, conduit validation

Record in the report which environment each finding was demonstrated in. A finding proven on a bench with matching firmware is strong evidence; one inferred from a version number alone should be marked as such.

Choosing and qualifying a provider

Use the Penetration Testing Provider Buyer's Guide for commercial evaluation; the OT-specific requirements are these.

Named OT experience: CVs for the actual testers showing industrial assessments in your sector and with your control system vendors, plus references from asset owners.
Service provider standard: ask how the provider meets IEC 62443-2-4, which sets security programme requirements for IACS service providers during integration and maintenance, and whether they can map findings to IEC 62443-3-3 system requirements and security levels. See the IEC 62443 Guide.
Scheme membership where required: for UK public sector and critical national infrastructure, the NCSC CHECK scheme assures companies to test those systems; ask whether the OT team members themselves hold the relevant status.
Safety competence: site safety induction, working at height or hazardous area training where relevant, and acceptance of the site's permit-to-work system.
Method transparency: a written description of what will be done at each Purdue level, which activities are passive, and which they refuse to do in production. A provider who cannot explain how they avoid disrupting a controller should not be on site.
Equipment hygiene: dedicated, clean test laptops, malware scanning before connection to the OT network, and no internet bridging from test equipment.

Contracts and authorisation

Written authority from the right owner: the authorisation letter is signed by someone who owns the plant and the systems, not only the CISO. Where the OT network is operated by an integrator or an outsourced provider, get their written consent too.
Third-party equipment: some controllers, metering or telemetry links belong to vendors, utilities or grid operators. Confirm ownership and get permission or exclude them.
Vendor warranty and support: check whether testing affects warranty or support contracts for safety and control systems and get the vendor's position in writing.
Liability and insurance: agree liability for production loss or equipment damage, confirm the provider's professional indemnity covers OT work, and tell your own insurer if the policy requires it.
Rules of engagement: attach scope, excluded devices, safety controls, abort triggers, communication plan and test windows to the contract so they are binding rather than advisory.
Supply chain requirements: NIST CSF 2.0 GV.SC-05 expects cybersecurity requirements to be written into supplier contracts; a test provider with access to control networks is such a supplier.

Where identity fits

OT tests repeatedly find the same identity weaknesses: shared engineering accounts, vendor remote access accounts that are never disabled, default passwords on HMIs and controllers, and service accounts used by historians and data diodes with broad rights. CISA's primary OT mitigations put default passwords, secure remote access with phishing-resistant MFA and disabling dormant accounts among its five priorities. Treat any credentials issued to testers the same way: unique, time-limited, logged and revoked at close-out. See the OT Security Guide for remote access and account controls.

Findings, data handling and remediation

Treat the report as sensitive: an OT test report is effectively a map of how to disrupt the plant. Classify it, limit distribution by name, require encrypted transfer and storage, and set retention and deletion terms for the provider's copies, captures and notes.
Packet captures and exports: captures and configuration exports may contain credentials, recipes and process data. Specify where they are stored, who may hold them and when they are destroyed.
Risk ownership stays with you: NCSC notes that the organisation owns risk decisions and that tester ratings are an input. Rate OT findings by consequence to the process, not by CVSS alone.
Remediation within OT constraints: many fixes need an outage or vendor approval. Use compensating controls (segmentation, conduit rules, monitoring) until the next window, and track each finding to a planned date.
Critical findings during the test: agree an immediate notification path for anything that suggests live compromise or imminent safety risk, and link it to the site's response plan. See the OT Incident Response Guide.
Retest after change: CPNI recommends reassessment after significant change; schedule a retest of fixed items within the next practical window.

Measuring the programme

Coverage: percentage of sites and zones that have had at least a review plus passive assessment in the last 24 months.
Safety record: number of test-induced process upsets, alarms or stops (target zero), with root cause for each.
Inventory accuracy: devices discovered by passive assessment that were not in the inventory, per site.
Remediation: median time from report to fix or compensating control for high-consequence findings, measured against outage windows.
Repeat findings: share of findings that recur from the previous assessment, especially remote access and account issues.
Replica use: proportion of device-level findings demonstrated on a bench or twin rather than in production.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	CA-8, CA-8(1), CA-8(2)	Penetration testing, independent test team, red team exercises
NIST SP 800-53 Rev. 5	RA-5, CA-2, CM-8, CP-4, SA-9	Vulnerability scanning, control assessment, component inventory, contingency plan testing, external services
NIST CSF 2.0	ID.RA-01, ID.IM-02, ID.AM-01, GV.SC-05	Vulnerabilities identified, improvement from tests, hardware inventory, supplier contract requirements
IEC 62443	2-4, 3-2, 3-3	Service provider requirements, risk assessment and zones/conduits, system security requirements and levels
CIS Controls v8.1	Control 18	Penetration testing programme
ISO/IEC 27001:2022	A.8.8, A.8.34	Technical vulnerability management, protection of systems during audit testing
ATT&CK for ICS v20	T0822, T0883, T0886, T0866, T0846, T0888	Entry and discovery techniques a test should show are blocked or detected

Common failure patterns

Treating OT as another IP range: an IT-focused provider runs its standard toolset across the control network and a controller faults. The fix is scoping by zone with explicit passive-only and excluded levels.
No operator involvement: the control room is not told, sees unusual behaviour and starts an incident response or a shutdown. Operators must be part of the plan and on the line.
Ignoring the IT/OT boundary: the test concentrates on field devices while the real exposure is a remote access account. The Colonial Pipeline ransomware attack began with an unused VPN account without MFA, and the operator shut down pipeline operations as a precaution even though the attack hit IT systems.
Stale replicas: the bench runs older firmware than production, so clean results give false comfort. Keep firmware and logic in sync or record the gap.
Report sprawl: the report is emailed widely and stored in shared drives. Handle it as sensitive operational data from the start.
Findings without outage plans: high-consequence findings wait for a turnaround nobody scheduled. Tie each to a window or a compensating control.

Practitioner checklist

Define scope by zone and Purdue level, marking each as passive, active (named devices only) or excluded.
Name safety systems, protection relays and fragile devices as excluded by IP and tag.
Run the test plan through management of change or a hazard review with process safety present.
Require named testers with OT and vendor-specific experience, and ask for IEC 62443-2-4 alignment.
Put a control room operator with stop authority on every session and agree abort triggers in writing.
Confirm controller backups and manual operation before any production-side activity.
Do device-level testing on a bench, standby system or twin; record which environment proved each finding.
Get written authorisation from plant ownership, integrators and owners of third-party equipment.
Classify the report and captures, restrict distribution and set provider deletion terms.
Track every finding to an outage window or compensating control and schedule a retest.

OT Penetration Testing Guide: Safe Testing of Industrial Control Systems