Safe OT Asset Discovery: How to Inventory the Plant Floor Without Knocking It Over

Picture it. It’s a Tuesday, somebody in security finally got budget for “OT visibility,” and the whole plan for OT asset discovery is a shiny new vulnerability scanner pointed at a /16 that nobody has drawn on a diagram since the Bush administration. Somebody hits Start. Twenty minutes later the phone in the control room rings, and it isn’t the help desk calling to say thanks.

I want to talk about how to avoid that phone call. You can’t protect what you don’t know you have, and every OT security framework worth reading starts with an asset inventory. The trick is building that inventory without poking the very equipment you’re trying to protect until it falls over. This post is my field guide to doing it the safe way: listen first, borrow what the network already knows, and only ask a device a question when you’ve earned the right to.

If you haven’t read it yet, my earlier post on IT/OT network segmentation, the Purdue model and IEC 62443 zones and conduits is the companion to this one. Segmentation tells you where the walls go. Discovery tells you what’s actually living inside them, and to be clear, you need both.

Why your IT playbook can tip over a PLC

On the IT side, scanning is routine. You sweep a subnet with nmap, you run a credentialed vulnerability scan every week, and if a server hiccups you reboot it and move on with your day. A lot of OT gear doesn’t play by those rules. PLCs, RTUs, protection relays and the little gateways that bridge serial to Ethernet were built to run one process, reliably, for fifteen or twenty years. Many of them carry small embedded TCP/IP stacks that were never tested against a burst of half-open connections, a malformed packet, a fragmented one, or a scanner fingerprinting every port from 1 to 65,535. Some of them handle a flood of unexpected traffic by dropping their communications module, faulting, or going to a stop state, and none of those are things you want to explain to operations.

This isn’t a theory, either. In 2005, Sandia National Laboratories published a short paper by David Duggan called Penetration Testing of Industrial Control Systems (SAND2005-2846P), and it opens with three real examples. A ping sweep on an active SCADA network caused a 9-foot robotic arm that was in standby to swing around 180 degrees. A ping sweep done “for inventory purposes” on a process control network hung a system in a chip fab and destroyed about $50,000 worth of wafers. And a penetration test of a gas utility’s corporate network wandered into a segment connected to SCADA, locked it up, and left the utility unable to move gas for four hours. A ping sweep. Not an exploit, not malware, just “hey, who’s out there?”

The federal guidance says the same thing in calmer language. NIST SP 800-82 Rev. 3 (September 2023), the government’s guide to OT security, warns that owners “should exercise extreme caution when permitting active scanning on an operational network,” that active scans “may cause device instability or interfere with the device process state,” and that they should be scheduled during planned outages whenever possible. One more time for the folks in the back: the device process state. That’s the part where a packet turns into something physical.

The same Sandia paper also hands you the alternative, in a little table that still holds up two decades later. Instead of a ping sweep, it suggests examining CAM tables on switches, examining router configs and route tables, physically chasing the wires, and passive listening. That’s basically the outline for the rest of this post.

Step one: listen before you talk

Passive discovery means you watch the traffic that’s already on the wire and you never add a packet of your own. NIST describes it as ideal for “sensitive devices found on OT networks that may exhibit unexpected behavior when directly probed.” Here’s how you get the traffic.

SPAN port or network TAP

A SPAN (mirror) port tells a switch to copy traffic from some ports or VLANs out to another port where your sensor lives. It’s cheap and you probably already own it, but it has a few gotchas: the switch treats the copy as low priority and can drop it when it’s busy, an oversubscribed SPAN (mirroring several busy ports into one) will lose packets, and a typo in the session config can mirror the wrong thing or add switch load you didn’t plan on. Change the switch config through your normal change process, because a switch on the plant floor is plant equipment, period.

A network TAP is a small piece of hardware that sits inline on a link and copies everything in both directions. A passive fiber TAP has no power and no brain, so if it dies the link keeps passing traffic. Copper TAPs for gigabit links generally need power, so look for fail-open designs. Installing one means a brief link interruption, which means a maintenance window, but once it’s in, you get every frame, including the errored ones, with nothing the switch can drop. For the links that matter most (the one between the supervisory layer and the controllers, for example), I’d take a TAP over a SPAN every time.

Either way, send the copy one direction only. The sensor’s capture interface should have no IP address and no way to transmit onto the monitored network. A listening post that can talk back isn’t a listening post anymore.

Deep packet inspection of industrial protocols

