CRA - Compliance by Consortium
Updated: Aug 26
POSITION NOTE: Through EU legislated CRA (Cybersecurity Resiliency Act) scope is product level, efforts are made to assert compliance by way of systems architecture - will this assertion hold water? We explore this question.
In late 2025, EtherCAT Technology Group consortium announced that its protocol meets the requirements of the EU Cyber Resilience Act. The initial statement, from the EtherCAT Technology Group, was carefully qualified — the protocol was said to meet IEC 62443 and CRA requirements for “almost all common applications,” with a TÜV SÜD assessment report still pending. By April 2026, when UL Solutions issued certificates following IEC 62443 testing, the headline had shed its qualifiers: EtherCAT, the announcements now read, meets CRA requirements for Security Level 2 “without modifications.”
The security case rests on architecture rather than cryptography, and the consortium is candid about this. EtherCAT slave controllers process Ethernet frames on the fly and do not forward non-EtherCAT traffic, which structurally separates the fieldbus segment from the IP network above it and shrinks the attack surface accordingly. It is a real property with real defensive value. It is also a conditional one: the case holds exactly as long as the segment boundary holds and the master — a general-purpose industrial PC running a commodity operating system, and therefore the actual attack surface of any EtherCAT system — remains uncompromised. The protocol itself carries no authentication, no integrity protection, and no encryption; the consortium's own roadmap of optional protocol extensions for higher security levels concedes as much. What was demonstrated, then, is that a well-designed system built on this protocol can present a defensible security architecture. That is a meaningful statement. It is a statement about systems, made under a systems standard — and the Cyber Resilience Act does not regulate systems, standards, or protocols. It regulates products.
Without meaningful security features that directly map to CRA Annex 1 "Essential Requirements" the protocol itself cannot be a coverage statement for products that adopt it. Each product, regardless of supporting protocols, must demonstrate the adherence to it. If the protocol enables some requirements of Annex 1 in the product, then it can be used but the compliance scope is the product, not the protocol.
Additionally, no one can hold the claimed conformity yet. The harmonized standards are what convert a technical finding into a legal presumption of conformity, and as of mid-2026 none exists: the Commission's standardization request was accepted by the European standards organisations in April 2025, the first deliverables are expected only in the second half of 2026, none has been ratified or cited in the Official Journal, and the OT-specific profiles are among the least mature of the programmed. IEC 62443 will inform those standards; it is not yet, in any legally operative sense, “the basis for the CRA.” Any current claim that anything “meets CRA requirements” is therefore a prediction about an unpublished measuring stick


Comments