Werkspilot
    ← Insights

    EtherCAT SBOM: how terminals without an IP address get into the device list

    In brief · As of October 2026

    EtherCAT participants process frames on the fly and have neither an IP stack nor their own address in the network – a scan from the maintenance PC sees the master (usually an industrial PC), not the terminals. Their identity exists in three places: in the SII EEPROM (Vendor ID, Product Code, Revision, serial number from word 0x0008), in the CoE object 0x1018 and in the manufacturer's ESI file. Only the master can read it: TwinCAT on "Scan Boxes", via ADS after a route has been enabled, CODESYS via EtherCATStack, IgH or SOEM. For the plant SBOM this means: the terminal list comes from the project or through the master – and the larger attack surface is the master itself.

    The identity is stored in the EEPROM, in the object dictionary and in the ESI file

    The ETG requires a globally unique Vendor ID for every device; Product Code and Revision are mandatory because the master needs them to match against the ESI and ENI configuration.

    SourceFieldsMeaning for the device list
    SII EEPROM (ETG.2010), words 0x0008–0x000FVendor ID, Product Code, Revision, serial numberReadable from state INIT; basis of every terminal list
    CoE object 0x1018 (Identity)The same four values, plus at Beckhoff 0x1008 name, 0x1009 hardware and 0x100A software versionOnly on devices with mailbox/CoE – plain digital terminals have none
    ESI file (XML)Vendor, ProductCode, RevisionNo, Name, OrderIdxManufacturer description; links the Product Code to the order designation (EL1008)

    The public ETG vendor ID list resolves the number (0x2 Beckhoff, 0x24 Bosch Rexroth, 0x691 FANUC). The Product Code remains manufacturer-internal; the order designation is found only in the ESI file or in the name string.

    Only the master can read, and the master is a PC

    A second master could only be connected by breaking the ring. In the running plant, the path therefore remains through the existing master: TwinCAT reads the EEPROM identity on scan and shows name, revision and firmware; via an ADS route the IPC hands out the same data programmatically; CODESYS masters offer ReadEEpromData, open-source masters such as IgH or SOEM a slaveinfo. All of this is read-only and common during operation.

    The master is an industrial PC with Windows, TwinCAT/BSD or Linux and TwinCAT, CODESYS or ctrlX OS. That is where the vulnerabilities that manufacturers actually report are found – all 17 Beckhoff advisories concern software, not a single terminal. The EtherCAT identity covers the I/O level; the software inventory of the master is the more important part. More on this in the article on Beckhoff and the plant SBOM.

    What EtherCAT does not provide

    • A serial number per device: many terminals carry only a date code (year/week) or a zero in the field. For evidence, the type plate counts.
    • A separate firmware version: the Revision is a 32-bit value with a manufacturer-specific split into hardware and firmware; a readable software string (0x100A) exists only on devices with CoE.
    • An order number as a field: the Product Code is a number; the order designation comes from the ESI file or the name string.
    • Access from outside: without master, project or ADS route there is no path to the terminal list – and passive listening from outside the ring is not possible.

    What this means for the plant SBOM

    • Export the terminal list from the project at acceptance (FAT) (TwinCAT ENI/XML, CODESYS device tree) or read it from the master via ADS; take type, revision and firmware per terminal.
    • List the master as a product of its own with a software inventory: operating system, TwinCAT or CODESYS version, packages. That is the surface advisories hit.
    • Additionally capture EtherCAT gateways to PROFINET or EtherNet/IP (EL6631, EL6652) in the network; they carry their own identity there.
    • How the scan in mixed plants builds in the stage "devices behind the master" is described in the article on the network scan per controller world.

    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

    Because EtherCAT participants have no IP stack and no address of their own in the network; they process the master's frames on the fly. Only the master, usually an industrial PC, is visible from outside. The identity of the terminals (Vendor ID, Product Code, Revision, serial number) is stored in the SII EEPROM and in CoE object 0x1018 and can be read only through the master – via TwinCAT scan, ADS route, CODESYS EtherCATStack or open-source master.

    Four values: Vendor ID (assigned by the ETG, publicly resolvable), Product Code (manufacturer-internal), Revision (32 bit, split manufacturer-specifically into hardware and firmware) and serial number (often only a date code or zero). Devices with a CoE mailbox additionally carry name, hardware and software version as strings (0x1008–0x100A). The order designation such as EL1008 is found in the ESI file.

    No, EEPROM reads and SDO upload of 0x1018 are read-only standard operations that TwinCAT performs online all the time. What is risky are write accesses to the EEPROM and state changes of the participants, which can disturb the ring. An inventory tool therefore uses only the master's read services and sends no frames of its own on the EtherCAT segment.