EtherCAT Explained: On-the-Fly Processing, Distributed Clocks, Security

EtherCAT is a real-time industrial Ethernet protocol in which one controller, the MainDevice, sends a standard Ethernet frame that passes through every SubDevice in turn; each SubDevice reads the data addressed to it and inserts its own data in hardware while the frame is still moving, then the last device sends the frame back. It was introduced in April 2003, is maintained by the EtherCAT Technology Group, and is standardised in IEC 61158 and IEC 61784. The protocol itself carries no authentication or encryption, so securing it means isolating the segment, controlling the MainDevice and its gateways, locking down file and Ethernet tunnelling services, and watching the traffic passively.

This post sits next to our other one protocol per post explainers for operational technology: OPC UA, DNP3, Modbus and why CAN bus has no authentication. Here we stay on EtherCAT: the frame at byte level, distributed clocks, the security model, and how to capture and parse frames on an isolated lab rig.

Safety note before anything else. EtherCAT networks drive servo axes, presses, robots, packaging lines and test stands. Frames on that wire move physical machinery, and a stray frame, a second controller or a state change can stop a line or move an axis without warning. Everything hands on in this post belongs on an isolated test rig with its own MainDevice computer, a few lab SubDevices and no connection to any production segment. Never plug a lab computer, a capture tool or a second controller into a running machine without written approval from the people responsible for that machine and its safety case.

Key takeaways

• EtherCAT was introduced in April 2003 and the EtherCAT Technology Group (ETG) was founded in November 2003. The ETG says the protocol has stayed at "Version 1" since then. Design goals were cycle times of 100 µs or less and jitter of 1 µs or less.
• Frames use EtherType 0x88A4. One frame visits every SubDevice; each SubDevice Controller (ESC) reads and writes its slice in hardware as the frame passes, and the last device returns it over the other half of the full duplex link. Only the MainDevice may originate frames.
• A frame holds datagrams, each with a command, an address (position, station, broadcast or logical) and a Working Counter. Logical addressing uses a 4 GB process image that FMMUs in each ESC map to local memory.
• Mailbox protocols carry acyclic traffic: CoE, SoE, EoE, FoE and AoE per the ETG, plus vendor specific VoE in open source masters.
• Distributed clocks use the first DC capable SubDevice as reference, measure every propagation delay and distribute the reference time in hardware, with jitter "significantly less than 1μs" per the ETG.
• Frames carry no authentication or encryption. The ETG says the architecture already meets IEC 62443-3-3 Security Level 2; treat that as its claim and still apply zones, conduits, physical protection and monitoring.
• FoE writes files and firmware into devices; EoE tunnels IP into the segment. Disable what you do not use and log what you keep, for example with CISA's open source ICSNPP EtherCAT parser for Zeek.

What EtherCAT is, who created it and where it is standardised

Origin and governance

The ETG's technology introduction describes EtherCAT as "a real-time Industrial Ethernet technology originally developed by Beckhoff Automation." It was introduced in April 2003, and the EtherCAT Technology Group was founded in November 2003 to bring manufacturers and users together in technical working groups. Today the ETG runs the specification, the conformance program (the EtherCAT Conformance Test Tool, test centres and Plug Fests held in Europe, North America and Asia), the vendor ID registry and the developer support around it.

The EtherType registry tells the same origin story from the other side. The IEEE's public list of assigned EtherTypes shows 0x88A4 registered to Beckhoff Automation GmbH and Co KG in Verl, Germany, with the protocol name EtherCAT. That registration is why a switch, a capture tool or a Zeek sensor can recognise an EtherCAT frame without any IP header at all.

The ETG FAQ adds that EtherCAT is open for anyone to implement, but implementations must stay compatible, and it is candid that the technology is covered by patents, as most fieldbuses are. Device makers must pass the ETG conformance test before a device goes on the market.

Terminology: MainDevice and SubDevice

Current ETG material says "MainDevice" for the controller and "SubDevice" for every other node. Older documents and most open source tools, including the IgH EtherCAT Master, SOEM and the CISA Zeek parser, still use master and slave. They mean the same roles.

Standards

According to the ETG FAQ, EtherCAT is standardised in IEC 61158, IEC 61784, IEC 61800 and ISO 15745, and is also SEMI standard E54.20 for semiconductor equipment. The technology introduction adds that both EtherCAT and Safety over EtherCAT are IEC standards, covering not only the lower protocol layers but also the application layer and device profiles such as drives. In practice:

