Some time ago I was brought into an OT security engagement at a manufacturing facility. Their internal team had just finished a pentest using the standard IT approach: Nmap aggressive scan for asset discovery, Nessus for vulnerability scanning, then Metasploit to validate findings. The result: three PLCs on the production line entered a fault state and had to be manually reset by an engineer on the factory floor. Four hours of production lost.
Not because any exploit succeeded. Just because the scanner sent unexpected TCP probes.
That experience illustrates a problem I keep running into: many security teams treat OT (Operational Technology) as a variation of IT with different hardware. That assumption is dangerous.
Why OT is different
In IT, we work with the CIA triad in that order: Confidentiality, Integrity, Availability. In OT, the priority order is reversed, and safety sits above all three. Downtime on an email server is an incident. Downtime on an industrial control system can mean equipment damage, chemical spills, or worker injuries.
The protocols running OT environments were designed long before network security was a concern. Modbus was developed by Modicon in 1979 for isolated serial networks. No authentication, no encryption, no session management. Any device on the same network can send commands.
DNP3 has basic authentication options in its Secure Authentication version, but most deployed implementations I have seen in the field do not use it. OPC-UA as a newer protocol has built-in encryption and certificate support, but many facilities still run OPC-Classic alongside it with no security configured at all.
Device age compounds everything. The typical OT asset lifecycle is 15 to 25 years. A PLC installed in 2005 may have an engineering workstation still running Windows XP, with firmware that has not been updated since initial commissioning. Patching in OT is not an IT decision; it is a process that requires vendor qualification and planned maintenance windows scheduled far in advance.
What happens when standard IT tools enter an OT network
Nmap with aggressive scan options, Nessus, Metasploit: all of these send large volumes of active network probes. In IT environments, devices receiving those probes respond or ignore them. In OT environments, many PLCs are not built to handle unexpected TCP connections gracefully.
A Modbus PLC receiving TCP connections outside its normal communication pattern can halt or enter a fault state. Resetting it requires an engineer physically present at the device. This is not a theoretical scenario. The SANS ICS curriculum explicitly documents aggressive scanning as a known hazard in ICS environments.
There is another dimension that often gets overlooked: timing. OT real-time systems communicate in milliseconds. When a scanner consumes bandwidth or introduces unexpected latency on the same network segment as PLCs, controllers can lose synchronization with sensors or actuators.
The architectural gaps I find most often
The Purdue Reference Model (ISA-95) defines a Level 0 through Level 4 hierarchy. Between Level 3 and Level 4 there should be a DMZ, what the Purdue model calls Level 3.5. This zone acts as a buffer: data can flow from OT to IT through controlled mechanisms, but direct access does not exist in either direction.
In the majority of Indonesian industrial facilities I have assessed, this DMZ is absent. The OT historian connects directly to the corporate network. Engineers in a Jakarta head office can sometimes reach SCADA systems at a Central Java plant without passing through any meaningful network control.
Remote access is the most common OT attack vector I encounter. Vendors install cellular modems on PLCs for remote maintenance. The security team does not know about them because procurement happened on the operational or engineering side, not through IT. Those modems stay active after commissioning is complete, sometimes for years, with no monitoring and no proper access control.
Two incidents worth understanding
Stuxnet (2010) targeted Siemens S7 PLCs at an Iranian uranium enrichment facility. It used four zero-day vulnerabilities to modify PLC programming while reporting normal status to operators. Centrifuges were spinning outside safe parameters while the HMI showed everything as normal. The most thorough technical deconstruction of how it worked was published by Langner Communications, the team that first reverse-engineered the malware.
Triton/TRISIS (2017) targeted the Safety Instrumented System (SIS) on a Schneider Electric Triconex controller at a Middle East petrochemical plant. SIS is the last line of defense that prevents dangerous process failures. Triton was designed to disable that safety layer. The plant actually shut down when the malware accidentally triggered a fail-safe. It was the first documented case of malware specifically targeting safety systems.
The implication for OT assessments: SIS systems require separate evaluation from standard process control systems.
Common findings on a first OT assessment
Annual surveys from Claroty and Dragos consistently find that more than 80% of OT devices have never had a security review. That tracks with what I see in engagements. Not because there is no awareness, but because the old assumption that air-gaps provided adequate protection persisted long after those air-gaps were gone.
What to think about before starting an OT assessment
If your organization is considering an OT security assessment, a few questions to answer first: does the assessment team have specific OT experience, not just IT? Do they understand Modbus, DNP3, and IEC 61850? Does their proposed method include passive monitoring rather than relying only on active scanning?
Key reference documents: NIST SP 800-82 Rev. 3 for industrial control system security guidance, and the IEC 62443 series for compliance framing. In Indonesia, Perpres 82/2022 establishes mandatory security requirements for eleven critical information infrastructure sectors including energy, manufacturing, and transport.
Also: involve the operational team from the start. Decisions about what to test and when should include the engineers responsible for the process, not just IT or the CISO. They are the ones who understand the real consequences if something is disrupted.
OT security is not a subset of IT security. The approach is different, the tools are different, and the consequences of getting it wrong are far more immediate.