Skip to content
Protocol Encyclopedia | | | 8 min read

EtherCAT - on-the-fly processing in industrial networks. Architecture, security and FSoE

EtherCAT according to IEC 61158 Type 12 - EtherType 0x88A4, cycle <=100 us, Distributed Clocks, FSoE. Security limitations and architectural recommendations.

J
Józef Sulwiński
EtherCATIEC 61158layer 2OT
EtherCAT - on-the-fly processing in industrial networks. Architecture, security and FSoE

EtherCAT (Ethernet for Control Automation Technology) was developed by Beckhoff Automation and standardised in IEC 61158 (Type 12) and IEC 61784-2. Stewardship of the standard was taken over in 2003 by the EtherCAT Technology Group (ETG) - today one of the largest standardisation organisations in industrial automation.

EtherCAT’s key innovation - processing on the fly - makes it possible to achieve communication cycles shorter than 100 us with jitter below 1 us. This property is why EtherCAT dominates in Motion Control applications, CNC machine tools and packaging machines, where tight synchronisation of many axes is required.

Processing on the fly

In a typical Ethernet protocol, a frame arrives at a device, is copied into a buffer, processed, and possibly retransmitted. Every step adds latency. EtherCAT works differently:

  1. The master sends a single Ethernet frame containing data for all slaves on the line (up to 65,535 devices).
  2. Each slave reads and modifies the data in its portion of the frame as it passes through - using a dedicated hardware ASIC (ET1100, ET1200, ESC20xx) or an SoC solution.
  3. After traversing all slaves, the frame returns to the master (ring topology logic) with the complete set of input data.

This mechanism eliminates the overhead of the TCP/IP stack and repeated buffering. A single Ethernet frame of up to 1498 bytes (excluding Ethernet/FCS overhead) can carry up to 1486 bytes of data divided across many slaves.

Topology and addressing

EtherCAT does not require a typical Ethernet switch. Slave devices usually have two ports (in/out), forming a line, a ring or a tree through branch modules. Slave addressing:

TypeDescription
Auto-increment addressPosition in the topology (assigned by the master at startup)
Configured station addressLogical address configured statically
BroadcastAll slaves
Logical addressAddress in the 4 GB logical space (for EtherCAT Mailbox)

Frame structure

An EtherCAT frame is encapsulated in an Ethernet frame with EtherType 0x88A4 (directly at layer 2):

FieldLengthPurpose
EtherCAT Header2 bytesLength, reserved, Type (1 = EtherCAT command)
Datagram 1..NvariableIndividual commands to slaves
- Command1 byteOperation type (LRD, LWR, LRW, FPWR, BWR, etc.)
- Index1 byteDatagram ID
- Address4 bytesSlave or logical address
- Length11 bitsData length
- Flags5 bitsC (Circulating), R (Reserved), M (More follows)
- IRQ2 bytesInterrupt status
- Data0-1486 bytesPayload
- WKC (Working Counter)2 bytesCounter of acknowledgements from slaves

The Working Counter is an elegant acknowledgement mechanism: each slave increments the WKC after successfully handling a command. When the frame returns, the master verifies that the WKC has the expected value - instant diagnostics telling it whether all slaves are operating correctly.

Distributed Clocks

Distributed Clocks (DC) is a mechanism for synchronising the clocks of all devices on the network with an accuracy better than 1 us. A selected slave (typically the first one behind the master) becomes the reference clock. The master measures propagation delays to every slave (a hardware “ping” technique) and distributes offsets that each slave applies to its local clock.

Precise synchronisation is a necessary condition for Motion Control applications - drives for many axes must issue commands at precisely defined moments, regardless of their distance from the master.

FSoE - Safety over EtherCAT

FSoE (FailSafe over EtherCAT), standardised in IEC 61784-3-12, is a safety layer up to SIL 3 according to IEC 61508. It follows the same philosophy as PROFIsafe - black channel: the safety layer is independent of the reliability of the transport medium.

FSoE mechanisms:

  • ConnID unique to the sender-receiver pair
  • Sequence number
  • Safety CRC
  • Watchdog

