What Is PLC Penetration Testing?

It sits within the wider discipline of OT penetration testing (also called ICS or SCADA penetration testing), and differs from IT testing in one critical way: the cost of a mistake is measured in process safety and downtime, not just data loss.

Why PLC Penetration Testing Is Different From Everything Else in Security

If you have managed IT penetration testing programmes, the instinct is to scope, scan, exploit and report. In an OT environment, that playbook can cause the very incident you are trying to prevent. The differences are structural, not cosmetic.

Industry reporting underlines why this cannot be skipped. Recent studies point to sharp year-on-year growth in OT incidents with physical consequences and a rise in ransomware against manufacturers, while a significant share of Siemens S7 PLCs still in the field are older, vulnerable models. Organisations that understand these constraints do not skip testing. They test differently.

Understanding the PLC Attack Surface

Before any methodology makes sense, you need to know what you are actually testing. The attack surface is larger than most security teams assume:

The controller itself - firmware, ladder logic or structured text programs, and configuration.

Engineering workstations (EWs) - the Windows machines where control logic is written and downloaded to PLCs. These are the crown jewels of any OT environment.

HMI and SCADA servers - operator interfaces and supervisory systems at Purdue Level 2 and above.

Industrial protocols - Modbus/TCP, EtherNet/IP, S7comm, DNP3, OPC UA and Profinet, most designed without authentication or encryption.

Remote access infrastructure - vendor VPNs, jump hosts and support tunnels that cross the IT/OT boundary.

Safety instrumented systems (SIS) - independent controllers built to bring the plant to a safe state, which attackers increasingly target directly, as Triton demonstrated.

The uncomfortable reality: most industrial protocols were designed for reliability, not security. If an attacker can reach a PLC on the network, there is often little stopping them from reading or writing whatever they want - a gap compounded by the fact that most PLCs do not support modern controls such as 802.1X port-based network access control.

That is why ICS penetration testing that stops at the IT/OT firewall misses the point. The question is not only “can they get in?” but “once they are at Level 1, what can they do to the process?”

The First Principle: Safety Is Not a Phase, It Is the Constraint

Every penetration test has phases. A safe PLC penetration test has something else first: a set of non-negotiable constraints agreed before anyone touches a keyboard.

In our experience, incidents during security testing rarely come from sophisticated exploitation. They come from sloppy scoping - a tester scans a subnet nobody said contained a fragile legacy controller, or runs an active tool during a production-critical window. NIST SP 800-82 Rev. 3, the leading guide to OT security, makes the same point: assessments, including penetration testing, must be conducted with care so that OT operations are not adversely affected.

Pre-test checklist (all in writing)

The 7-Phase Safe PLC Penetration Testing Methodology

The methodology is built around one idea: maximise knowledge gained per unit of operational risk. It progresses from zero-risk activities such as documentation review to carefully controlled validation, and touches live production controllers only when there is no safer alternative - with explicit authorisation.

Phase 1: Scoping and Architecture Review (zero operational risk)

• Everything starts on paper. Before a single packet is sent, the team reviews:

• Network diagrams and Purdue-level architecture

• Firewall rulesets governing IT/OT and DMZ boundaries

• Remote access pathways - VPNs, jump hosts, vendor portals

• Asset inventories, including firmware versions and vendor support status

• Historians, engineering workstations and data flows between zones

Reviewing the architecture on paper first gives the team a full understanding of the environment before any testing begins. This phase routinely surfaces serious issues without touching production: flat networks that contradict the official diagram, undocumented vendor tunnels, and firewall rules that allow far more than intended.

Phase 2: Threat Modelling and Crown-Jewel Identification

Not all PLCs are equal. A PLC in a comfort-cooling loop carries different risk from a burner management controller at a refinery. Work with process engineers to identify the crown-jewel assets - controllers whose compromise would mean safety consequences, environmental release or catastrophic downtime - then model realistic attack paths. How would an adversary move from a phishing email in the corporate network to that controller, and with which techniques?

Map these paths to MITRE ATT&CK for ICS. The Triton intrusion maps to a long list of documented ICS techniques, from valid account abuse to program download and controller manipulation. This mapping gives you a defensible framework for what to test, and why.

Phase 3: Passive Discovery - Look, Don’t Touch

This is where OT testing genuinely diverges from IT. Instead of sending probes, you listen.

Network tap or SPAN port deployment to mirror traffic (usually from the Level 3/3.5 boundary) without injecting packets.

Protocol analysis with Wireshark to identify every controller, its protocol, communication partners and operating state.

Traffic baselining - normal cyclic traffic, programming connections and engineering downloads.

Asset reconciliation - compare what you observe with the documented inventory. The gap is often the first significant finding.

