How is security ensured in EtherCAT?
The first step is to separate two meanings of the word “security.” Safety over EtherCAT (FSoE) is a functional-safety protocol for machine safety functions; it is not the cybersecurity mechanism that protects an engineering account from an attacker. Cybersecurity has to protect the complete EtherCAT system: the field segment, MainDevice, engineering workstation, user access, gateways/EoE paths, firmware, supervisory networks and change process.[1]
Read the image as layered defence, not as a protocol feature list. Access control, encrypted communication, device authentication, CRC, segmentation and monitoring appear together in the diagram. They are not all intrinsic properties of every cyclic EtherCAT frame. CRC detects transmission errors; it is not cryptographic authentication. TLS or authenticated encryption belongs to the relevant engineering, upper-network or enhanced security layer rather than being assumed on every classic EtherCAT process-data telegram.
FSoE protects functional safety, not user accounts or malware boundaries
Safety over EtherCAT carries safety-related information for emergency stops, guard functions, safe I/O and safe drive functions. ETG states that FSoE was developed according to IEC 61508, standardized in IEC 61784-3 and can be used in applications up to SIL 3 when the complete safety function meets the required conditions.[2]
Its black-channel principle does not rely on the underlying communication medium for safety integrity. The safety connection checks items such as Connection ID, watchdog timing and safety CRC. These mechanisms address communication faults relevant to functional safety; they do not stop a stolen engineering credential or malware on the MainDevice PC. That is why SIL, machinery safety and industrial cybersecurity have to remain separate engineering disciplines.[3]
EtherCAT's field architecture can reduce the exposed attack surface
ETG's 2026 cybersecurity material points to several architectural characteristics: SubDevice frame processing is hardware-based, classic cyclic EtherCAT does not depend on a normal TCP/IP application stack, and EtherCAT frames are actively generated by the MainDevice. This can leave a smaller conventional IT-style service surface on the field segment than a general-purpose IP network.[4]
That is an architectural advantage, not a claim of invulnerability. The MainDevice, engineering workstation, gateway, EoE service, firmware-update mechanism and upper-level SCADA or IIoT connection can all create attack paths.
CRC is not cryptographic integrity
Ethernet/EtherCAT CRC/FCS is excellent for detecting accidental transmission errors. It does not use a secret key and therefore should not be described as cryptographic protection against deliberate manipulation.
For stronger threat models, ETG's 2026 work describes backward-compatible software security extensions, including authenticated encryption. These enhanced mechanisms should not be assumed to be present in every existing EtherCAT controller or SubDevice; the actual MainDevice, configurator and security implementation have to be verified.[5]
What does the 2026 IEC 62443 assessment actually prove?
ETG's 2026 whitepaper and UL Solutions assessment describe defined EtherCAT system architectures that satisfy IEC 62443-3-3 Security Level 2 requirements, with software extensions available for higher attacker-strength scenarios associated with SL3.[6]
This does not make every EtherCAT machine automatically “IEC 62443 SL2 certified.” Certification and security claims depend on the assessed system boundary, configuration and implemented controls. A machine with shared admin passwords or unrestricted remote engineering access is not made secure simply by using EtherCAT.
Protect the MainDevice and engineering workstation
The MainDevice controls configuration and initiates the EtherCAT traffic, so unauthorized engineering access is one of the most important risks. Use separate user accounts, least privilege, strong authentication, controlled remote access, session locking and change logging on the PLC/IPC and engineering workstation.
A permanently open engineering session or shared administrator password can defeat otherwise strong protocol architecture. The EtherCAT programming and engineering tools guide helps identify which software components need this access control.
Segment the field network from IT and untrusted networks
NIST SP 800-82 Rev.3 treats segmentation, controlled boundaries and layered security as core OT security practices.[7]
The EtherCAT field segment should not be connected casually to an office switch, guest Wi-Fi or the Internet. Use appropriate industrial firewalls, routers, DMZs or controlled gateways between PLC/HMI, SCADA and enterprise networks where required. An air gap can reduce exposure but is not a complete strategy; maintenance laptops, USB media and temporary remote-access connections can bridge it.
EoE and gateways create explicit security boundaries
Ethernet over EtherCAT (EoE) tunnels standard Ethernet frames through EtherCAT mailbox communication. That can be useful, but it also brings standard Ethernet services closer to the field segment and therefore belongs in the threat model. EoE does not mean that ordinary cyclic EtherCAT process data is TCP/IP-based.[8]
Gateways to Modbus, PROFINET, CANopen, IO-Link or other networks create similar boundaries. When integrating the other industrial Ethernet protocols, define not only which data is translated but also which services and directions are allowed across the boundary.
Device identity and topology changes can provide security-relevant evidence
The EtherCAT MainDevice knows the expected devices and physical topology. Unexpected devices, changed order or topology manipulation can therefore be detected through the configuration and diagnostic mechanisms. ETG includes this capability among EtherCAT's cybersecurity strengths.[9]
Detection is not the same as authentication. In a critical installation, device replacement, ESI revision, firmware version and spare-part approval should be part of formal change management. The device integration and topology guides explain where that technical evidence comes from.
WKC and EtherCAT diagnostics are useful evidence, not a full IDS
Working Counter, AL Status, link status, port-error counters and topology information can expose unexpected communication changes quickly. A falling WKC can show that an expected memory transaction no longer has the configured participation.[10]
That does not tell you whether the cause is an attack, a broken cable, a reset device or a configuration error. EtherCAT diagnostics should be correlated with firewall, endpoint-security, engineering and data-logging records.
Firmware and device security remain vendor-level responsibilities
Secure boot, signed firmware, update policy, local user management, debug interfaces and service ports are not identical across all EtherCAT products. They need to be verified on the actual device. EtherCAT conformance provides evidence about protocol behavior; it does not by itself certify the entire product cybersecurity lifecycle.
For new equipment, review firmware-support policy, security advisories, default accounts and remote-service methods in addition to the EtherCAT feature list.
Backups and recovery are part of security
A verified backup can be the fastest route back from an attack or an unauthorized change. Keep controlled copies of the PLC/MainDevice project, ESI set, device parameters, safety project, HMI/SCADA configuration and relevant firmware versions.
A backup is not useful if nobody knows which machine revision it belongs to. This is where EtherCAT troubleshooting and cybersecurity meet: restoring an unknown old project can create a fresh configuration fault or reintroduce an insecure setting.
Use the wider OtomasyonAVM content as one security map
EtherCAT security should not live on an isolated protocol page. OtomasyonAVM's industrial cybersecurity section covers the OT context; Ethernet network security covers general network protection; SIL and machinery safety cover functional safety; and the PLC, HMI and SCADA branches show the actual assets that must be protected.
This turns “EtherCAT security” into the real engineering chain: protocol + device + controller + engineering workstation + upper network + user + safety function.
A practical security checklist
| Control | Purpose | Bad assumption |
|---|---|---|
| FSoE | Functional-safety communication | “FSoE stops hackers” |
| Segmentation | Control OT/IT boundaries | “A separate switch makes it secure” |
| User access | Restrict MainDevice and engineering changes | “Shared admin is fine because the protocol is secure” |
| CRC / WKC | Detect transmission/process anomalies | “They provide cryptographic proof” |
| EoE / gateway policy | Limit cross-network services | “A gateway adds no attack surface” |
| Firmware / backups | Secure change and recovery | “Any backup can be restored safely” |
| Monitoring | Correlate topology, WKC, users and firewall events | “One log source proves an attack” |
Bottom line: security is a system architecture, not one EtherCAT setting
EtherCAT's hardware-oriented field processing, MainDevice hierarchy and limited classic IP exposure can provide a useful cybersecurity foundation. ETG's 2026 IEC 62443 work shows that this architecture can support strong security claims in defined system scenarios. A secure machine still requires access control, segmentation, engineering-workstation protection, device/firmware security, monitoring, backup and controlled upper-network integration.
Use FSoE for functional-safety communication. Use layered OT cybersecurity for malicious-threat protection. Treating those as the same “security” problem is one of the most dangerous conceptual mistakes in industrial networking.
Related EtherCAT and OtomasyonAVM guides
• What is EtherCAT?
• EtherCAT MainDevice–SubDevice communication
• EtherCAT topology
• EtherCAT device and sensor integration
• EtherCAT troubleshooting
• EtherCAT and industry standards
• Industrial cybersecurity
• Ethernet network security
• SIL
• Machinery safety standards
• Industrial communication
Technical references
[1] EtherCAT Technology Group — EtherCAT & Cybersecurity; cybersecurity architecture versus functional safety. EtherCAT & Cybersecurity
[2] EtherCAT Technology Group — Safety over EtherCAT, IEC 61508 / IEC 61784-3 and SIL 3 scope. FSoE
[3] EtherCAT Technology Group — FSoE black-channel principle, Connection ID, watchdog and safety CRC. FSoE Introduction
[4] EtherCAT Technology Group — 2026 cybersecurity assessment: hardware frame processing, MainDevice hierarchy and minimized attack surface. Built-in Cybersecurity Whitepaper
[5] EtherCAT Technology Group — authenticated encryption and backward-compatible software security extensions for higher requirements. 2026 Whitepaper
[6] EtherCAT Technology Group / UL Solutions — explanatory notes on IEC 62443-3-3 assessment scenarios, April 2026. Certification Notes
[7] NIST — SP 800-82 Rev.3, Guide to Operational Technology Security. NIST SP 800-82 Rev.3
[8] EtherCAT Technology Group — Ethernet over EtherCAT (EoE). EoE
[9] EtherCAT Technology Group — detection of topology/device manipulation as a cybersecurity-relevant architectural capability. Cybersecurity
[10] EtherCAT Technology Group — Working Counter and network diagnostics. EtherCAT Diagnosis for Users