OT Pentest: Why SCADA, PLCs and Industrial Plants Need a Different Security Logic

The PLC had been running for 22 years. Nobody had ever tested it for vulnerabilities. Until an attacker did.

A mid-sized water utility in southern Germany. Three pumping stations, two treatment plants, one central control room. The SCADA system had been installed in 2003 — at the time, fully air-gapped, with no external connectivity. Over the years, the IT department had added remote maintenance access, a VPN tunnel to the control centre, and a web-based HMI for mobile monitoring. Each decision made sense on its own. Together, they had put a PLC that had never been patched in 22 years onto the internet.

In the course of an authorised OT pentest, we found within four hours of passive network analysis: unencrypted Modbus communication on port 502, reachable from the internet through a misconfigured firewall ruleset. No password. No authentication token. Full read and write access to the valve control system.

We could have altered the chlorine dosage. We could have shut down pumps. We could have manipulated pressure values until pipes burst. We did none of those things — but an attacker with different intentions would have. And nobody would have noticed until the first households had no water.

Why OT requires a different security logic than IT

In IT, the hierarchy is: Confidentiality, Integrity, Availability — in that order. Confidentiality first. In OT, this hierarchy is inverted. Availability comes first — because a pump that is not running, or a valve in the wrong position, can cause immediate physical harm. An OT pentest that ignores this logic is itself dangerous.

In practice, this means: a standard IT pentest with aggressive network scanning can crash a PLC. Not because the scanner is malicious — but because many PLC systems simply were not built to handle the speed and volume of an IT network scan. Industrial controllers from the 1990s and 2000s can enter undefined states under too many simultaneous connection attempts — with direct consequences for the physical processes they control.

This different security logic means: an OT pentest requires OT expertise. Not knowledge of SCADA systems as a bolt-on module — but deep understanding of industrial processes, protocols, and the consequences of every single test step on the running plant.

Where OT systems are vulnerable: the complete attack surface

OT attack surfaces have one characteristic that fundamentally distinguishes them from IT environments: they have grown over decades without security ever being a primary design consideration. Modbus was developed in 1979. DNP3 in 1990. Profibus in 1987. None of these protocols have authentication. None have encryption. They were designed for reliable communication in controlled, closed environments — not for a world where OT networks are connected to the internet via VPN and cloud services.

The insecure protocol landscape

IT/OT convergence: the most dangerous development of the last decade

OT used to be air-gapped. Physical separation from the IT network protected the plant — not because the systems were secure, but because nobody could reach them from the outside. Those days are over.

Remote monitoring, predictive maintenance, cloud connectivity for historian databases, VPN access for service technicians — each of these makes the plant more efficient. And each creates a new bridge between the IT network and the production environment. An attacker who has compromised the IT network only needs to cross that bridge.

Real attacks, real consequences

OT attacks are not theoretical. Colonial Pipeline 2021: ransomware in the IT network, OT proactively shut down — five days of pipeline outage, fuel shortages along the US East Coast, $4.4 million in ransom. Norsk Hydro 2019: ransomware in aluminium production, 800 million NOK in damages, manual plant control for weeks. Triton/TRISIS 2017: malware targeting Safety Instrumented Systems (SIS) specifically — the last protection layer before physical catastrophes in petrochemical plants.

Triton's objective was not data theft. Its objective was to disable safety systems — and thereby enable physical explosions or releases of hazardous materials. That is the dimension at stake in OT security.

OT pentest without production stoppage: the methodology

The most common concern when we raise the topic of OT pentests: "Could this endanger our running production?" The answer is no — if the test is conducted by people who know what they are doing. Our methodology strictly separates passive and active phases, and every active step is coordinated with the operations team in advance.

What we specifically assess

What NIS2, KRITIS, and IEC 62443 require from you

OT security is no longer a voluntary consideration. With NIS2 (December 2025) and the KRITIS-Dachgesetz (January 2026), OT security measures are legally binding for operators of critical infrastructure — with personal liability for senior management.

• NIS2 (Article 21): Explicitly mandates "supply chain security," "network security," and "security in production" — including OT environments. Initial incident notification: 24 hours. Penalty: up to €10M or 2% of annual revenue. Personal liability for management.
• KRITIS-Dachgesetz: Expands the operator scope and requires resilience plans that include physical and digital security of OT infrastructure. Obligation to demonstrate compliance to BSI — an OT pentest report is a recognised evidence document.
• IEC 62443: The international standard for OT/ICS security. Defines Security Levels (SL 1–4) for zones and conduits in OT networks. Our reports are aligned to IEC 62443 compliance requirements.
• BSI IT-Grundschutz (ICS profile): Concrete measures for industrial control systems in Germany. The basis for many KRITIS evidence submissions to BSI.
• CER Directive: Extends NIS2 to physical resilience — OT protection across the entire supply chain, including suppliers and maintenance contractors. Relevant for all organisations that are part of a critical supply chain.

What an OT pentest from us actually means

OT security is not an add-on to our portfolio — it is a standalone area of expertise. The difference from an IT provider who "also does OT": we know Siemens S7comm as well as we know Shodan dorks for SCADA systems. We know which PLC types freeze under too many simultaneous connection attempts — and we know it before we start the test, not after.

Our OT pentests cover the full spectrum — from purely passive analysis for running production environments to full-chain engagements that combine physical access, IT network, and OT environment. We deliver audit-ready reports for IEC 62443, KRITIS, NIS2, and BSI IT-Grundschutz — and we escalate critical findings immediately, not only in the final report.

Most importantly: production safety always takes precedence over test results for us. Every step is coordinated with your operations team. No test that is not reversible. No scan that endangers the plant.

Conclusion: OT security is not an IT problem. It is a business risk with physical consequences.

The PLC is running. The plant is producing. The SCADA system shows green. That is not a security proof — it is the normal state in which an attacker is preparing undetected. OT attacks are quiet. They leave no log entries in a system that was never built for security logging. They are only noticed when the valve no longer responds, the pump won't start, or production stops.

An OT pentest is not an IT pentest in a factory hall. It is a distinct discipline — with its own methodology, its own protocols, its own risk awareness. Operators of OT systems who have never tested them for vulnerabilities are operating a risk they cannot see. Until someone else sees it.

Further reading: what a breach in production actually costs is covered in the post on cost of a breach. How attackers gain physical access to facilities is covered in the series on visitor management and rogue devices. And what NIS2 and KRITIS concretely require is explained in the post on physical security compliance.