FSoE operates as an application layer on top of the standard EtherCAT Mailbox - it requires no special hardware in the infrastructure, only the end devices (safety I/O modules, safety drives) need to support FSoE.

Cybersecurity of EtherCAT

WARNING

In its baseline form, EtherCAT has no cybersecurity mechanisms - neither authentication nor encryption. The design assumption is that the entire EtherCAT network sits in a physically controlled, trusted segment. Violating this assumption (an attacker gaining access to the cabling or to an unused slave port) gives full control over the traffic.

Attack vectors:

AttackEffect
MITM between master and first slaveModification of LRW commands, changing setpoint values of drives
Frame injectionInjecting attacker-crafted EtherCAT frames into the topology
Slave impersonationImpersonating a slave - accepting output values, ignoring real ones
DC desynchronizationManipulating Distributed Clocks offsets - degrading Motion Control
EoE abuseEtherCAT over Ethernet allows tunnelling standard Ethernet - can be used as an exfiltration vector

Unlike PROFINET (where PI released a Security specification in 2020), EtherCAT has no formal cybersecurity specification. ETG has published a Security Guideline with recommendations, but it is not a mandatory standard.

EoE, SoE, CoE - applications over EtherCAT

EtherCAT allows tunnelling of other application protocols through its Mailbox mechanism:

AcronymExpansionPurpose
CoECANopen over EtherCATCANopen PDOs and SDOs - the dominant application profile
SoESERCOS over EtherCATSERCOS Motion Control profiles
EoEEthernet over EtherCATEthernet tunnel (e.g. for a device web server)
FoEFile Access over EtherCATFile transfer (firmware update)
AoEADS over EtherCATBeckhoff ADS protocol

EoE is particularly interesting from a security perspective - it allows any Ethernet traffic to be sent through an EtherCAT network. Deployed carelessly, it can become a tunnel that bypasses segmentation.

Architectural recommendations

  1. Physical isolation of the EtherCAT network - the EtherCAT network has no reason to exist beyond a dedicated machine or production line. Masters may communicate with higher layers (SCADA, MES) via TCP/IP, but the EtherCAT network itself remains local.
  2. FSoE for safety functions - mandatory for SIL elements. The black channel allows coexistence with standard traffic.
  3. Monitoring of unusual frames - the master monitors the Working Counter and diagnostics. Unexpected WKC values may indicate manipulation or slave failure.
  4. Firmware updates only via a controlled channel - FoE allows flashing over the network, which is convenient but requires process discipline (hash verification, access control for the engineering workstation).
  5. Disable EoE if not needed - turning off EoE on slaves that do not require it reduces the attack surface.

Analysis and monitoring tools

Wireshark natively decodes EtherCAT:

Wireshark filterUse
ecatAll EtherCAT traffic
ecat_mailboxMailbox (CoE, SoE, EoE, FoE)
ecat_datagramIndividual EtherCAT datagrams

EtherCAT traffic samples:

Zeek parsers (CISA ICSNPP):

Production anomaly monitoring:

  • TwinCAT Scope (Beckhoff, free for analysis) - correlating EtherCAT events with PLC application context
  • Nozomi Guardian, Dragos Platform, Claroty CTD/xDome - all support EtherCAT in their dissectors, although semantic coverage (interpretation of CoE/SoE profiles) varies between products

Open source tools:

  • nsacyber/GRASSMARLIN - passive ICS topology mapping from NSA Cybersecurity. Note: the repository was archived in 2023 - useful for reference, not for production

Summary

EtherCAT is a mature deterministic industrial communication protocol, designed for Motion Control and OT applications that require synchronisation. Functional-safety mechanisms (FSoE) are well developed, but cybersecurity remains a design-time assumption - EtherCAT relies on physical isolation. In a defensive architecture this means the EtherCAT network should remain the innermost zone, cut off from everything except the dedicated PLC.

Related articles: PROFINET (IEC 61158), EtherNet/IP (ODVA).

Sources

Need help in this area?

Our experts will help you assess the risk and plan next steps.

Talk to an expert

We'll discuss scope, methodology, and timeline.

+48 22 292 32 23 Talk to an expert