Protocol gateways

A protocol gateway is a device that bridges an IP network to a separate, sometimes non-IP fieldbus, backplane, or serial bus — for example, a Modbus/TCP-to-Modbus-RTU gateway, an EtherNet/IP CIP rack with backplane modules, a BACnet/IP router fronting an MS/TP segment, or a HART-IP multiplexer in front of a loop of HART field instruments. From the IP side, only the gateway is reachable. The PLCs, RTUs, IEDs, meters, sensors, and CNC modules behind it are invisible to a typical port scanner.

runZero unmasks those downstream devices. When a scan identifies a supported gateway, the scanner issues protocol-native, read-only enumeration queries to the gateway and reports each downstream device as its own sub-asset in the inventory. Sub-assets are linked back to the gateway so you can see, search, and report on the full field-level topology — without credentials, agents, or active control commands.

How it works

Identify the gateway. The standard service probe identifies a supported industrial protocol on the gateway’s IP address and port (for example, Modbus/TCP on TCP/502, CIP on TCP/44818, BACnet/IP on UDP/47808, HART-IP on TCP/5094).
Enumerate downstream devices. The probe issues protocol-specific identification requests against each address space the gateway exposes — Modbus unit IDs, CIP backplane slots, BACnet device instances and routed networks, KNX individual addresses, HART sub-device indices, S7 racks/slots, and so on. All requests are read-only.
Emit a sub-asset per downstream device. Each enumerated device is reported with a stable foreign ID of the form <protocol>/<port>/<address>, plus whatever identity the protocol exposes — vendor, model, firmware, serial, name, location.
Link sub-assets to the gateway. Each sub-asset carries parent.id, parent.addresses, and protocol-specific parent attributes that point back to the gateway asset. The console uses these to show downstream devices on the gateway’s detail page and to render gateway → sub-asset edges on the Network Map.
Score the gateway as a choke point. Because the gateway is the only path to its sub-assets, the Network Map treats it as a protocol-gateway pivot and ranks it at the top of the choke-point panel.

Sub-assets are full assets in the inventory: they appear in search, in queries, in exports, and in dashboards. They are matched and merged with assets discovered through other sources (for example, a PLC enumerated through CIP and also seen directly via SNMP), so the same physical device is not duplicated.

Supported protocols

The protocols below produce sub-assets when enumeration is enabled. The gateway_kind column is the value used by the Network Map gateway_kind: filter (map view only — see Finding gateways and sub-assets for inventory queries).

Protocol	Default ports	`gateway_kind`	What runZero enumerates
BACnet/IP	UDP 47808 (+ range)	`bacnet`	Device instances and routed networks reachable through the BACnet router, including BBMD / FDT entries.
EtherNet/IP CIP	TCP/UDP 44818	`cip`	Modules in the controller backplane (CPU, scanner, communications, I/O, drives) via List Identity.
Modbus/TCP	TCP 502	`modbus`	Connected unit IDs reachable through the gateway, with vendor / product / firmware where exposed.
KNXnet/IP	UDP 3671	`knxnet`	KNX devices behind the IP interface, keyed by KNX individual address.
Siemens S7Comm	TCP 102	`s7comm`	Backplane rack/slot modules (CPU, CP, IM, signal modules) for S7-300/400/1200/1500.
DNP3	TCP 20000	`dnp3`	Outstation addresses behind a DNP3 master / data concentrator.
PROFINET	UDP 34962-34964	`profinet`	Slot/subslot module list reported by PROFINET I/O devices.
EtherCAT	UDP 34980	`ethercat`	Slaves discovered on the EtherCAT segment behind the master.
Omron FINS	UDP 9600	`omronfins`	CPU modules and connected units reachable through the FINS gateway.
Mitsubishi MELSEC-Q	TCP 5006-5007	`melsecq`	CPU modules on the MELSEC backplane, including CPU model and type code.
HART-IP	TCP 5094	`hartip`	HART field instruments behind the multiplexer (Cmd 84 walk of sub-device indices).
IEC 60870-5-104	TCP 2404	`iec104`	Outstations addressed through the IEC-104 master gateway.
IEC 61850 MMS	TCP 102	`mms`	Logical devices and IEDs reported through the substation MMS gateway.
Beckhoff ADS	TCP 48898	`ads`	ADS sub-devices behind the Beckhoff TwinCAT runtime.
IEEE C37.118 Synchrophasor	TCP 4712	`c37118`	PMUs reported by the Phasor Data Concentrator.

