OT VAPT vs IT VAPT: why industrial environments need a different methodology

When an IT security team is first asked to test an OT network, the natural instinct is to open a familiar tool and run a scan. The result can be a PLC that stops responding, an RTU that hangs, or a SCADA server that enters an error state that requires manual recovery, all because of a standard network probe that would cause no harm at all on the IT side. OT VAPT is not IT VAPT applied to a different network. The methodology is different from the ground up, and understanding why matters before you decide which engagement your environment actually needs.

Why IT VAPT tools are dangerous in OT environments

Standard penetration testing tools, including Nessus, Metasploit, and even basic port scanners, are built on the assumption that the target is an IT system: a web server, a workstation, or a network appliance that can respond to probes without operational side effects. OT devices do not work that way.

A PLC that controls a valve or a conveyor belt was not designed to handle unusual network traffic bursts. An RTU collecting field data can hang when it receives a packet type it does not recognize. A Distributed Control System or SCADA server can enter a fault state that requires an engineer to intervene on-site. Historians and HMIs, Human Machine Interfaces, can lose synchronization or display incorrect state to operators.

In IT, these effects are acceptable in a test context because systems can be restarted and services have built-in recovery. In OT, an unplanned PLC shutdown can halt a production line, trigger safety alarms, or in serious cases create a dangerous physical condition requiring immediate response from plant personnel. OT systems also operate continuously: 24/7 availability is the expectation, and downtime costs are measured in production loss, not SLA credits.

How OT VAPT methodology works

The engagement starts with passive network discovery. The team places sensors or network taps to capture traffic already moving across the OT network. No probes are sent to any device. From captured traffic, analysts build a map of the network: which devices are communicating, which protocols they use, and how data flows between segments. Common OT protocols, including Modbus, DNP3, OPC-UA, Profinet, and EtherNet/IP, often carry no built-in authentication, which means anyone on the same network segment can read or write to devices using them.

Once the network map is established, the team moves to architecture review. This means assessing how closely the real environment matches the Purdue Model (ISA-95) that defines OT network zones: Level 0 for field devices, Level 1 for PLCs and RTUs, Level 2 for SCADA and DCS, Level 3 for operations and historians, a DMZ at Level 3.5, and Level 4 for corporate IT. Flat networks that connect corporate IT directly to OT without a proper DMZ are still common, and they represent a concrete risk: one successful phishing email on the IT side can give an attacker a direct path to the SCADA network.

Configuration review covers device settings, remote access paths, and firmware versions. This is where undocumented vendor access is often found: cellular modems or VPN tunnels installed by equipment vendors for support purposes that are unknown to the operations team and unmonitored by anyone.

Active testing, where it happens at all, is limited and scheduled during agreed maintenance windows. No exploit attempts are made against live production devices.

The most common findings

IT/OT network segmentation is the highest-priority finding category. A direct connection between corporate IT and OT networks without a firewall or DMZ means a compromise on the IT side can propagate to industrial systems. This is not a theoretical risk; several documented industrial incidents have followed exactly this path.

Undocumented vendor remote access is the category that most often surprises operations teams. Cellular modems and VPN tunnels added by equipment manufacturers during installation or subsequent service visits rarely appear in network documentation and are almost never monitored.

Protocol exposure on shared segments is a consistent finding in environments where IT and OT networks have grown together over time. Modbus and DNP3 devices visible to IT-connected hosts are accessible to any attacker who reaches those hosts.

Firmware that cannot be patched is not negligence. OT systems have lifecycles of 15 to 25 years, and patches for legacy PLCs often require vendor qualification that takes months or are simply not available. OT VAPT documents these gaps and recommends compensating controls: network isolation, monitoring, and access restrictions that reduce risk without requiring a patch that does not exist.

The difference at a glance

Which one do you need

What an OT VAPT report contains

An OT VAPT report differs from an IT VAPT report in what it prioritizes. Beyond a findings list and technical recommendations, it includes the actual network segmentation map compared to what the architecture should look like, a full device inventory that captures undocumented assets, an analysis of communication paths between Purdue Model levels, and compensating control recommendations for devices that cannot be patched.

If your environment includes OT devices controlling physical processes, the first conversation to have is about methodology, not scope.