Feed that copy to a sensor that actually understands industrial protocols. That can be a commercial OT monitoring platform or an open source stack like Zeek with ICS protocol parsers (CISA’s own ICSNPP project publishes Zeek parsers for a bunch of them) or the Malcolm toolkit that bundles them. Plain IP and MAC data tells you something is there. Protocol-aware deep packet inspection tells you what it is and what it’s doing:

• Modbus/TCP (TCP 502): which HMI or SCADA server polls which controller, the function codes in use (reads versus writes), and the register ranges. If a device answers a Read Device Identification request during normal operations, you can catch the vendor and revision going by.
• DNP3 (usually TCP 20000): master and outstation addresses, polling patterns, and whether anyone is sending control operations or file transfers you didn’t expect.
• EtherNet/IP and CIP (TCP 44818, UDP 2222 for I/O): List Identity responses carry vendor, device type, product code, revision, serial number and product name, and engineering software does a lot of that chatter on its own.
• S7comm (TCP 102): Siemens controllers, the stations that program them, and the moments when somebody uploads or downloads a project.
• BACnet/IP (UDP 47808): building systems announce themselves with I-Am messages, and the device object holds vendor, model and firmware.
• OPC UA (TCP 4840 by default): servers, clients and their security modes. Watch for anything negotiating a “None” security policy.

The bonus is that passive monitoring doesn’t just find assets, it finds relationships. You learn who talks to whom, how often, over what, and that baseline becomes the rule set for your conduits. When the engineering workstation suddenly starts speaking S7 to a controller it’s never touched, that’s worth a look.

NIST is honest about the limits, and so am I. Passive discovery “cannot identify devices that are not actively communicating,” it can’t see inside encrypted traffic without extra setup, and it “will often take days to complete due to its dependence on existing network traffic.” A spare PLC sitting in a cabinet, a serial device behind a gateway, or a box that only phones home once a week may never show up. That’s why step one isn’t the only step.

Step two: borrow what the network already knows

Your infrastructure has been taking notes for years. Reading those notes is free, it’s quiet, and nobody’s controller ever faulted because you typed show mac address-table on a switch.

• Switch MAC address tables (CAM tables). Every active port, every MAC, every VLAN. The first half of a MAC (the OUI) usually tells you the manufacturer, and an unknown vendor on a controller VLAN is a great conversation starter.
• ARP tables on routers, firewalls and Layer 3 switches. They tie those MACs to IP addresses without you sending a single probe to the end device.
• CDP and LLDP neighbor tables. Managed switches, many industrial switches, and plenty of newer IP devices advertise themselves, which helps you draw the physical topology.
• Firewall rules, logs and NetFlow or IPFIX records. Who is allowed to talk across your zone boundaries, and who actually does.
• DHCP leases and DNS records, where OT uses them at all (a lot of it is statically addressed, so don’t count on it).

Pull these from the network devices, not by scanning through them. Read-only SNMP polling of your own switches or a scheduled config backup is a very different animal than throwing packets at the end devices behind them.

Step three: read the paperwork the plant already wrote

OT environments are documented, sometimes badly, but documented. The control engineers already know a lot of what you’re trying to discover, and the polite move (and the smart one) is to ask them before you build a sensor.

• Historians. The historian’s tag and point configuration lists the devices it collects from, often by IP or device name, plus what each tag means to the process. That’s criticality data you can’t get from a packet.
• Engineering workstations and project files. The PLC and HMI projects describe the controllers, the I/O modules, the firmware the project was built for, and the network settings. Get exports from the engineers. Don’t go rummaging on an engineering workstation yourself.
• Drawings and configs. Network diagrams, P&IDs, panel schedules, switch and firewall configs, vendor turnover packages and the spare parts list.
• A walk down. Flashlight, label maker, camera (with permission), and someone from operations. CISA’s guidance literally calls for “a physical inspection and logical survey,” and the walk down is where you find the cellular modem zip-tied inside a cabinet that never once showed up in a SPAN.

Compare all three sources. Passive monitoring finds the stuff nobody wrote down, the paperwork finds the stuff that isn’t talking, and the walk down settles the arguments.

Step four: selective active queries, done safely

Sometimes you really do need to ask. Passive data says there’s a Rockwell controller at an address, but you need the exact firmware to know whether a new advisory applies, and that controller hasn’t said its revision out loud in three weeks of listening. Fine. NIST describes a “safe active scanning” approach that “first learns about connected equipment through passive means and then uses device-specific communication” to get the rest. Here’s how I’d keep that safe:

