Every OT penetration test scope document answers the same question at a high level: what is in, what is out, and who signs off.
For a manufacturing environment, that process is well understood. The harder question comes next, and it is the one that trips up even experienced security teams: for the specific PLC running your welding cell, the HMI on your packaging line, or the engineering workstation your controls team uses every day, what does “testable” actually mean?
A blanket answer does not hold up on a real plant floor. A Siemens S7-1500 controller running a robotic work cell and an MES server tracking production yield are both technically “OT assets,” but they carry completely different risk profiles under active testing. PROFINET and OPC-UA are both “industrial protocols” running on the same factory Ethernet, but one was built with zero authentication for cyclic real-time control and the other was built with security as a design requirement.
Treating these systems in the same way can create operational risk. A routine scan or a malformed test request can disrupt a fragile controller or interrupt a process that depends on precise timing. NIST SP 800-115, Section 2.3, warns that direct interaction with a system during security testing can produce unexpected results, including system halts and denial of service. That is why an OT penetration test needs a scope that accounts for the specific machine, not just the plant network.
This guide gives manufacturing security leaders and plant IT teams a practical way to draw that line: asset by asset, protocol by protocol, mapped to where each one sits on your floor.
Also Read: Inside OT, ICS & IoT VAPT: What CISOs Need to Test, Scope, and Defend
A Fast Refresher: Why the Purdue Model Sets the Boundaries on Your Floor
The Purdue Model helps organize assets by function and operational consequence. IEC 62443 complements that view by providing a framework for defining security zones and conduits based on risk. Used together, they help testing teams determine where assets belong, how communications between zones should be controlled, and which testing methods are appropriate for each area. It matters for penetration testing because testability drops sharply as you move down the stack:
- Level 0 - Physical Process: Robotic actuators, conveyor motors, and sensors on the line. No penetration testing applies directly here. Impact shows up as physical movement.
- Level 1 - Basic Control: PLCs and RTUs running welding cells, CNC machines, packaging lines, and safety instrumented systems (SIS) guarding presses and robotic cells. This level is where testing carries the highest safety consequences.
- Level 2 - Supervisory Control: HMIs and SCADA/DCS servers give line operators visibility and control.
- Level 3 - Operations Management: Engineering workstations, historians, and manufacturing execution systems (MES) tracking production, yield, and quality.
- Level 3.5 - Industrial DMZ: A recommended buffer zone between plant operations and enterprise IT. It provides a controlled point for managing traffic between the two environments and can be an appropriate place to assess boundary controls, remote access, and permitted communications. The testing scope should still reflect the assets and services hosted in the DMZ.
- Level 4/5 - Enterprise IT: ERP, email, and business systems. Standard penetration testing rules apply.
Purdue levels tell you where the consequences live on your floor. They do not, by themselves, tell you what method is safe. That takes a machine-by-machine and protocol-by-protocol view.
The Asset-Level Line: What's Fair Game and What Isn't
PLCs and RTUs Running Your Production Lines (Level 1)
The PLCs controlling your welding cells, CNC machines, and packaging lines execute logic that directly drives physical output. Most run on real-time operating systems with thin TCP/IP stacks that were never built to withstand a real vulnerability scanner, let alone an exploit attempt. A malformed packet that a modern IT server would silently drop can freeze a controller mid-cycle and halt the line behind it.
Where the line sits: Use passive traffic analysis and offline configuration review for production PLCs and RTUs. Perform active testing only against a lab replica or digital twin, not against a live production controller. A digital twin, in this context, is a non-production replica of the control logic used to evaluate security behavior without interacting with the live controller. Review exported configuration files, firmware information, and control logic offline to identify weaknesses without disrupting the production device.
Safety Instrumented Systems (Level 1)
SIS controllers guard against the presses, robotic cells, and conveyor interlocks that exist specifically to prevent injury and equipment loss when something else fails. Safety Instrumented Systems (SIS) protect against dangerous operating conditions, including failures involving presses, robotic cells, and conveyor interlocks. Exclude SIS controllers from active penetration testing under this assessment's rules of engagement. IEC 62443-3-2, Zone and Conduit Requirement 3.3, provides a basis for placing safety-related assets in their own zone. That separation should be reflected in the scope, access restrictions, and approved testing methods. [2]
Line HMIs and SCADA/DCS Servers (Level 2)
HMIs on the plant floor and supervisory servers are Windows or Linux-based in most modern deployments, which makes them look more like with IT targets. That familiarity is deceptive.
A line of HMI often runs vendor software that has not been patched in years because a patch cycle means a certified requalification of the line. Credential attacks, authentication bypass testing, and known-vulnerability validation are generally appropriate here with proper coordination. Testing that could interrupt the display or control function, such as aggressive scanning or session flooding, needs a maintenance window and an operator standing by.
Engineering Workstations, Historians, and MES (Level 3)
This is usually the most productive and safest place to run a thorough active assessment on a manufacturing floor. Engineering workstations hold the programming software, project files, and often cached credentials for every controller in the plant, which makes them a high-value target for a real attacker and a legitimate, well-bounded target for a tester. Historians and MES servers store production and quality data rather than control logic, so a compromise there is a confidentiality and integrity problem rather than a physical safety one. Standard penetration testing techniques, including privilege escalation, credential harvesting, and lateral movement testing, are appropriate on these assets with the same rigor applied to a corporate IT engagement.
The Protocol-Level Line: What Your Floor's Protocols Can Actually Absorb
The asset type tells you what machine you are looking at. The protocol tells you what happens when you talk to it. The two do not always point in the same direction. An engineering workstation (generally testable) that authenticates controllers over unauthenticated PROFINET is a different scoping conversation than the same workstation talking to controllers over a properly configured OPC-UA connection. Manufacturing floors run a specific mix of protocols, and each one carries a different testing risk:
| Protocol | Typical Purdue level | Where it runs on your floor | What active testing does to it | Recommended approach |
|---|---|---|---|---|
| PROFINET / EtherNet/IP | Levels 1-2 | Factory Ethernet and line-control networks | Delays or malformed frames can disrupt timing-sensitive control traffic. | Passive capture via an approved SPAN/mirror port or TAP; limit active testing to approved diagnostic services in a controlled scope. |
| Modbus TCP/RTU | Levels 1-2 | Legacy machines and automation cells | Unexpected function codes or malformed messages can produce unpredictable device behavior. | Passive analysis first; active function-code testing only against non-production replicas. |
| S7comm / S7comm-Plus | Levels 1-2 | Siemens PLC communications | Protocol-specific implementation weaknesses can affect controller availability. | Offline configuration and firmware review; active testing against a lab replica. |
| OPC UA | Levels 2-3.5 | Integration between control systems, MES, historians, and the IT/OT boundary | Insecure configuration, weak access controls, or implementation of flaws can expose data and services. | Test authentication, authorization, certificates, encryption settings, and configuration within the approved scope. |
| DNP3 | Depends on deployment; often Levels 1-3.5 in utility-related environments | Sites with integrated power or water infrastructure | Poorly controlled requests or implementation weaknesses may disrupt communications. | Passive first; use protocol-aware testing in a controlled environment and coordinate with the system owner. |
Putting the Two Views Together
The asset view and the protocol view answer different questions, and a manufacturing scope document should be used for both. A well-scoped engagement supports more thorough active testing where the workstation or server sits behind a properly configured protocol and calls for more caution where a device's every command reaches a live controller unauthenticated.
This is the practical output manufacturing decision-makers need from a scoping exercise: not just a list of in-scope IP addresses, but a matrix that shows, for every machine and system on the floor, its Purdue level, its protocol exposure, and the specific method approved for testing it. That matrix is the artifact plant operations leadership can actually sign, because it answers their real question in their own terms: what could go wrong here and how contained it is.
Also Read: Map Your OT Attack Surface Before the Next Audit
Moving Ahead
An OT penetration test should never treat every asset like an IT server. A PLC, HMI, engineering workstation, and SIS can sit on the same plant floor while carrying very different testing risks. The right scope connects three things: where the asset sits, how it communicates, and what happens when testing goes wrong.
Map each asset to its Purdue level. Identify its protocols. Define the testing method it can safely handle. Then get plant operations to sign off before testing starts. The goal is not to test everything. It is to test what matters, without becoming the incident you were hired to prevent.