Two cautions. The ETG pages name the series without listing the exact part numbers and type numbers that hold EtherCAT, so check the current IEC catalogue entries when a contract or certificate needs the precise part and edition. And the ETG technology page itself writes the drive standard as both IEC 61491-7-204 (in a heading) and IEC 61800-7-204 (in the body text); the body text and the FAQ agree on IEC 61800, which is the drive systems series.

How processing on the fly works

One frame, every device

Most industrial Ethernet systems send a separate frame to each device, or each device sends its own frame. EtherCAT does the opposite. The MainDevice builds one frame (or a few) that holds outputs for every SubDevice, and sends it down the line. The ETG's description is precise: each SubDevice "reads the data addressed to it 'on the fly', and inserts its data in the frame as the frame is moving downstream." The frame is delayed only by hardware propagation time inside each ESC, not by any software stack.

When the frame reaches the last SubDevice in a segment or drop line, that device detects that its next port is open and sends the frame back towards the MainDevice using the return path of the full duplex link. Each 100BASE-TX link carries traffic in both directions at once, so the outbound frame and the returning frame do not compete. The ETG puts the effective data rate above 90 percent, and notes that because both directions are used, the theoretical figure is "more than 90 % of two times 100 Mbit/s".

Three consequences follow, and all of them matter for security later:

1. Only the MainDevice sends. The ETG states that the MainDevice is the only node in a segment allowed to actively send an EtherCAT frame; everyone else forwards. That is what removes collisions and unpredictable delays.
2. Every SubDevice sees every frame. Each ESC in the line handles each frame as it passes. A device reads and writes only the bytes addressed to it, but the frame physically travels through all of them.
3. The MainDevice needs no special hardware. The ETG says a MainDevice uses a standard Ethernet MAC without an extra communication processor, and in most cases moves the whole frame to and from memory by DMA, so the CPU does not copy process data. Mapping happens in the SubDevices, so the process image arrives back already sorted.

Inside the frame

EtherCAT puts its payload straight into an IEEE 802.3 Ethernet frame. There is no IP, UDP or TCP header for cyclic data, which is the main reason the protocol is fast and also the main reason ordinary IP firewalls do not see it.

The Wireshark project's EtherCAT page shows a decoded example that makes the layout concrete. After the Ethernet header comes a 2 byte EtherCAT frame header with an 11 bit length field, one reserved bit and a 4 bit type (type 1 means EtherCAT commands). Then come one or more datagrams. In the example, a single datagram uses command LRW (logical memory read write, command code 12) on logical address 0x00010000 with 100 bytes of data, and the frame header length is 0x0070, which is 112 bytes. Those 112 bytes are the 10 byte datagram header, the 100 data bytes and the 2 byte Working Counter. The example's Working Counter came back as 2, meaning two SubDevices processed it.

A datagram header carries:

Addressing modes

The ETG describes two broad families of addressing, and the command byte selects among them:

• Position (auto increment) addressing. The MainDevice reaches a device by its place in the line. Each SubDevice increments the address as the frame passes, and the device that sees zero is the target. This is used at startup to walk the network, compare it with the planned topology and assign addresses.
• Configured station addressing. After the scan, the MainDevice gives each node a fixed station address and talks to it by that address, which still works when the topology changes, for example with Hot Connect groups that can be attached and removed during operation.
• Broadcast. Every SubDevice processes the datagram, which is useful for startup and for latching clock timestamps on all devices at once.
• Logical addressing. This is the one used for cyclic process data. Each datagram addresses part of a single logical process image with 4 GB of address space. During startup each SubDevice is told which part of that space belongs to it. If several devices own pieces of the same area, one datagram serves all of them.

The ETG notes this lets a MainDevice refresh drives on a short cycle and sample slow I/O on a longer one, with no fixed process data structure.

FMMUs and sync managers

Two hardware blocks inside each ESC make logical addressing and safe data exchange possible:

• Fieldbus Memory Management Units (FMMUs) translate a range of the global logical address space into a range of the ESC's local memory, at bit granularity if needed. When an LRW datagram for logical address 0x00010000 passes, each FMMU checks whether that range overlaps the window it was programmed with and, if so, reads or writes the matching local bytes. The ETG notes that the number of FMMUs and the size of the internal dual ported RAM vary between ESC models.
• Sync managers guard the shared memory between the network side and the device's local application, so that the network never reads half updated inputs and the application never sees half written outputs. They run either in buffered mode for cyclic process data (the latest complete value wins) or in mailbox mode for acyclic messages (a handshake that hands a complete message from one side to the other).

Open source masters automate this. The IgH EtherCAT Master's feature list includes automatic calculation of process data mapping and FMMU and sync manager configuration, so an application registers the PDO entries it needs and the master programs the hardware to match.