Other industrial protocols — including Emerson BSAP/IP, ANSI C12.22, Allen-Bradley CSPv4 / PCCC, Diagnostics over IP (DoIP), Fanuc FOCAS, SEMI HSMS / SECS-GEM, M-Bus over TCP, and OPC UA — return downstream-device summaries as gateway attributes when probed, but currently do not promote those entries to standalone sub-assets. See Supported protocols for the full list of probes and what each one returns.

Enabling enumeration

Sub-asset enumeration runs as part of the standard scan when the relevant protocol is enabled and the matching probe is selected in the scan configuration. Most OT probes are off by default to keep scans of IT-only networks lean — see the Scanning OT networks playbook for the recommended enable-list and probe options.

When you enable a gateway protocol, the scanner runs both the standard fingerprint probe and the downstream enumeration step. There is no separate “enumerate sub-assets” toggle; enabling the protocol turns on both.

Finding gateways and sub-assets

Use the asset inventory search to pivot between gateways and the devices behind them. The asset inventory does not have a dedicated gateway: keyword — that field is computed inside the Network Map report. From the inventory, find gateways by type: or by the protocol they speak, and find sub-assets by the source that produced them.

Goal	Query
All protocol gateways	`type:"Protocol Gateway"`
Modbus gateways	`type:"Protocol Gateway" AND protocol:modbus`
EtherNet/IP CIP gateways	`type:"Protocol Gateway" AND protocol:cip`
BACnet/IP routers	`type:"Protocol Gateway" AND protocol:bacnet`
All sub-assets discovered behind a gateway	`source:bacnet OR source:cip OR source:modbus OR source:knxnet OR source:s7comm OR source:dnp3 OR source:profinet OR source:ethercat OR source:omronfins OR source:melsecq OR source:hartip OR source:iec104 OR source:mms OR source:ads OR source:c37118`
Sub-assets behind a specific gateway protocol	`source:modbus` (or `source:bacnet`, `source:cip`, `source:s7comm`, …)
Devices in the OT category	`category:OT`

Inside the Network Map search box, the additional gateway: and gateway_kind: keywords are available to filter the graph (gateway:t AND NOT gateway_kind:switch, gateway_kind:cip, etc.). Those keywords only apply to the map view; they do not work in Inventory → Assets.

Each sub-asset’s detail page shows the parent gateway under Source data → Parent, and the gateway’s detail page lists every sub-asset enumerated through it.

Where sub-assets show up

Inventory — Sub-assets are regular assets. They appear in Inventory → Assets, in saved queries, and in CSV exports.
Asset details — A sub-asset’s page links back to its parent gateway. The gateway’s page lists all sub-assets discovered through it.
Network Map — Gateways render as protocol-gateway nodes with edges out to each sub-asset on their backplane. The Proto Gateways category in the Asset Index counts BACnet, EtherNet/IP, Modbus, KNXnet/IP, C37.118, and the other supported gateway kinds.
Choke points — Protocol gateways are always promoted into the Network Map’s Choke Points panel, with a +1000 Pivot Risk Score boost and a count of the assets they front. If the gateway is also EOL or carries known vulnerabilities, an additional +200 boost is applied.
Categories and functions — Sub-assets are placed in the OT Category and assigned OT Functions (typically Process Control, with Safety, Monitoring, Communications, or Human Interface added when the protocol exposes enough detail).

Safety

All gateway enumeration uses read-only protocol requests — identification reads, list-identity, who-is, sub-device indexing. The scanner never sends control or write commands, never issues operator overrides, and never attempts to authenticate. Probes are throttled by the standard scan rate and per-protocol pacing.

The runZero scan engine has been independently tested against a range of OT and industrial environments, including the U.S. Department of Energy’s National Renewable Energy Laboratory (NREL) CECA evaluation, which validated that active scanning is safe for operational technology. See the Scanning OT networks playbook for additional safety guidance, recommended pacing, and per-protocol options.