Visibility is the foundational problem in industrial security: surveys consistently show that only a minority of organisations have full OT asset visibility. Passive discovery carries no risk to control operations and answers critical questions: Which PLCs accept programming connections, and from where? Is anyone talking to the SIS network who should not be? Is plaintext Modbus crossing zones?

Phase 4: Configuration and Boundary Validation

With a traffic baseline in hand, move to controls testing - still without touching the PLCs themselves.

• Segmentation testing: verify, from a simulated compromised IT host, that firewall rules actually block unauthorised IT-to-OT paths, and that the industrial DMZ is the only bridge between worlds.

• Remote access review: Is MFA enforced on every vendor pathway? Are sessions recorded and attributable? Is access time-bound and removed when contracts end? Unauthorised external access features prominently in OT incident reporting.

• Engineering workstation assessment: patch status, local admin rights, removable media controls and protection of PLC project files. A compromised engineering workstation is the most dangerous position an OT attacker can hold, because it bridges cyber access to process-level change.

Phase 5: Controller-Level Assessment - Lab First, Production Last

Here is where most testing programmes go wrong: they want to “test the PLC” and point tools at live production hardware. Don’t. A safer, more defensible approach uses three tiers.

Write operations to production PLCs - downloads, mode changes, register writes - should be reserved for dedicated maintenance windows, if done at all. In many mature programmes they are never performed on live systems. Combining passive production observation with aggressive lab testing delivers most of the insight at a fraction of the risk. This mirrors NIST guidance to test changes on a test system under field conditions before they reach the OT system.

Phase 6: Safe Exploitation and Attack-Path Demonstration

When exploitation is validated, do it in the lab against the replica, then demonstrate the path, not just the punch. A board does not need to hear “we can crash a Modbus stack.” It needs to hear:

Phase 7: Reporting, Remediation and Retesting

The report must serve three audiences:

The Toolkit: What Professionals Use (and Avoid)

Common Mistakes That Turn Tests Into Incidents

1. Treating OT like IT. Default scanner configurations and broad active enumeration are a leading cause of testing-related outages in industrial environments.

2. Testing without operations in the room. OT teams know things no scan will tell you - which loop is unstable, which controller dislikes TCP retransmissions, when the plant is most sensitive.

3. Ignoring the safety systems. Attackers do not share your reluctance. Triton targeted the SIS precisely because defenders treated it as too sensitive to examine.

4. A report that ends in “patch it.” If the realistic answer is “during the next planned shutdown in 14 months,” the report is shelf-ware. Effective OT reporting always includes compensating controls.

5. Point-in-time thinking. A penetration test is a snapshot; attackers operate continuously. Use findings to drive continuous monitoring and recurring validation.

Aligning With the Standards Your Auditors Will Ask About

A well-scoped IEC 62443 penetration test maps cleanly onto the frameworks regulators and cyber insurers increasingly reference:

Anchor your methodology to these, and the pentest report becomes evidence of due diligence, not just a technical document.

Frequently Asked Questions About PLC Penetration Testing

Is PLC penetration testing safe?

Yes - when it is properly scoped, coordinated with operations, uses passive methods first, defines stop conditions and reserves active testing for lab replicas or approved maintenance windows. The methodology above ensures no production-affecting action occurs without explicit authorisation and a safety case.

How is PLC penetration testing different from a vulnerability assessment?

A vulnerability assessment lists what might be wrong. A penetration test proves what actually is: which weaknesses are reachable, exploitable and chainable into real attack paths. In OT this matters even more, because you need to know which of your thousands of scan findings are dangerous given your segmentation and compensating controls.

Can we test PLCs without taking the plant offline?

In most cases, yes. A mature programme gets the majority of its value from passive observation, configuration review and lab replication. Direct active testing on live controllers is the exception, not the rule.

How often should PLC penetration testing be done?

At minimum annually, and after significant change: new remote access pathways, network re-architecture, controller firmware upgrades or integration of acquired facilities. OT environments change slowly, but the connections around them change constantly.

Who should perform PLC penetration testing?

A team with demonstrated OT experience, not just pentesting certifications. Ask about prior industrial engagements, safety training and how they handle a PLC that crashes during testing. Their answer will tell you a great deal.

The Bottom Line

PLC penetration testing is not about proving you can break a controller. Any competent attacker can do that, Triton proved it at nation-state scale. It is about understanding your real exposure before someone hostile does, in a way that never puts your operation at risk.

Organisations that get this right share a pattern: they treat safety as a design constraint rather than a disclaimer, they test aggressively in replicas and passively in production, and they turn findings into compensating controls that survive the reality of unpatchable, decades-old control hardware.

If your current security testing programme cannot touch the OT environment without operations pushing back, the answer is not to stop testing. It is to test safely.