Why “Just Run a Scan” Can Shut Down a Plant
Let me share a scenario that plays out more often than it should.
An IT security engineer is brought in to assess an OT environment for the first time. They are genuinely trying to help, sharp, well-trained, and experienced. They know their tools. They’ve run hundreds of vulnerability scans. So, they do what they always do: they set up their scanner, point it at the network, and hit go.
Within minutes, a controller stops responding. A process trips. An alarm goes off on the floor.
They didn’t do anything wrong by IT standards. But in OT, the scan itself was the incident.
I say this not to judge that engineer. I say it because before I entered OT, I would have done the same thing.
I hold a Certified Ethical Hacker (CEH) certification from EC-Council. Coming into this field, my view was straightforward: security is security. The principles are the same, the vulnerabilities follow the same logic, and a well-trained security professional should be able to assess any environment. My IT background was solid, and I genuinely believed it would translate.
The CEH framework, like most IT security training, assumes the target environment can handle a scan. that sending probe, generating traffic, and actively testing the systems is a normal part of the assessment process. That assumption holds in IT. However, in OT, it is the assumption that causes incidents.
Then I stepped into my first OT environment and realized I was wrong, not entirely.
The IT background helped me understanding networks, protocols, and how attackers think, all of that carried over. But how you apply that knowledge in OT has to change. I had a lot to learn, and more importantly, habits to unlearn.
OT Is Not IT – The Difference Is Physical
In enterprise IT, security prioritizes Confidentiality, Integrity, then Availability (CIA). A breach is serious. Downtime is inconvenient. But a crashed server doesn’t injure anyone.
In OT that order is inverted. Availability first. Because a crashed server is an inconvenience. A crashed controller is a safety event.
In OT the stakes are different. A tripped relay in a substation affects thousands of homes. A halted production line can cost hundreds of thousands per hour. Downtime here is not an inconvenience.
The systems on these networks were built for one purpose: keeping processes running. Not for handling the traffic an active scanner generates at them.
When you send high-volume probes across the network, a server handles it. A legacy PLC may simply freeze. And when that happens mid-operation, the real world feels it.
From Day One, It Was Drilled Into Me
You do not run an active scan on a live OT environment. Full stop.
Not because of process. Because the consequences can be catastrophic, and they have been.
It almost always comes from good intentions. The intent is right. The method is wrong.
This is why OT-specific assessment methodologies exist. You learn what’s on the network by watching it, not interrogating it.
“The best OT security engineers aren’t the ones with the most tools. They’re the ones who know when not to use them.”
Before I Touch the Network: Preparation, Then Conversation
The first thing I do is request whatever documentation exists: network diagrams, P&IDs, architecture drawings, previous assessment reports, vendor datasheets.
Not to take it at face value. Documentation in OT is almost always incomplete or outdated. But it tells me where the gaps are likely to be and which questions to bring to the room.
Then, with that groundwork done, I get operations, engineering, and IT in the same room.
Not separately. Together.
Because I’ve already reviewed the documentation, I’m not walking in blind. I’m walking in with specific questions. That changes the conversation from a generic kick-off into a focused technical discussion.
This isn’t process overhead. The documentation review and the joint conversation together. That is the assessment foundation.
There is something I have found to be true in every OT environment I have assessed:
“Every team carries a different version of the truth.”
IT thinks they know what’s on the network. Engineering thinks they know how the systems behave. Operations knows what actually happens on the floor. None of them are wrong. But the real environment lives in the gap between all three.
If I don’t understand what’s critical and what cannot be interrupted, I am operating blind. In OT that doesn’t just mean missing a vulnerability. It means I could cause the very incident I was hired to prevent.
What OT VAPT Actually Looks Like
A proper OT VAPT is nothing like IT equivalent. Here is what it actually involves:
Passive monitoring first: Before anything active, we observe. Traffic is captured and analyzed across industrial protocols like Modbus, DNP3, and EtherNet/IP. This step alone regularly turns up undocumented assets and unintended communication paths, without a single probe sent.
Architecture and configuration review: We review zone segmentation against different industrial standards, firewall configurations, remote access pathways, and historian setups. In most environments I have assessed, the serious risks are structural. A flat network with no zone separation is a bigger problem than any individual unpatched device.
Physical walkthrough: Sometimes the vulnerability is a USB port on an HMI in an unlocked cabinet. Or an engineering laptop with no endpoint protection sitting permanently on the control network. You find these things by walking the floor, not by running a tool.
Controlled, targeted active testing, only where appropriate: Where the environment permits, limited active testing is done under tight controls: isolated segments, an agreed maintenance window, and vendor confirmation that target devices can tolerate the testing. Sign-off from engineering and safety is not a formality. It is what prevents the assessment from becoming an incident.
What a Good OT VAPT Report Actually Gives You
After running a comprehensive VAPT, what you should walk away should not be a CVE list. It should be risk in context: each finding connected to the asset, the process it controls, and the operational impact if that process is disrupted.
That is a report an operations manager can actually act on.
The Principle I Carry Into Every Assessment
The engineers who cause the most damage in OT aren’t the incompetent ones. They’re the confident ones who move fast without looking first. I have seen it firsthand. Incidents that took weeks to recover from, all because someone skipped the understanding phase.
The first conversation “getting ops, engineering, and IT in the same room, is not overhead. It’s the assessment.” Everything that follows is informed by it or compromised without it.
If you’re an IT security professional stepping into OT for the first time, I’ve been exactly where you are. The IT background matters. But you will need to relearn how to apply it. The priorities are different, the risk decisions are different, and the consequences sits in a different category.
If you’re an operations manager considering an OT security assessment, ask the assessors how they start. If the first answer is a scan, keep looking.