The state machine and configuration files

Every SubDevice runs an EtherCAT state machine with states INIT, PRE-OPERATIONAL, SAFE-OPERATIONAL, OPERATIONAL and, on devices that support it, BOOTSTRAP. Mailbox communication is available from PRE-OP onward. In SAFE-OP inputs are exchanged but outputs stay in a safe state. Only in OP do outputs drive the process. BOOTSTRAP is the special state for firmware updates, where typically only FoE is available. This state machine is the most important lever you have on a running segment, and later sections come back to it.

Two files describe the network:

• ESI (EtherCAT SubDevice Information) is the XML description a vendor ships with each device. The ETG says it describes the device's network accessible properties, including process data and mapping options, supported mailbox protocols and supported synchronisation modes. A copy of the basic information also sits in the device's own EEPROM, the SubDevice Information Interface (SII), so a MainDevice can run a device even without its ESI file.
• ENI (EtherCAT Network Information) is the XML a configuration tool exports for one specific network: the cyclic process data layout plus the boot up commands for each SubDevice. A MainDevice loads it to bring the network up.

Both files are security relevant. An ENI file is effectively the configuration of the machine's network. It belongs under change control in the same way PLC programs do.

Topology, scale and diagnostics

The ETG lists line, tree, star and daisy chain topologies, with drop lines built from extra ports on I/O modules rather than switches. Its figures:

• up to 65,535 devices on one segment;
• up to 100 m between two nodes over 100BASE-TX copper, with fibre such as 100BASE-FX for longer runs;
• Hot Connect detection, where a removed neighbour's port is closed automatically, in under 15 μs;
• cable redundancy by running a cable from the last node back to a second MainDevice port to make a ring, with recovery in under 15 μs so that at most one cycle is disturbed.

For diagnosis, each ESC checks every passing frame's checksum and counts errors per port, which lets the MainDevice localise a faulty cable. If a datagram's Working Counter is lower than expected, the MainDevice withholds that data from the control application. That is a consistency check for honest hardware, not a message authentication code: a device that alters data can still increment the counter.

A worked timing example

Numbers make processing on the fly easier to reason about. Suppose a machine has 1,000 bytes of cyclic process data in one LRW datagram on a 100 Mbit/s segment. The bytes on the wire are:

