OT Devices: The Asset Inventory Problem Every MSP Inherits

Lead your next OT engagement with a safe, fixed-scope asset discovery.
Get a Pentest Quote
OT Device Inventory title card with a server icon in the MSP Pentesting brand style.

OT devices are the one class of asset your client can't hand you a straight list of. PLCs, HMIs, RTUs, historians, safety instrumented systems, plus the switches and vendor remote access boxes wired between them. Ask for the inventory and you'll get a spreadsheet that's two years stale and missing a large share of what's plugged in right now.

That gap is the whole problem. Every control you'd sell after this point assumes the list is right.

Here's the uncomfortable version.

You can't segment a network you can't draw. You can't patch a device you don't know exists. And the last person who genuinely knew what was on that plant network retired several years ago.

MSP Pentesting runs OT asset discovery channel-only, behind your brand. It's the engagement we tell partners to lead with, because it's the one a plant manager says yes to without convening a committee.

What counts as an OT device

Start with the definition, because scope arguments burn the first week of every engagement. An OT device is anything that senses, controls or reports on a physical process, plus the network gear dedicated to carrying that traffic. Here's what turns up on a typical site.

Device classWhat it doesWhy it goes missing
PLCRuns the control logic for a machine or lineBought as part of a machine, tracked as capital equipment, not as IT
HMI or operator panelLocal screen an operator uses to run the lineOften an embedded Windows box counted as a panel, not as a computer
RTUCollects field data at a remote site, common in water and energySits at a pump station miles away on a modem nobody billed to IT
SCADA or DCS serverSupervises and coordinates multiple controllersThe primary is known. The redundant pair and the dev copy aren't
Process historianTime-series database of everything the process didStraddles OT and IT, so each side assumes the other owns it
Safety instrumented systemIndependent layer that trips the process to a safe stateDeliberately kept separate, then treated as a safety asset, not a network asset
Engineering workstationHolds project files and vendor programming softwareFrequently a laptop in a drawer, powered on only during maintenance
Industrial switch or gatewayCarries plant traffic, converts serial to EthernetUnmanaged units get installed by integrators with no change record
Protection relay, VFD, robot controllerPurpose-built devices that grew their own IP stacksNobody thinks of a drive as a network device until it exposes a web interface
Vendor remote access applianceLets an OEM dial in to support a specific machineInstalled under a service contract, invisible to IT, sometimes on its own uplink

Look at the pattern in that right-hand column. Almost none of this is missing because somebody was careless.

It's missing because it was bought and installed by a function that isn't IT, on a capital cycle IT never saw.

Why nobody has an accurate inventory

Six structural reasons. Only one of them is fixable with tooling.

  • The asset was a machine, not a computer. A stamping press with four PLCs, a safety controller and an HMI arrives on a purchase order as one line item. Finance tracks one asset. The network sees six.
  • Integrators commission and leave. The systems integrator built the cell network, documented it in a drawing set, handed over a binder and never touched a CMDB. Three line changes later, the binder is fiction.
  • Your existing tooling can't see it. RMM and EDR cover whatever accepts an agent. A PLC won't. So a plant with dozens of live devices reports a handful, and the dashboard looks green.
  • Active scanning is off the table. The standard IT discovery method is banned here for good reason, so in practice most sites never discover anything.
  • Nobody owns the seam. IT says the plant floor belongs to operations. Operations says networks belong to IT. The historian and the engineering workstation live exactly in that gap.
  • Serial and non-routable gear doesn't appear at all. Devices on Modbus RTU, PROFIBUS or HART sit behind a gateway. An IP-based sweep sees the gateway and nothing behind it.

That last point matters more than people expect. On plenty of sites a large share of endpoints have no IP address at all, which means an inventory built purely from network data is wrong before you start.

What Counts as an OT Device checklist with two columns: CONTROL LAYER lists PLCs and controllers, HMIs and operator panels, RTUs at remote sites, safety instrumented systems, and protection relays and drives; DATA LAYER lists SCADA and DCS servers, process historians, engineering workstations, industrial switches, and vendor remote access boxes.
The classes that show up on nearly every plant site.

Why you can't secure what you haven't enumerated

That isn't a slogan. It's a dependency chain, and every meaningful OT control sits downstream of the register.

  • Zones and conduits. IEC 62443-3-2 asks you to group assets into zones by risk and define the conduits between them. That's an inventory exercise before it's an architecture exercise.
  • Vulnerability management. A CISA ICS advisory names a vendor, a product family and a firmware range. If you don't know your client owns three of those, the advisory is noise.
  • Segmentation. Firewall rules written from an incomplete map produce one of two outcomes. Either you break production, or somebody writes a permissive rule to stop the breakage and the project quietly dies.
  • Incident response. During an event the first question is what else talks to the thing that's misbehaving. If assembling that answer takes six hours, the plant is down for six hours.
  • Questionnaires and insurance. Do you maintain an inventory of OT assets is a standard line item now. Answering yes without one is a decision your client regrets at claim time.

NIST SP 800-82 Rev. 3 and CIS Control 1 both put asset inventory first, for the same reason. It's the control every other control is priced against.

A discovery approach that won't take the line down

Five passes, run in this order. Treat the order as non-negotiable.

Pass four is what makes passes one through three honest.

1. Paper first

