How to scan OT networks without breaking them

If you’ve worked OT, you’ve heard the story. A penetration tester runs an nmap scan against a substation. A protective relay reboots. A breaker trips. The lights go out for a city block.

The story is apocryphal in some tellings, real in others — but the principle is not in dispute. Industrial control systems are not designed to gracefully handle the kind of traffic an IT-grade scanner generates. And yet, every OT environment has unknown assets, unpatched firmware, and exposed protocols. The question isn’t whether to scan; the question is how to scan without becoming the incident.

This is how we built the OT module.

What active scanning actually does

When you point a generic vulnerability scanner at a Modbus PLC, here’s what happens:

• It sends rapid TCP SYN floods to discover open ports
• It opens connections and tries default credential pairs
• It sends malformed packets to fingerprint the device
• It may attempt a write to verify capabilities

Each of those steps was designed for IT systems that gracefully handle bad input. Industrial controllers were not. A protective relay running 1990s-vintage firmware does not have a robust TCP/IP stack. A SYN flood can crash it. A write attempt to a coil can change physical state. A malformed Modbus packet can cause a CPU exception that triggers a safety shutdown.

This is why “we’ll just run our IT scanner against the OT segment” is a sentence that should make a control systems engineer leave the room.

The read-only safe principle

We built the OT module on three principles:

1. No writes, ever. Every protocol probe sends only the queries necessary to identify the device and read its public attributes. Modbus diagnostic queries, S7comm read-only system data, BACnet “Who-Is” broadcasts — all read-only by protocol design or careful query selection.

2. Single-thread, low rate. No parallel sessions. No SYN floods. The probe behaves like a polite OPC client, not an aggressive scanner. A single TCP connection at a time, with timeouts that match industrial expectations.

3. No fingerprinting via crash. Some IT scanners identify devices by sending malformed packets and analyzing the error responses. That approach is forbidden in OT mode. We fingerprint by reading public identification fields the device is designed to expose — vendor ID, device ID, firmware version — never by triggering exception paths.

Per-protocol notes

Each of the eleven protocols has its own quirks. A few highlights:

Modbus

We send Function Code 17 (Report Server ID) and Function Code 43 (Read Device Identification). Both are read-only and explicitly defined for diagnostic purposes. We never send Function Code 5/6/15/16 (write coil/register) — these change physical state.

S7comm (Siemens)

We send the SZL (System Status List) read query. It returns CPU type, firmware version, and module list. We never send the password handshake — even an attempted authentication can lock the CPU into protected mode if the password is wrong.

EtherNet/IP / CIP (Rockwell)

We use a single List Identity UDP query. It’s a registered enumeration mechanism the device is designed to respond to. We do not enumerate CIP services or attempt class-3 connections.

BACnet

We send Who-Is broadcasts and parse the resulting I-Am responses. We never send WriteProperty or attempt to enumerate devices on remote networks via routing.

DNP3

This one we treat with extra care. DNP3 is common in utility SCADA — exactly the systems where a scanner-induced incident has the largest blast radius. We send only Read Class 0 requests, which return static device data and never trigger event reporting or control actions.

What you give up

Read-only safe probing means we don’t get the full picture an active scan would. We can’t enumerate every CIP service. We can’t fuzz Modbus exception handling. We can’t validate write-protection bypass.

That’s a deliberate tradeoff. The information we lose is exactly the information that requires risky probing to obtain — and the value of that information rarely justifies the risk to the production environment. For genuinely hostile probing, a controlled engagement on a non-production segment with the asset owner’s explicit authorization is the right tool. Continuous platform scanning is not.

What you get

What you do get, continuously, is:

• Vendor and model identification across 30+ industrial families
• Firmware version with change tracking over time
• Exposed protocols per device
• CVE correlation against public ICS vulnerability databases
• Compliance mapping to IEC 62443, NERC CIP, and NIST 800-82
• A persistent inventory that builds over weeks and months

It’s not everything. It’s the things that don’t require you to risk an incident to learn.

The honest summary

Most OT scanning tools either refuse to scan at all (because of liability) or scan unsafely (because they were built for IT). Read-only safe probing is what you do when you actually understand the environment and the consequences of getting it wrong.

If you’re evaluating a platform for OT visibility, the test is simple: ask the vendor exactly which protocol-level operations they perform. If the answer is vague, the answer is “we run a generic scanner with the speed turned down.” That’s not safe. That’s just slower-unsafe.