At 100 Mbit/s each byte takes 80 ns, so serialising the frame takes 1,052 × 80 ns = 84.16 µs. Because the frame is processed on the fly, that serialisation time is paid roughly once, not once per device. On top of it you add the forwarding delay through each ESC (a hardware figure from the ESC vendor's datasheet) and cable propagation of around 5 ns per metre in copper, for the outbound and return paths. A small machine with 64 bytes of process data instead is padded up to the Ethernet minimum frame size, and its whole frame occupies only a few microseconds on the wire, which is how cycle times of 100 µs and below become practical.

The same arithmetic explains a security property. A single frame carries every output for the whole machine. Anything that can alter that frame in flight can alter every output, which is why the physical path and every device on it are part of the trusted base.

Mailbox protocols: CoE, SoE, EoE, FoE, AoE and VoE

Cyclic process data covers inputs and outputs. Everything else, such as parameters, diagnostics, files and tunnelled IP traffic, uses the acyclic mailbox, which the ETG describes as a reliable mailbox protocol with an auto recover function for erroneous messages. A SubDevice does not have to support every mailbox protocol; the ESI file tells the MainDevice which ones it implements.

The ETG lists the first five as the established communication profiles. VoE comes from the IgH master's feature list rather than the ETG's introduction.

Distributed clocks: sub-microsecond sync

Why EtherCAT needs its own clocks

Coordinated motion needs every axis to act at the same instant and every position sample to be taken at exactly equal intervals. The ETG makes the second point clearly: velocity is usually calculated from successive positions, so small timing errors in when a position was sampled turn into larger errors in the calculated velocity, especially at short cycle times. Tying actions to the arrival of a frame would make every device inherit the MainDevice's software jitter. Distributed clocks (DC) break that link: each device acts on its own local clock, and the clocks are kept aligned.

How it works

The ETG describes DC as "completely hardware-based." The sequence is:

1. Pick a reference clock. The first DC capable SubDevice in the line becomes the reference. Its time is the system time.
2. Measure propagation delays. At startup the MainDevice sends a broadcast that makes every ESC latch the local time at which the frame arrived on each of its ports, on the way out and on the way back. Reading those latched times lets the MainDevice compute the cable and forwarding delay between the reference and every other device. The ETG says this measurement is made at startup or, if desired, continuously during operation.
3. Set offsets. The MainDevice writes each device's offset and delay so that every local clock reads the same system time.
4. Compensate drift. In each cycle, a datagram reads the reference clock's time and writes it to all other DC devices as the frame passes. Each ESC compares the received time, corrected for its delay, with its own and adjusts its clock rate in hardware.
5. Fire on time. Outputs are applied and inputs latched on hardware sync signals generated from the local clock, not on frame arrival.

The ETG's figures: system jitter "significantly less than 1μs", demonstrated with a scope view of two devices 300 nodes and 120 m of cable apart. Because outputs fire on the local clock, the MainDevice only has to send the frame early enough, and the ETG notes that MainDevice jitter of several microseconds does not reduce DC accuracy. That is what lets a MainDevice run in software on a standard network card.

A small worked example shows why delay compensation matters. Suppose device 50 is 60 m of cable and 49 ESCs away from the reference. At about 5 ns per metre the cable alone adds roughly 300 ns, and each ESC adds its own forwarding time, so the raw arrival time of the reference value could be off by well over a microsecond. Without compensation, device 50 would act consistently late by that amount. Measuring the round trip on each port lets the MainDevice subtract it, which is how a line of hundreds of devices stays aligned within a fraction of a microsecond.

EtherCAT distributed clocks compared with PTP

IEEE 1588, the Precision Time Protocol, solves a similar problem for general networks. The IEEE describes IEEE 1588-2019 as a protocol for precise synchronisation of clocks in packet based networked systems that supports accuracy and precision "in the sub-microsecond range". The approaches differ in where the work happens:

The two often meet. A plant may run PTP across its network and need an EtherCAT segment's system time to follow it, or several EtherCAT segments to share one time base. The MainDevice is the bridge in that design, and its own clock discipline becomes part of what you protect. Our PTP explainer covers PTP's own attack surface and hardening.

The EtherCAT security model

What the protocol does not have

An EtherCAT frame has no field for a sender identity, a signature, a message authentication code, a sequence number designed against replay, or encryption. The Working Counter and Ethernet checksum protect against errors, not against a device that deliberately changes data. The MainDevice only rule is a rule that conforming hardware follows; it is not a cryptographic control. The Wireshark example frame is addressed to the broadcast MAC address, which is normal for EtherCAT because SubDevices are not addressed by MAC at all.

That was a deliberate trade for speed, cost and determinism, and it puts the security boundary around the segment, not inside it. Whatever can put frames on the wire, sit inline, replace a SubDevice or control the MainDevice's software can change process data, parameters, device states and firmware.

What the ETG says

The ETG's cybersecurity page argues the other side, and it is worth reading in full rather than paraphrasing loosely. Its points, in summary:

• the attack surface is small because frames are processed in hardware without a traditional software stack;
• there is no IP based communication on the segment, which protects against typical malware that spreads over IP;
• frames can only be generated by the MainDevice;
• manipulation of topology and devices can be detected, because the MainDevice compares the actual topology with the planned one;
• many attack types, such as denial of service, are ineffective, in the ETG's words.

The ETG states that EtherCAT systems already meet the requirements of Security Level 2 under IEC 62443-3-3 without any protocol modification, assessed and certified by an independent testing body, and that Security Level 3 needs only software extensions. It also says that, for exceptionally high requirements, EtherCAT is being extended with authenticated encryption in a backward compatible way, and it publishes an EtherCAT Security Profile as document ETG.1800.

Both views can be true at once. An enclosed segment with one tightly controlled MainDevice, topology checks at every start and no IP bridged in is a small target. The same protocol behind a MainDevice on the office network, with EoE bridged to a maintenance laptop and open spare ports, is a large one. Your architecture decides which you have.

Where attacks would actually land

Described at the level of mechanism and defence, not as instructions, the realistic paths to an EtherCAT segment are:

What IEC 62443 says about it

The ISA/IEC 62443 series is developed jointly by the ISA99 committee, which ISA set up in 2002, and IEC TC 65 Working Group 10; ISA says the ISA and IEC editions of each part are identical. Its central architectural idea for a protocol like EtherCAT is the pair zones and conduits:

• A zone is a group of assets that share the same security requirements. An EtherCAT segment, its MainDevice and the safety logic that rides on it are a natural zone, often called a cell.
• A conduit is the controlled path between zones. For EtherCAT, the conduit is almost never the EtherCAT wire itself; it is the MainDevice's second network interface, an AoE router, an OPC UA server on the controller, or an edge gateway.

IEC 62443-3-2 (security risk assessment for system design) is where a system is partitioned into zones and conduits with a target security level for each. IEC 62443-3-3 lists system security requirements and security levels, and IEC 62443-4-2 sets technical requirements for components. For an EtherCAT machine, that means: make the segment its own zone with no direct conduit to the enterprise network, route every path in and out through a conduit you can describe, control and log, set the zone's target level from what the machine can physically do, and hold the MainDevice and gateways to the component requirements, because they carry the security functions the segment lacks.

NIST SP 800-82 Revision 3, the US guide to operational technology security published in September 2023, gives the same pattern in a different vocabulary: segment OT from IT, put boundary protections between them, restrict and monitor remote access, and account for the safety and availability requirements that make OT different from IT. NIST released the initial public draft of Revision 4 in September 2026, with comments due by 30 November 2026, so check which revision your program follows.

FoE firmware upload and EoE tunnelling: exposure and lockdown

What FoE exposes

The ETG describes FoE as a simple TFTP like protocol for file access in a device and "a uniform firmware upload to devices across a network," deliberately lean so a boot loader can support it. That is exactly why it matters. Whoever can send FoE writes to a SubDevice in BOOTSTRAP state can replace its firmware, if the device accepts unsigned images. Whoever can send FoE reads may be able to pull files, configuration or logs out of a device.

Open source masters make FoE easy for legitimate maintenance: the IgH master's ethercat tool loads and stores files over FoE, and SOEM ships a firm_update sample. FoE security therefore comes from who can run such tools and what the device checks, not from the protocol.

Locking FoE down

• Keep the BOOTSTRAP state rare and visible. A device can only take firmware in BOOTSTRAP. Any state change to BOOTSTRAP outside a maintenance window deserves an alert.
• Prefer devices that verify firmware signatures. Whether a SubDevice checks a signature on an FoE image is a vendor feature, not a protocol feature. Ask each vendor, in writing, whether their boot loader verifies images, and record the answer in your asset inventory.
• Restrict who can drive the MainDevice. The IgH master creates its EtherCAT character devices with mode 0660 and group root by default, according to its INSTALL file, which keeps the ethercat tool to root. Its install notes show how to loosen that with a udev rule; on a production machine, do not.
• Do not expose mailbox gateways to the IP network without control. A mailbox gateway or AoE router can carry FoE from outside the segment. If you need it, restrict it by source, authenticate the IP side and log every use.
• Watch FoE traffic. The CISA Zeek parser writes ecat_foe_info.log with the operation code, packet number, error code, file name and transferred data for each FoE message. FoE activity should line up with change tickets.

What EoE exposes

EoE tunnels ordinary Ethernet frames through the EtherCAT segment. The ETG explains that the MainDevice acts as a layer 2 switch that forwards frames by MAC address to SubDevices with a switchport, and that EtherCAT devices can run HTTP and other Ethernet protocols and so behave like normal Ethernet nodes. The IgH master implements this as a virtual network interface for each EoE capable SubDevice, in either a switched or a routed design, "configurable with standard tools."

The benefit is convenient web based configuration of drives and gateways. The risk is that a segment with no IP becomes a segment with IP, and every embedded web server, FTP service or management interface on a SubDevice becomes reachable from wherever those virtual interfaces are bridged or routed.

Locking EoE down

• Leave EoE off unless a device needs it. If the ENI does not configure EoE for a device, the MainDevice does not set it up.
• Never bridge EoE interfaces to a plant or office network. If maintenance needs a device's web interface, reach it from the MainDevice host itself or through a tightly filtered, logged route.
• Firewall the MainDevice. On a Linux MainDevice, default deny forwarding between EoE interfaces and every other interface, and allow only the specific management flows you have approved. A minimal nftables pattern looks like this (adjust interface names to your host, and test on the lab rig first):

# Lab rig only: show which EoE interfaces the master created
ip -br link | grep -i eoe

# Default deny forwarding between interfaces on the MainDevice host
sudo nft add table inet ecatguard
sudo nft add chain inet ecatguard fwd '{ type filter hook forward priority 0; policy drop; }'
sudo nft add rule inet ecatguard fwd ct state established,related accept
# Allow only an approved engineering host to reach one device's web UI over EoE
sudo nft add rule inet ecatguard fwd iifname "eth1" ip saddr 10.20.30.40 oifname "eoe0s3" tcp dport 443 accept
sudo nft list ruleset

• Inventory EoE endpoints. Each EoE capable SubDevice with an IP stack is a networked device in your asset list, with firmware to track and patch.

Monitoring EtherCAT traffic passively

Where to tap

An EtherCAT segment has no switch in the middle, so there is usually no mirror port. The natural capture point is the link between the MainDevice and the first SubDevice, where a passive network TAP sees both the outbound frame and the returning frame. A capture on the MainDevice's own interface also works on a lab rig, and the IgH master offers a virtual read only network interface for debugging and traffic monitoring "using Wireshark, etc." without extra hardware. On a production machine, a passive TAP is the least intrusive option, and installing it still means a planned stop.

What CISA's Zeek parser does

ICSNPP (Industrial Control Systems Network Protocol Parsers) is a CISA project that publishes protocol parsers for the Zeek network monitor. ICSNPP-Ethercat is a Zeek plugin that parses EtherCAT and writes structured logs. Its README lists these log files:

The README says the parser produces eight log files but lists the seven above; the register log notes that EoE is among the mailbox types the parser routes, without a separate EoE log in the list. The plugin installs through the Zeek package manager, the repository is under a 3 clause BSD license with a 2023 copyright line, and the GitHub repository dates from April 2021.

What to alert on

Passive monitoring of EtherCAT is most useful as baseline and deviation detection, because a healthy machine's traffic is extremely regular:

• A new source MAC sending EtherCAT frames. Only the MainDevice should originate frames on a segment.
• FoE activity of any kind outside a maintenance window, and any state change towards BOOTSTRAP.
• CoE or SoE writes to parameters that should not change in production, such as drive limits, once you know the normal set.
• Changes in ecat_dev_info.log values for a given position, which can mean a replaced device.
• AoE traffic from network IDs you have not seen before.
• Working Counter mismatches and error counters rising, which are often cabling faults but are also the symptom of something inline that should not be there.

Feed those logs into whatever system your OT security team already uses for Zeek output. Keep the sensor passive: it should have no route back into the segment.

EtherCAT, PROFINET, EtherNet/IP and Modbus TCP compared

The comparison below is about design, not about which is better. Each protocol suits different machines, and all of them are used safely when the architecture around them is right.

EtherCAT is the only one of the four whose cyclic data never touches IP, which limits exposure to whatever reaches the segment physically or through the MainDevice. The others travel over or beside IP, which makes them easier both to integrate and to reach.

Step by step: an isolated EtherCAT lab with SOEM or IgH, a capture and the Zeek parser

Read this first. Do this only on a dedicated test rig: one Linux computer with a spare wired Ethernet port, one or more EtherCAT lab SubDevices (an evaluation kit or a simple digital I/O terminal on a bench power supply), and no connection between that port and any other network. Use outputs that drive nothing, or only LEDs. A MainDevice tool on a production segment would compete with the real controller and can move machinery.

Step 1: identify the lab interface and isolate it

# List interfaces and pick the one cabled ONLY to the lab SubDevice
ip -br link
# Confirm the driver and link state of that port (replace enp3s0 with yours)
sudo ethtool enp3s0 | grep -E "Speed|Link detected"
sudo ethtool -i enp3s0
# Make sure the lab port has no IP address and no default route through it
ip addr show dev enp3s0
ip route | grep enp3s0 || echo "no routes on enp3s0"

Check the cable path by eye as well: from the computer's port to the first SubDevice's input port, and nowhere else. If the port shows an IP address from a DHCP server, it is connected to something it should not be.

Step 2 (option A): build SOEM and read the lab SubDevices

SOEM is a C library for building EtherCAT MainDevices on Linux, Windows and embedded targets, with sample programs. Its latest release at the time of writing is v2.0.1, published on 15 October 2026, and the project builds with CMake presets that use the Ninja generator.

sudo apt-get install -y build-essential cmake ninja-build git
git clone https://github.com/OpenEtherCATsociety/SOEM.git
cd SOEM
git checkout v2.0.1
cmake --preset default
cmake --build --preset default
# Locate the built sample
find . -type f -name slaveinfo -perm -u+x

The slaveinfo sample prints its usage as slaveinfo ifname [options], with -sdo to print the CoE object dictionary and -map to print the process data mapping. Raw Ethernet access needs root or the CAP_NET_RAW capability:

# Lab rig only. Replace the path with what find printed above.
sudo ./bin/slaveinfo enp3s0 -map

Be aware that slaveinfo is not passive. To read mappings it initialises the segment, assigns addresses and moves SubDevices through their states, which is fine on a bench and exactly why it must never touch a live machine.

Step 2 (option B): build the IgH EtherCAT Master

The IgH EtherCAT Master is a GPLv2 Linux kernel module plus a userspace library and the ethercat command line tool. Its INSTALL file gives the short procedure:

git clone https://gitlab.com/etherlab.org/ethercat.git
cd ethercat
git checkout stable-1.6
./bootstrap
./configure --sysconfdir=/etc
make all modules
sudo make modules_install install
sudo depmod

Then edit /etc/ethercat.conf on a systemd based distribution to bind the master to the lab port's MAC address and choose the Ethernet driver module (the generic driver works with any card the kernel supports, and the project documents native drivers for specific chips). Start it and read the segment:

sudo systemctl start ethercat
sudo ethercat master          # master state, link, frame statistics
sudo ethercat slaves          # position, state and name of each SubDevice
sudo ethercat slaves -v       # vendor, product code, revision, ports, DC support
sudo ethercat pdos            # process data mapping

Reading is safe on a bench. The same tool can write registers, write SII EEPROM contents, change states and push files over FoE; leave those commands alone unless a lab exercise needs them, and never run them against a production segment.

Step 3: capture EtherCAT frames

# Capture only EtherCAT frames on the lab port for 30 seconds
sudo timeout 30 tcpdump -i enp3s0 -w ecat-lab.pcap ether proto 0x88a4
# Quick look with the Wireshark command line dissector
tshark -r ecat-lab.pcap -c 10 -V | grep -E "EtherCAT|Cmd|Working Cnt" | head -40

Wireshark ships an EtherCAT dissector, as the ETG also points out, and shows commands, addresses, data and Working Counters in plain text. Look for the startup broadcast reads, the position addressed writes that assign station addresses, mailbox traffic in PRE-OP and the regular LRW frames once the segment is cyclic.

Step 4: parse the capture with ICSNPP-Ethercat

# Install Zeek from your distribution or the Zeek project first, then:
zkg refresh
zkg install icsnpp-ethercat
zeek -N | grep -i ethercat          # expect ICSNPP::ETHERCAT

mkdir zeek-out && cd zeek-out
zeek -Cr ../ecat-lab.pcap icsnpp/ethercat
ls *.log
cat ecat_dev_info.log | zeek-cut ts slave_id dev_type fmmucnt smcount dpram
cat ecat_log_address.log | zeek-cut ts Command Log_Addr Length | head
cat ecat_foe_info.log 2>/dev/null | zeek-cut ts opCode filename || echo "no FoE traffic"

The repository also ships an example trace, and its README shows running the plugin against it with zeek -Cr icsnpp-ethercat/tests/traces/ethercat_example.pcap icsnpp/ethercat, which is a useful check before you have lab hardware.

Step 5: turn the logs into a baseline

Record what normal looks like: one source MAC, a fixed set of logical addresses and lengths, stable device information per position, no FoE or EoE. Then change one thing at a time on the bench, such as unplugging a SubDevice or restarting the master, and confirm the logs show it.

Common mistakes

• Treating the EtherCAT segment as safe because it has no IP. The MainDevice host has IP, the gateway has IP, and EoE can add IP inside the segment. Protect those paths.
• Bridging EoE into the plant network for convenience. It turns every SubDevice web server into a reachable host.
• Leaving FoE tools available to every user on the MainDevice. Keep the character devices and tools root only, and log their use.
• Assuming firmware updates are signed. Signature checking is a vendor boot loader feature. Ask and record.
• Running a MainDevice tool or scanner on a live machine. Even "read only" MainDevice tools initialise the segment and change states.
• Ignoring topology checks. The MainDevice can compare the actual topology and device identities with the planned ones at every start. Make a mismatch stop the machine and raise an alarm, not a warning nobody reads.
• Leaving spare ports open. The open end of a line and unused drop ports are physical entry points. Cap, lock or alarm them.
• No change control for ENI files. A changed ENI changes the machine's network behaviour at the next start.
• Planning to monitor from a mirror port. EtherCAT segments rarely have a switch. Plan a passive TAP at the MainDevice link.

FAQ

Is EtherCAT the same as Ethernet?

It uses standard IEEE 802.3 Ethernet frames and physical layers, with EtherType 0x88A4, but not standard Ethernet switching. SubDevices process frames in hardware as they pass instead of receiving and resending them, so you cannot drop an ordinary switch into the middle of a line and expect it to behave the same.

Who owns EtherCAT?

It was originally developed by Beckhoff Automation, which holds the EtherType registration, and since November 2003 it has been maintained as an open technology by the EtherCAT Technology Group, which runs the specification, conformance testing and vendor IDs.

How fast is EtherCAT?

The ETG's design goals were cycle times of 100 µs or less and synchronisation jitter of 1 µs or less. Real cycle times depend on how much process data the machine has; serialising 1,000 bytes at 100 Mbit/s takes about 84 µs.

Does EtherCAT have encryption or authentication?

Not in the frame. The ETG argues that its architecture meets IEC 62443-3-3 Security Level 2 without protocol changes and has announced backward compatible authenticated extensions for higher requirements. Today, most security comes from isolation, the MainDevice, conduits and monitoring.

Can EtherCAT go through a router or over the internet?

Cyclic EtherCAT stays on a segment. The Wireshark project notes that EtherCAT can also be carried in UDP, on port 0x88A4 (34980), for IP routed access, and the EtherCAT Automation Protocol links controllers across networks. Any routed path is a conduit and needs the controls that implies.

What is FoE used for?

File Access over EtherCAT moves files to and from SubDevices, most often firmware images during an update in BOOTSTRAP state. It is simple enough for boot loaders, which is also why access to it needs control.

How do distributed clocks differ from PTP?

Distributed clocks run inside one EtherCAT segment, in ESC hardware, using the first DC capable device as the reference and in frame datagrams. PTP (IEEE 1588) runs across general networks with dedicated messages, a grandmaster and switch support. Both reach the sub-microsecond range.

How can I monitor EtherCAT without disturbing the machine?

Put a passive TAP on the link between the MainDevice and the first SubDevice, capture EtherType 0x88A4, and parse it with a protocol aware tool such as CISA's ICSNPP-Ethercat plugin for Zeek. Do not run active scanners or MainDevice tools on a live segment.

Is EtherCAT safe to use for safety functions?

Safety over EtherCAT (FSoE) carries safety data in "safety containers" inside normal process data and treats EtherCAT as a black channel. The ETG says FSoE was developed according to IEC 61508, is standardised in IEC 61784-3 and suits applications up to SIL 3. Functional safety is not the same as security, and both need their own assessment.

Where Safeguard fits

Safeguard does not monitor EtherCAT traffic, configure MainDevices, manage SubDevice firmware, scan controller firmware or inventory devices on a machine network. Nothing in the isolation, FoE, EoE or monitoring steps above depends on it. The honest connection is the software around the machine that teams build themselves: MainDevice applications built on SOEM or the IgH master, edge gateways that pull data out of the segment, OPC UA and MQTT bridges, analytics services and the container images they ship in.

For that software, Safeguard's software composition analysis builds a dependency inventory of your own code, container scanning shows which images carry which package versions, and SBOM generation and analysis records the result in SPDX or CycloneDX. The platform shows which projects contain a given component and version, vulnerability matching and reachability analysis help you decide what to fix first, and policies and gates can stop a build that pulls in a known vulnerable version. When an advisory lands for a protocol library or a gateway's web framework, "which of our services still ship it" has a quick answer. See using SBOMs to find affected products fast. SubDevice and controller firmware is different: when the vulnerable code is inside a vendor's drive or I/O module, the fix has to come from that vendor.

The fit here is indirect, but real. A rebuilt MainDevice host or edge gateway pulls its open source libraries again from package managers and base images, and those dependencies need the same hygiene as any other software you ship.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not EtherCAT monitoring or machine network security. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at an edge gateway or a MainDevice application repository your team builds, the same scan lists the packages and versions inside it and their known vulnerabilities, so you know what to rebuild after a library advisory.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a vulnerable dependency in a Node.js or Python service that collects data from a machine's controller.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• EtherCAT Technology Group: EtherCAT technology introduction
• EtherCAT Technology Group: FAQ
• EtherCAT Technology Group: EtherCAT and Cybersecurity
• IEEE Registration Authority: EtherType assignments
• Wireshark Wiki: EtherCAT protocol page
• IgH EtherCAT Master README
• IgH EtherCAT Master INSTALL
• IgH EtherCAT Master FEATURES
• SOEM repository and README
• SOEM v2.0.1 release
• SOEM slaveinfo sample source
• SOEM firm_update sample source (FoE update in BOOT state)
• CISA ICSNPP-Ethercat Zeek parser
• ISA: ISA/IEC 62443 series of standards
• NIST SP 800-82 Rev. 3: Guide to Operational Technology Security
• IEEE 1588-2019: Precision Clock Synchronization Protocol
• ODVA: EtherNet/IP
• ODVA: CIP Security
• Modbus Organization FAQ
• PROFIBUS and PROFINET International: PROFINET overview

Last reviewed: 24 October 2026. EtherCAT security extensions, ISA/IEC 62443 parts and NIST SP 800-82 are all under active revision; check the pages above for the current editions before relying on a specific part number or security level claim.