Scanning a plant for the SBOM: PROFINET, SNMP and IP scans together yield the device list with order number and firmware

Which three sources feed an SBOM in plant engineering is covered in the article on creating the SBOM: parts list, engineering project and network scan. The scan is the only one of the three that measures the firmware version actually running, and at the same time the one with the most gaps. This article deals with the scan alone: which method reaches which devices, why one method is never enough, and how the approach depends on the plant's control system world.

Which identification data each protocol exposes and where its gaps are is covered per protocol in a separate article: PROFINET, EtherNet/IP, EtherCAT, Modbus TCP, OPC UA, SNMP and IO-Link. What the manufacturers themselves provide in advisories and SBOMs is compared in SBOM by manufacturer.

No common tool delivers order number and firmware for every device in a plant

A plant made of conveyor technology, robotics, cameras and network equipment contains devices that report on themselves through five or six different protocols. Every scan tool handles part of them. In practice, six gaps appear:

• PROFINET scans capture only PROFINET devices. Access points, standard switches, industrial PCs and cameras are missing, although they carry firmware and regularly appear in advisories.
• Firewall and gateway solutions have gaps in firmware and device name. They see traffic, not identity. For many devices the firmware column stays empty.
• EtherCAT participants are reachable only via the master. Beckhoff terminals have no IP address; they become visible only after enabling access on the industrial PC.
• Some devices expose no identification. Individual drives report neither name nor order number, whichever way they are asked.
• The parts list lacks the firmware, the scan often lacks the order number. Both sources are incomplete on their own and have to be mapped onto each other.
• Scanning happens on site, evaluation centrally. Whoever scans each plant section separately merges the results of several teams by hand at the end.

The depth of the list is not the difficulty here. For machines and plants, the flat device level is enough, every device with manufacturer, order number and firmware version, without the software components beneath; the reasoning is in the article on creating the SBOM. The difficulty is the breadth: all devices, across all protocols, across all plant sections.

In a pure Siemens and PROFINET world, PRONETA plus an SNMP and IP query is enough

Many mid-sized plant builders and a large part of intralogistics work with Siemens throughout: S7 controllers, ET 200, SINAMICS drives, SCALANCE switches, PROFINET as the fieldbus. For these plants the approach is manageable and needs two methods.

PRONETA for the PROFINET devices. With the I&M0 data, the PROFINET standard prescribes what every device reveals about itself: manufacturer, order number, hardware and firmware version, serial number. PRONETA queries this data via PROFINET DCP, without a controller and independent of the IP configuration, and exports the list. For PROFINET participants this is the most reliable source there is. It has two limitations: DCP works on layer 2, so the scan reaches only the segment the computer is attached to and has to be repeated per VLAN. And everything that does not speak PROFINET stays invisible.

SNMP and IP query for the rest. Access points, switches, routers, industrial PCs and cameras expose their identification by other routes. The switch and router tables (ARP, Bridge-MIB) first deliver every device on the Ethernet with MAC address, IP, port and VLAN, which is to say completeness. An SNMP query against the addresses found delivers device name, hardware and firmware version from the system group and the ENTITY-MIB, often the order number as well. What does not answer on SNMP usually has a web interface with a type plate; industrial PCs additionally offer a Windows inventory via a read-only account.

An IP scan here means reading tables and querying the addresses found in known protocols, with a fixed port list and without write access. Port probing in the style of an IT vulnerability scanner is something else and does not belong in a plant network; the distinction is drawn in the article on SBOM tools.

The two lists are merged via the MAC address, which appears in both methods. The result is an Ethernet list in which the PROFINET devices carry I&M0 data and the network and IT devices carry SNMP data. For a plant with one control system world and a handful of VLANs, that is feasible in one acceptance day, with tools that are on the engineering notebook anyway.

Where control system worlds are dictated, a scan in three stages leads to the complete list

In automotive, energy, oil and gas, chemicals and pharma, the end customer frequently dictates the control and network technology, differently from plant to plant. The plant builder then builds Siemens for one customer, Rockwell for the next, and in practice often has several worlds in one plant: an S7 for the conveyor line, a Beckhoff IPC for the robot cell, B&R in the purchased module, IO-Link at the sensors. Here PRONETA plus SNMP is no longer enough, because each world exposes its identification by a different route. The approach becomes multi-stage.

The order of the stages follows the reliability of the data. Collection starts with PROFINET because the standard prescribes the identification data and every certified device delivers it. With EtherNet/IP, Modbus or OPC UA, the manufacturer decides what a device exposes; the yield is high but not guaranteed. The third stage needs access to be enabled once on the respective master, for instance an ADS route on the Beckhoff IPC, and therefore coordination with the controls engineer.