Before a single packet, collect the network diagrams, P and ID drawings, integrator handover binders, maintenance records, OEM service contracts and the purchasing history for capital equipment.

Purchase orders are badly underrated. Every machine on that floor was bought by somebody, and the PO usually names the control platform inside it.

2. Passive network capture

Get a span port or a passive tap at the core plant switch and at each cell switch you can reach. Capture long enough to cover a full production cycle, including a shift change and ideally a weekend, because devices that only speak during a batch won't show up in a short window.

Parsing that traffic gives you addresses, the protocols in use (Modbus TCP, EtherNet/IP, PROFINET, S7comm, DNP3, OPC UA) and a conversation map of who talks to whom. No packets go onto the process network. The only change you make is the SPAN configuration itself, which is why a TAP is the better option wherever one can be fitted.

3. Configuration and backup review

Pull the switch configurations, firewall rule sets, DHCP reservations and the controller project files from the engineering workstation.

Project files are the best source in the building. A PLC program typically enumerates every I/O module, drive and remote rack it addresses, including gear that never generates routable traffic.

4. Physical walkdown

Walk the floor with the maintenance lead and open the panels. Photograph the nameplates.

This is the only pass that finds the serial devices, the unmanaged five-port switch zip-tied inside an enclosure, and the cellular router an OEM left behind after a commissioning visit. Budget a full day per production area, and don't send a junior alone into a live plant.

5. Reconcile, then assign an owner

Merge the four sources into one record per device: make, model, firmware, addresses, physical location, zone, the process it supports and who to call when it fails.

Then get a named person to own the update process, tied into the site's management of change procedure. An inventory without an owner is stale within a quarter, and a stale one is worse than none, because people trust it.

Active scanning gets its own rule. If you have to scan, do it inside an agreed maintenance window, rate-limited, with the process owner present and an abort signal agreed beforehand. Some OT-aware platforms run safe active queries using the device's own protocol rather than generic port sweeps, which is gentler.

Gentler isn't free. And get the machine vendor's written sign-off before anything touches a controller still under warranty.

Five step flow for building the OT asset inventory: collect the paper trail, passive traffic capture, config and backup review, physical walkdown, then reconcile and assign.
Five passes, from paperwork to physical walkdown.

What the client gets at the end

The output of a discovery engagement isn't a screenshot of a scanner console. It's four artifacts the client can act on and an auditor can read.

  • The asset register. One row per device with the fields above. Exportable, because it'll be pasted into a customer questionnaire within a month.
  • The communication map. Who talks to whom, over which protocol, across which boundary. This is the artifact that becomes a segmentation design.
  • The exposure list. Every path from outside the plant to inside it. Vendor VPNs, cellular modems, dual-homed workstations, the wireless bridge somebody ran to the warehouse.
  • The gap register. Unsupported firmware, default credentials, flat zones and anything carrying an open CISA advisory, ranked by consequence to the process rather than by CVSS score alone.

That gap register feeds straight into an OT risk assessment, which is the natural second engagement. Package all of it under your own brand. If you'd rather not build the capability in-house, a pentest partner that works channel-only can run the fieldwork behind your logo, invisible to the client.

Frequently asked questions

What are OT devices?

OT devices are the hardware that monitors or controls a physical process. The main classes are PLCs, HMIs and operator panels, RTUs at remote sites, SCADA and DCS servers, process historians, safety instrumented systems, engineering workstations, and the industrial switches and gateways connecting them. If it changes or reports what happens on the plant floor, it counts.

Can we just run our normal network scanner across the OT network?

No. Legacy controllers have documented failure modes when they're hit with unexpected or high-rate traffic, and some will stop responding or fault outright. Past the technical risk, unauthorized scanning can void an OEM support agreement. Passive capture first. Active work only inside an agreed window, with operations watching.

How long does OT asset discovery take?

For a single mid-size manufacturing site, plan on two to four weeks end to end. The passive capture runs for a week or two, the walkdown is a day or two per area, and reconciliation takes about as long as the fieldwork. Multi-site clients should be phased one site at a time.

Who at the client should we be talking to?

The maintenance or controls lead, not the IT manager. The IT manager will hand you a spreadsheet. The controls lead knows which panel has the modem in it. Get the plant manager to sponsor the work so you get floor access, and keep the safety team informed if anything you're planning goes near the SIS.

How often does the inventory need refreshing?

Continuously in principle, with a formal reconciliation annually and an immediate update after any line change or new commissioning. Tie the update trigger into the site's management of change process and the register largely maintains itself. Bolt it on as a separate task and it won't survive the year.

Lead with the walkdown

Every OT security proposal you write rests on knowing what's out there, and almost none of your clients do. Don't hold it against them. The gear was bought as machinery and installed by integrators, and keeping a list of it was never anybody's job.

Which makes discovery the easiest first sale in this category. It's fixed scope, it's low risk to the process, and it produces the findings that justify everything you'd want to sell next.

Start with the walkdown. If you want the fieldwork and the reporting delivered under your brand, get a pentest quote and we'll size the first plant with you.

Author

Sunil Kande

Pentest Expert

Sunil is a pentester focused on web and mobile security, specializing in finding deep vulnerabilities beyond surface-level testing. His approach combines manual analysis, reverse engineering, and creative problem-solving to uncover impactful security issues.

Join our MSP Partner Program

Want reseller pricing, sample reports, and partner resources?
Book a call with our team to get access.