• Speak the device’s own language. Use a single native protocol request the device is designed to answer, like an EtherNet/IP List Identity, a Modbus Read Device Identification, an S7 module identification read, or a BACnet ReadProperty on the device object. That’s the same kind of question the vendor’s own engineering software asks every day. A port sweep or an OS fingerprint is not.
• Target, don’t sweep. Query only the known address and known port you learned passively. No host discovery across the subnet, no all-ports scan, no “let’s see what else is out there.”
• Go slow. One device at a time, one request at a time, with a real delay between them. If your tool has a “safe” or “OT” profile, use it, and read what it actually sends.
• Never send the weird stuff. No fragmented packets, no malformed or fuzzed packets, no vulnerability checks, no brute-force logins, and nothing that writes, changes mode or touches a controller’s run state.
• Allowlist the source. Queries come from one known, hardened host whose address is in the firewall rules on purpose, so the traffic is expected, logged and easy to shut off.
• Test bench first. Run the exact tool, settings and request against the same make, model and firmware on a bench or in the vendor’s lab before it ever sees production. NIST recommends testing automated tools on offline systems before deploying them into the OT production environment, and that’s the cheapest insurance you’ll ever buy.
• Maintenance window and operations sign-off. Schedule it when the process can tolerate a hiccup, tell the control room before you start, have a named operator on the phone who can tell you to stop, and stop the first time anything looks off.

And if the answer from operations is “not on that one, not ever”? Respect it. Some devices (safety instrumented systems come to mind) get documented by hand and left alone, and that’s the right call.

What goes in the OT asset inventory

An inventory is only useful if it answers the questions you’ll have on your worst day. The August 2025 joint guide from CISA, NSA, FBI, EPA and international partners, Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators, lists the high-priority attributes, and I’d start right there:

• Active and supported communication protocols
• Asset criticality
• Asset number, role and type
• Hostname, IP address and MAC address
• Manufacturer, model and operating system (and I’d add firmware version and serial number)
• Physical location
• Ports and services
• User accounts and logging

On top of that I’d add the zone and conduit each asset belongs to (that’s your tie back to segmentation), the owner and the vendor support contact, how it was discovered and when it was last confirmed, and its end-of-support date. The CISA guide also pushes you to build a taxonomy that sorts assets by function and criticality, and it includes sample taxonomies for oil and gas, electricity, and water and wastewater, which are worth a read even if you’re in a different sector.

If you’re working toward ISA/IEC 62443, the inventory isn’t optional there either. IEC 62443-3-3 has a system requirement for it (SR 7.8, control system component inventory), which expects the control system to be able to report what components are installed and their properties. Besides, you can’t draw zones and conduits around equipment you can’t name.

Keep it current with change control

Here’s the part that separates a living inventory from a spreadsheet that was right once. Things change. A contractor swaps a failed I/O card, a vendor upgrades the HMI firmware, somebody adds a wireless bridge so they don’t have to walk to the far building in February. If the inventory doesn’t change with them, you’re back to guessing.

• Make the inventory part of the change process. No change ticket closes until the inventory is updated. CISA’s guide says the same thing: follow your change management process and require inventory updates whenever a device is added or removed, “in all cases, even under emergency change authority.”
• Let passive monitoring be the tripwire. A new MAC, a new IP or a new protocol conversation that doesn’t match an approved change should show up as an alert and a ticket, not as a surprise during an incident.
• Reconcile on a schedule. Compare the monitored network, the switch tables and the inventory every quarter (or after every major outage or project), and chase down every mismatch.
• Treat discovery itself as a change. Adding a SPAN session, installing a TAP or running a selective active query goes through the same approval as anything else on the plant floor.

The short version

Listen first with a SPAN or TAP and a sensor that speaks Modbus, DNP3, EtherNet/IP, S7, BACnet and OPC UA. Borrow what your switches, routers, firewalls and historians already know. Read the paperwork and walk the floor. When you have to ask a device a question, ask one question, in its own language, slowly, from an allowlisted host, on a tested setup, in a window that operations approved. Then keep the whole thing honest with change control.

Slow is smooth, and smooth is fast. The goal was never to find everything by Friday; it’s to find everything without being the reason the plant went down on Tuesday. Go figure it out, carefully.

References

• CISA, NSA, FBI, EPA and partners, Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators (August 13, 2025)
• NIST, SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security (September 2023), Appendix E.2.2 and E.2.3 on passive and active scanning, and Section 6.1.1 on asset management
• David P. Duggan, Sandia National Laboratories, Penetration Testing of Industrial Control Systems, SAND2005-2846P (March 2005)
• ISA, ISA/IEC 62443 series of standards
• CISA, ICSNPP: Industrial Control Systems Network Protocol Parsers for Zeek and Malcolm
• My companion post: IT/OT Network Segmentation: The Purdue Model Is the Map, IEC 62443 Zones and Conduits Are the Rules