OT security assessment: ICS penetration testing guide

An OT security assessment and an ICS penetration test are the technical way to know, with evidence rather than assumptions, whether an automation and control environment would withstand a real attacker without compromising the physical process. Unlike a web or corporate infrastructure audit, the goal here is not to protect data but a process that spins turbines, doses reagents, or governs a production line. A poorly planned aggressive scan can degrade a critical communication or halt a plant. That is why an OT security assessment is designed and executed very differently from an IT pentest.

This article describes how the scope is defined and how an industrial penetration test is actually run: asset discovery, passive versus active testing, safe and non-destructive testing over live OT, mapping to the Purdue Model zones and to IEC 62443, tooling, deliverables and a remediation roadmap, and the engagement model. For the domain fundamentals we point to what OT/ICS security is, and for the technical reference framework to IEC/ISA 62443.

The essentials. An OT pentest is not an accelerated IT pentest. Availability is the absolute priority, devices are fragile, and many protocols lack authentication. The methodology always starts with passive discovery, prioritizes non-destructive testing, reserves active tests for non-production environments or controlled windows, and maps every finding to the Purdue Model zones and to the IEC 62443 security levels. The deliverable is not a list of CVEs but a remediation roadmap by zone and by process risk.

Why an OT Pentest Is Not an IT Pentest

In IT, the security triad prioritizes confidentiality. In OT, the order inverts: availability, integrity, then confidentiality. Stopping a web server during a scan is a nuisance; stopping a PLC that controls a boiler is a physical safety incident with consequences for people and equipment. This difference shapes the entire methodology.

OT assets are also especially fragile. Many PLCs and RTUs with old TCP/IP stacks reset or fail on a normal SYN scan, a malformed query, or simply a volume of connections a modern server would not even notice. On top of that, protocols such as Modbus/TCP, DNP3, EtherNet/IP (CIP), S7comm, or Profinet were born for isolated, trusted networks, with no native authentication or encryption. That legacy design, more than any single vulnerability, is the real playing field of industrial pentesting: whoever reaches the control segment can usually read and write registers without credentials.

The practical result is a rule that governs all the work: in OT you test nothing you cannot justify, and you touch no production asset without an explicit window and authorization. The assessor's quality is measured as much by what they find as by what they avoid triggering. For the threat context that makes this urgent, it is worth reviewing the critical IoT/OT threats in 2026.

Scoping and Asset Discovery

The scope of an OT assessment is defined in a pre-engagement workshop involving security, operations, and, where one exists, the functional safety officer. That is where the rules of engagement are agreed: which segments are in, which assets are expressly out (safety instrumented systems almost always are), which maintenance windows can be used, and who has the authority to abort a test in real time.

The first technical task is the inventory, because you cannot audit what you do not know. In OT a reliable inventory rarely exists, so it is reconstructed by combining sources:

• Passive discovery from a traffic copy (SPAN or TAP) analyzed with OT tools such as Nozomi Guardian, Claroty CTD, Dragos Platform, or the open GRASSMARLIN utility, complemented with Wireshark and Zeek for protocol detail.
• Documentary review of network diagrams, PLC lists, managed switch configurations, and ARP tables from network gear, which surface assets that passive traffic does not reveal if they are silent.
• Interviews with operations, who usually know about legacy equipment, vendor remote access, and undocumented connections that no tool detects on its own.

The goal of this phase is a validated asset inventory, a communications map, and a network architecture. On that basis risk can be reasoned about; without it, any active test is a shot in the dark.

Passive Versus Active Testing in OT

The intrusiveness ladder is the heart of the methodology. You climb it rung by rung, and only when the previous one is not enough to answer the risk question.

Passive analysis. It injects not a single packet into the control network. From captured traffic it identifies assets, firmware versions, flows between zones, cleartext protocols, credentials transmitted unencrypted, and communications crossing Purdue Model levels that should not be touched. A huge share of valuable findings comes from here, with no risk to the process.

Non-destructive active testing. When exposure needs confirming, careful probing is used: device identification queries on industrial protocols, service enumeration with conservative profiles (Nmap with a low --max-rate, no aggressive or version scans against sensitive PLCs), and segmentation verification by trying to reach restricted zones from others. These tests run preferentially against the industrial DMZ, IT/OT boundary assets, and non-production systems.

Intrusive active testing. Modbus register writes, state changes, exploitation of specific CVEs, or denial-of-service tests are reserved for a lab environment, a digital twin, a test bench, or an agreed shutdown window. They are never launched against a live process asset without a rollback plan and operations sign-off. This same principle of grading risk appears in the differences between white-box, black-box, and grey-box auditing applied to the industrial world.

Mapping to Purdue Zones and IEC 62443

An industrial pentest does not deliver loose findings: it places them in the architecture. The Purdue Model organizes the environment into levels, from the physical process and instrumentation (level 0), through basic control (level 1), SCADA supervision (level 2), and plant operations (level 3), up to the industrial DMZ (level 3.5) and the corporate domain (levels 4 and 5). Each finding is tagged with the level where it lives and, above all, with the improper crossings between levels that an attacker would use to pivot from IT into OT.

Over that map the IEC 62443-3-2 assessment is overlaid, partitioning the system into zones and conduits and assigning each zone a target security level (SL-T). The pentest supplies the measurement of the real side: it contrasts the achieved level (SL-A) against that target using the system requirements of 62443-3-3 and the component requirements of 62443-4-2. The distance between what the zone needs and what it delivers is the gap the assessment quantifies. For the detail of this framework, we point to the analysis of IEC 62443 as an OT cybersecurity standard.