Which route applies to which control system world is shown in the following assignment. It serves as a template for recording, per plant type, which stages are needed.

Until a route in the scan is available, the data comes from the engineering project. The plant SBOM includes every device with firmware or a digital interface; purely analogue sensors stay out.

The scan runs from the maintenance PC across all VLANs, with no additional hardware in the plant

The sixth gap from the list above, scanning on site and merging by hand, is resolved by where the scan runs. PROFINET scans have to run per segment, and firewall or gateway solutions bring their own hardware into every plant. The maintenance PC in the central network cabinet, by contrast, reaches all plant sections through the router: VLAN 11 with PLC, ET 200, drives and HMI, VLAN 12 with the Beckhoff IPC and the scanners, VLAN 13 with IO-Link master, camera and access point, up to 150 plant sections in large plants. Everything reachable via IP is captured in one run; EtherCAT terminals and IO-Link sensors are added via their master.

For the run to be accepted in the plant network, it needs four things:

1. A profile per plant type, agreed once with the network department: which protocols, which port list, which read-only accounts.
2. A dry run that lists every request the scan would send, without sending anything.
3. A read-only run with a fixed port list that finishes in minutes.
4. A plant SBOM as CycloneDX with a coverage report: every unidentified device listed individually, with port, VLAN and manufacturer from the MAC assignment.

The coverage report is the part usually missing from scan results. A list of 180 identified devices says nothing about whether the plant has 180 or 230 devices. Only the open items with switch port and VLAN make the comparison against the EPLAN parts list and the engineering project possible. Results from other scanners can be placed alongside, just like the engineering data itself.

The timing stays the same as for the SBOM as a whole: FAT or commissioning, while the plant is still within the builder's own reach, and afterwards at every own service call or retrofit. Between these events the plant is in the operator's hands; the scan from acceptance day remains the last state measured by the builder.

Questions from practice

Is PRONETA enough to scan a plant for the SBOM?

For the PROFINET devices yes, for the plant no. Via I&M0, PRONETA delivers the best data a scan can get for PROFINET participants, but sees neither access points nor switches, industrial PCs or cameras, and has to run per segment because of DCP. In a pure Siemens world, an SNMP and IP query from the maintenance PC adds the rest; merging is done via the MAC address.

How do EtherCAT terminals and IO-Link sensors get into the list?

Only via the master. EtherCAT participants have no IP address; the scan reads their identification and firmware through the Beckhoff IPC, after an ADS route has been enabled once. IO-Link sensors are delivered by the IO-Link master via its diagnostic or REST interface, B&R controllers expose their participants via the system diagnostics. Whatever is not reachable this way comes from the engineering project.

What happens with devices that do not expose any identification?

They appear as open items in the coverage report, with MAC address, manufacturer from the MAC assignment, switch port and VLAN. That way they can be completed from the engineering project or the EPLAN parts list. Without the open items, the completeness of the list cannot be judged.

Whether an active scan in a plant network is risky, and why Claroty, Nozomi and the other OT monitoring platforms are the wrong tool for the acceptance of a plant about to ship, is answered in the article on SBOM tools. In short: queries in the devices' own protocols, read-only and with a fixed port list, do the same thing an engineering station on the network does; what is risky is port probing in the style of an IT vulnerability scanner.

Development partners test the collection on a plant of their own

We are implementing the methods from this article in Werkspilot Scan, a standalone module of Werkspilot that combines the scan methods from the maintenance PC in one run and outputs a plant SBOM as CycloneDX. Siemens and PROFINET are covered from stage 1; further control system worlds follow in stages 2 and 3. We are testing the module with a few plant builders on their own plants before it becomes generally available.

• Duration: four months, three partners.
• Testing: Werkspilot Scan runs on an internal test or reference plant of the partner. We or the partner scan it from the maintenance PC, the evaluation is done jointly, and the collection is extended stage by stage to the partner's controllers, for instance Beckhoff or B&R.
• Partner's contribution: an internal test plant for the duration, a fixed contact from network engineering and a weekly 30-minute review.
• Result for the partner: one plant of their choice as a plant SBOM, every reachable device with manufacturer, order number and firmware version, open items listed individually, for comparison with the EPLAN parts list for example. Afterwards the scan module permanently at partner conditions.

Request a place in the development partnership →

Werkspilot continuously checks the device list of delivered plants against the advisories and CSAF feeds of the component manufacturers. Werkspilot Scan is a standalone module for this and is being tested with development partners. This article reflects the technical state at the time of publication.