← Insights

    PROFINET SBOM: what I&M0 reveals about every device and why DCP is not enough

    In brief · As of October 2026

    For the plant SBOM, PROFINET provides the most complete data: every certified IO device must carry the record I&M0 – vendor ID, OrderID (the MLFB at Siemens), serial number, hardware and software revision. The query runs in two steps: DCP Identify on layer 2 finds all participants in the segment but names only type and station name; only reading record 0xAFF0 via PNIO-CM (UDP 34964, "Read Implicit", without a connection to the controller) provides the fields that advisory matching needs. What PROFINET does not reach: everything that does not speak PROFINET, and the software components below the firmware version.

    I&M0 is mandatory for every PROFINET device and contains exactly the fields of the device list

    The "Identification & Maintenance" records are described in PI guideline 3.502 and are part of certification: without I&M0, no device passes the conformance test. The record sits at index 0xAFF0 and is written by the manufacturer, not by the user.

    Field (I&M0)SizeMeaning for the device list
    IM_Vendor_ID2 bytesManufacturer as PI number (42 = Siemens, 176 = Phoenix Contact, 288 = Beckhoff, 333 = Festo); resolved through the public PI vendor table
    IM_Order_ID20 charactersOrder number as the advisory names it – the MLFB at Siemens, the article number at Phoenix
    IM_Serial_Number16 charactersSerial number of the device
    IM_Hardware_Revision2 bytesHardware revision
    IM_Software_Revision4 bytesFirmware version as prefix (V/R/P/U/T) plus x.y.z – the field against which the version range of the advisory is checked
    IM_SupportedBitmaskWhich further records (I&M1–I&M5) the device carries

    I&M1 to I&M3 (function, location, date, description) are writable by the operator and help with assignment to the plant section. I&M5 describes an embedded communication module – such as the Anybus chip in a third-party device – with its own OrderID and firmware.

    DCP finds the participants, reading I&M0 identifies them

    Step 1, DCP Identify-All: an Ethernet frame to the multicast address 01:0E:CF:00:00:00 (EtherType 0x8892); every PROFINET device in the same layer-2 segment answers with station name, device type as text ("S7-1500"), vendor and device ID, role and IP configuration. No serial number, no order number, no firmware version. The scan needs raw-socket access and a network card in the segment – one pass per VLAN.

    Step 2, read the record: through the PNIO-CM service on UDP 34964, an engineering tool reads record 0xAFF0 as "Read Implicit" – without an application relationship, so without touching the running connection between controller and device. This is exactly how PRONETA and the online functions in the TIA Portal work. Alternatively, the controller itself reads it via a function block (RDREC at Siemens, FB_PN_IM0_READ at Beckhoff).

    A side effect that makes the work easier: on many devices the endpoint mapper response on UDP 34964 contains a text with model and order number ("S7-1500 6ES7 672-5DC01-0YA0") – a cheap fingerprint on layer 3 before any record is read at all.

    What PROFINET does not provide

    • Everything outside PROFINET: switches without a PROFINET profile, access points, industrial PCs, cameras and routers answer neither DCP nor PNIO-CM. They need SNMP or an inventory through their web interface.
    • Modular devices: an ET 200 head has one I&M0, every module with its own firmware has another per slot and subslot. A scan that reads only slot 0 misses interface and function modules.
    • Devices behind a proxy: an IE/PB link answers with its own I&M0; the PROFIBUS participants behind it are reachable only via DPV1 (index 255, subindex 65000) through the master.
    • The software below the firmware: I&M0 names the firmware version, not the libraries inside it. That is sufficient for the device level, because manufacturer advisories name products and firmware ranges, not libraries.
    • Write access: DCP Set (name, IP, factory reset) is unauthenticated. An inventory tool may use Identify and read services only.

    What this means for the plant SBOM

    • At acceptance (FAT), run DCP Identify per segment, then read I&M0 per participant and per slot; the result is a list with manufacturer, OrderID, serial number and firmware – the columns through which Siemens, Phoenix Contact, Festo and Pilz assign their advisories.
    • Resolve the vendor ID into a manufacturer name through the PI table and take the OrderID over unchanged; it is the matching key, not the product name.
    • Add non-PROFINET devices through SNMP, ARP tables and web interfaces; which method reaches which devices is described in the article on the network scan per controller world.
    • Use I&M1 (function, location) to assign devices to the plant section – this saves the manual work of merging with the parts list.

    All 13 manufacturers compared: SBOM by manufacturer →

    Trial Werkspilot Scan on your own plant.

    We are trialling the capture with a few plant builders on their test or reference plants, for four months, extended stage by stage around their controllers. The partner gets one plant of their choice as a plant SBOM: every reachable device with manufacturer, order number and firmware version, open items listed individually.

    Ask about the development partnership →

    Werkspilot Scan reads these fields from the maintenance PC, read-only and with a fixed request list, and keeps them per plant. This article describes the state of the specifications at the time of publication.

    Frequently asked questions

    Vendor ID (PI vendor ID), OrderID (order number, the MLFB at Siemens), serial number, hardware revision and software revision (firmware as prefix plus x.y.z), plus a bitmask of the further supported I&M records. I&M0 sits at index 0xAFF0, is written by the manufacturer and is mandatory for every certified PROFINET IO device.

    No. DCP Identify finds all participants in the layer-2 segment and names station name, device type as text, vendor and device ID and the IP configuration – but neither serial number nor order number nor firmware version. These fields come only from reading record 0xAFF0 via PNIO-CM on UDP 34964, which is possible without a connection to the controller.

    Not if it uses only Identify and read services. Every controller sends DCP Identify itself at start-up, and reading records as "Read Implicit" does not touch the running connection. What is risky are DCP Set commands (name, IP, factory reset), which are unauthenticated, and port scans in the style of an IT vulnerability scanner, which can bring older stacks to a halt.