As additional reference, each observed technique is cross-walked with MITRE ATT&CK for ICS and with NIST SP 800-82 Rev. 3, which translates the technical finding into a language of adversary tactics and controls recognizable to a regulator or a CISO.

Tooling and Techniques

The toolkit combines generic utilities used with extreme caution and OT-specific tools:

• Discovery and protocol: Wireshark and Zeek for passive dissection; OT platforms (Nozomi, Claroty, Dragos) for inventory and anomaly detection; GRASSMARLIN for passive topology.
• Industrial enumeration: Nmap NSE scripts from the Redpoint project (s7-info, enip-info, modbus-discover, bacnet-info), plcscan, and lightweight Modbus, DNP3, or OPC UA clients for non-destructive identification.
• Controlled exploitation: Metasploit and its SCADA modules, the Industrial Exploitation Framework (ISF), and proof-of-concept work on specific CVEs, always in a lab or window.
• Remote access and segmentation: review of jump hosts, vendor VPNs, industrial firewall rules, and data diodes, where the real exposure usually concentrates.

On reference vulnerabilities, the pentest contextualizes cases such as CVE-2021-22681 (hardcoded key in Rockwell Studio 5000), the OT:ICEFALL set documented by Forescout with 56 flaws across products from multiple vendors, or the capabilities of the PIPEDREAM/INCONTROLLER malware flagged by CISA. It is not about collecting CVEs, but about showing which concrete paths exist from the entry point to the asset that governs the process.

Deliverables and Remediation Roadmap

The value of the assessment materializes in the report, and in OT that report has a structure of its own:

1. Executive summary with process risk in business language, not just CVSS.
2. Asset inventory and architecture validated during discovery.
3. Findings with evidence, severity, impact on the process, and location in the Purdue Model.
4. Gap against IEC 62443, with the SL-A versus SL-T contrast per zone.
5. Prioritized remediation roadmap by risk and by effort, grouped by zone: segmentation and reinforcement of the industrial DMZ, hardening of vendor remote access with a jump host and MFA, continuous passive monitoring, patch management in windows, and procurement requirements on suppliers under 62443-4-1.
6. Retest of the applied fixes.

Remediation acknowledges that in OT you do not patch on demand: many actions are compensating (segment, monitor, restrict flows) because updating firmware requires a shutdown. The underlying good practices are detailed in the article on SCADA security: threats and best practices.

Engagement Model

An industrial pentest is contracted in phases and with close coordination with the plant. The usual sequence is: scoping workshop and rules of engagement, a risk-free passive phase, a non-destructive active phase over the boundary and DMZ, intrusive tests only in a lab or shutdown window, and a closing session with operations. The work can be on-site (essential for the traffic tap and physical validation) or hybrid, and it always includes an immediate abort channel.

This approach aligns with NIS2, which raises the requirements on industrial environments and their supply chain. The relationship between OT auditing and this framework is developed in Industry 4.0 and OT cybersecurity under NIS2, and the general logic of contracting and running a pentest is explained in the pentesting guide for businesses.

Frequently asked questions

Is it safe to run a pentest on a plant in production?

Yes, if it is done with OT methodology. The passive phase injects no traffic and has no impact. Active tests are graded, confined to the IT/OT boundary and the DMZ, and anything intrusive is reserved for a lab or shutdown windows. Risk is managed with rules of engagement, an abort channel, and operations sign-off.

What is the difference between an OT pentest and an IEC 62443 audit?

They are complementary. The IEC 62443 audit evaluates the design, the zones, the conduits, and maturity against the standard. The pentest supplies practical validation: it tries to reach and manipulate assets to measure the security level actually achieved (SL-A). The ideal is to combine them, using the pentest to verify the assumptions of the risk assessment.

Are PLCs really exploited during the assessment?

Only in an environment where it is safe. On production assets, passive observation and non-destructive probing take priority. Register writes, state changes, or CVE exploitation are moved to a test bench, a digital twin, or a scheduled shutdown, never against the live process without a rollback plan.

What deliverables should I expect?

An executive summary oriented to process risk, a validated asset inventory and architecture, findings located in the Purdue Model, a gap analysis against IEC 62443 per zone, and a prioritized remediation roadmap, with a retest of the fixes. The report should serve the technical team, management, and a NIS2 auditor alike.

How long does an industrial pentesting project take?

It depends on size and segmentation, but a typical mid-sized plant scope usually runs between two and four weeks, with the passive phase and discovery concentrated in the first part and active tests coordinated in agreed windows. Multi-plant environments are addressed in phases.

Related Resources

• What OT/ICS security is
• IEC/ISA 62443: OT cybersecurity standard
• SCADA security: threats and best practices
• IoT/OT cybersecurity: critical threats in 2026

OT Security Assessment and ICS Penetration Testing with Secra

Secra runs industrial pentesting and OT/ICS assessments with operational sensitivity: we start with passive discovery, grade every active test, map findings to the Purdue Model and to IEC 62443, and deliver a remediation roadmap prioritized by process risk. We work in coordination with the plant, respecting its windows and its constraints.

If your organization needs to validate the resilience of its industrial environment before an attacker does, explore our IoT/OT security audit or contact our team for a no-commitment initial conversation.