Protocol gateways

A protocol gateway is a device that bridges an IP network to a separate, sometimes non-IP fieldbus, backplane, or serial bus. Examples include a Modbus/TCP-to-Modbus-RTU gateway, an EtherNet/IP CIP rack with backplane modules, a BACnet/IP router fronting an MS/TP segment, and 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 sends protocol-native, read-only enumeration queries to the gateway and reports each downstream device as its own sub-asset in the inventory. Sub-assets link back to the gateway, so you can see, search, and report on the full field-level topology with no credentials, agents, or active control commands.

How it works

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).
The probe sends protocol-specific identification requests to 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.
runZero reports each enumerated device as a sub-asset with a stable foreign ID of the form <protocol>/<port>/<address>, plus whatever identity the protocol exposes: vendor, model, firmware, serial, name, location.
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 draw edges from the gateway to each sub-asset on the Network Map.
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. runZero matches and merges them with assets discovered through other sources (for example, a PLC enumerated through CIP and also seen directly via SNMP), so the same physical device appears once.

Supported protocols

The protocols below produce sub-assets when enumeration is enabled. The gateway_kind column gives the value to use with the gateway_kind: and child_kind: search keywords in both the asset inventory and the Network Map.

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.

When probed, other industrial protocols return downstream-device summaries as gateway attributes, but runZero currently does not promote those entries to standalone sub-assets. These include 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. 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’s 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 topology keywords below come straight from the edges table runZero builds during enumeration, so the same queries work in Inventory > Assets, in any report that has an asset search box, and in the Network Map search bar.

Goal	Query
All protocol gateways	`is:gateway`
Layer-2 switches	`is:switch`
Modbus/TCP gateways	`gateway_kind:modbus`
EtherNet/IP CIP gateways	`gateway_kind:cip`
BACnet/IP routers	`gateway_kind:bacnet`
Siemens S7Comm racks	`gateway_kind:s7comm`
All sub-assets discovered behind any protocol gateway	`is:child`
Sub-assets behind a specific gateway protocol	`child_kind:modbus` (or `bacnet`, `cip`, `s7comm`, `dnp3`, `profinet`, `ethercat`, `omronfins`, `melsecq`, `hartip`, `c37118`, `knxnet`)
Gateways fronting more than 10 downstream devices	`is:gateway AND downlink_count:>10`
Public-facing protocol gateways	`is:gateway AND has_public:t`
OT assets within 2 hops of a public-facing asset	`category:OT AND hops_from_public:<=2`
Devices in the OT category	`category:OT`

The topology keywords accept the OT protocol names from the gateway_kind column in the Supported protocols table. They aren’t limited to OT: is:switch and the existing has:uplink / has:downlink / has:switch keywords cover layer-2 switch relationships.

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

Sub-assets are regular assets in the inventory. They appear in Inventory > Assets, in saved queries, and in CSV exports.
A sub-asset’s detail page links back to its parent gateway, and the gateway’s page lists all sub-assets discovered through it.
On the 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.
The Network Map always promotes protocol gateways into its 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, runZero applies an additional +200 boost.
runZero places sub-assets in the OT Category and assigns them 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. The standard scan rate and per-protocol pacing throttle the probes.

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.