Werkspilot
    ← Insights

    IO-Link SBOM: what the master provides about every sensor and what it does not

    In brief · As of October 2026

    IO-Link devices are connected point-to-point to a master and have no network address; the master reads their identity. Mandatory according to specification V1.1.3 are VendorID and DeviceID (Direct Parameter Page) as well as VendorName (index 0x10) and ProductName (0x12). ProductID (order number), SerialNumber, HardwareRevision and FirmwareRevision (0x13–0x17) are optional – the large sensor manufacturers fill them, but it is not guaranteed. To the outside, the master hands out the data through its fieldbus submodule (PROFINET IOL_CALL), through OPC UA according to OPC 30120 or through the REST interface "JSON Integration for IO-Link". For the plant SBOM, IO-Link is the third stage: first the master in the network, then the sensors through it.

    Four mandatory fields, four optional ones

    ParameterAccessMandatoryMeaning for the device list
    VendorID (Direct Parameter Page 0x07–0x08)Master at port start-upyesManufacturer as 16-bit number, identical to the PI vendor ID
    DeviceID (0x09–0x0B)Master at port start-upyesDevice type, manufacturer-internal; resolved through the IODD (IODDfinder)
    VendorName (ISDU 0x10), ProductName (0x12)ISDUyesManufacturer and product name as text
    ProductID (0x13)ISDUnoOrder number or type key – the matching key, if filled
    SerialNumber (0x15), HardwareRevision (0x16), FirmwareRevision (0x17)ISDUnoSerial number and revisions – common at ifm, SICK, Balluff, Pepperl+Fuchs, Turck and Festo, not guaranteed

    IO-Link V1.0 devices (RevisionID 0x10) often carry no ISDUs; then VendorID and DeviceID remain. The assignment to the product then runs through the IODD, publicly searchable in the IODDfinder.

    Three paths from the master into the device list

    • Through the master's fieldbus: PROFINET masters show every port as a submodule; VendorID and DeviceID are in the port parameters, the ISDUs are read by an IOL_CALL from the controller or by an engineering tool (S7-PCT, TIA Portal IO-Link tool). EtherNet/IP masters offer manufacturer-specific CIP objects.
    • Through OPC UA according to OPC 30120: the IOLinkDeviceType carries VendorID, DeviceID, VendorName, ProductName and – mandatory there – SerialNumber; HardwareRevision and SoftwareRevision optional. Implemented on masters from ifm, Balluff, Turck and others.
    • Through JSON/REST: the community specification "JSON Integration for IO-Link" (10.222, V2 since 2025 with OpenAPI) defines Gateway → Master → Ports → Devices with identification objects under /iolink/v1. Balluff and Pepperl+Fuchs implement it, ifm uses its own REST API (IoT-Core).

    All three paths are read-only and permissible during operation. Write parameter accesses, port mode changes or data storage uploads do not belong in an inventory tool.

    What IO-Link does not provide

    • Guaranteed serial number and firmware: optional according to the specification; empty fields are permissible.
    • Direct visibility: without the master there is no path to the sensor – and the master first has to be found via PROFINET DCP, EtherNet/IP or an IP scan.
    • An unambiguous product identifier without IODD: DeviceID is unique only together with VendorID; ProductID is free text.
    • The master itself: its firmware is a CRA product of its own – in 2026 there were advisories for IO-Link masters from Phoenix Contact (IOL MA8); this is described in the article on Phoenix Contact and the plant SBOM.

    What this means for the plant SBOM

    • First capture the IO-Link masters in the network (I&M0, Identity Object, SNMP), then read the port list per master with VendorID, DeviceID, ProductName and – as far as filled – ProductID, serial number and firmware.
    • Resolve DeviceID into a product type through the IODD; the vendor ID is the same number as in PROFINET and public through the PI table.
    • List sensors without serial number as items with master and port – that is enough for the exposure assessment per plant.
    • At acceptance (FAT), define which path (fieldbus, OPC UA, REST) is used per master type; the stage logic for this is in the article on the network scan.

    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

    According to specification V1.1.3, VendorID and DeviceID (Direct Parameter Page) as well as VendorName (ISDU 0x10) and ProductName (0x12) are mandatory. ProductID (order number), SerialNumber, HardwareRevision and FirmwareRevision (0x13–0x17) are optional; the large sensor manufacturers fill them as a rule, but it is not guaranteed.

    Only through the IO-Link master. It hands out the device data through its fieldbus submodule (with PROFINET via IOL_CALL or engineering tool), through OPC UA according to OPC 30120 or through the REST interface "JSON Integration for IO-Link". First the master itself has to be found in the network, for example via PROFINET DCP or EtherNet/IP ListIdentity.

    The VendorID is the same number as the PI vendor ID and can be resolved through the public PI vendor table. The DeviceID is manufacturer-internal and unique only together with the VendorID; the assignment to the product is provided by the IODD, publicly searchable in the IODDfinder of the IO-Link Community with more than 7,500 device descriptions.