EU CRA: Guidance for Non-IP Embedded Communication Systems

February 24, 2026

Blog

In other words, reduce the likelihood of having your system hacked.

Communication networks for operational technology (OT) and Industrial Internet of Things (IIoT) networks include UART, SPI, I2C, USB, CAN, Modbus RTU, other fieldbuses, and potentially proprietary local links. Such networks can be attacked through physical access, maintenance interfaces, compromised connected devices, or gateways to other networks. The EU Cyber Resilience Act (CRA) points out that relatively “unimportant” components may be used as a stepping stone to attack other parts of a larger system. Therefore, even without a direct Internet connection, these risks are sufficient to trigger CRA obligations, unless your application’s cybersecurity requirements are already EU-regulated (like automotive, aviation, medical).

There are no CRA harmonized standards that help us determine what measures we should apply to these networks. However, widely used cybersecurity standards such as IEC 62443, ISO IEC 27001, ETSI EN 303 645, and select NIST SP 800 risk-management standards follow a common principle: security measures are selected based on risk and potential impact, taking into account technical feasibility, effectiveness, and proportionality, which in practice also includes economic considerations.

Main Attack Surfaces

For all connected devices, the CRA requires a secure software update mechanism. If the embedded communication is used to install code update files, then these must be integrity-protected, authenticated, and encrypted. These security mechanisms must be independent of the embedded communication, which only passes on the protected files (considered a black channel).

Any sort of cybersecurity attack will need access to the device or system, either remotely through other networks or locally through physical access to wires and connectors. Therefore, if you can reliably ensure that this sort of access is not possible, then you might not need any further protection.

From the embedded communication perspective, the first step is to review all logical access options. Which interfaces, bridges, and gateways connect the embedded network or fieldbus to other networks? All existing elements need state-of-the-art security protection.

The second step is to review your system’s physical access options. This is where the length and accessibility of the network cabling come into play. Is the embedded communication on a PCB only, which is often the case with SPI or I2C? Or do you have longer wiring, like often found with CAN-based systems or other fieldbuses?

For any risk assessment that considers physical access attacks, it’s important to understand how determined your potential attackers might be. Although the CRA does not require a specific security level, you must show in your risk assessment which kinds of attacks you included or excluded. Depending on the assessment’s depth, this may include attacks from within the supply chain, rogue employees, or potential attacks coming from system owners or operators.

As an example, for any building-control application, including elevators and climate control, one attack scenario would be someone pretending to be a service technician to get physical access. The security documentation and risk assessment for such cases should clearly state that any building operator needs to implement appropriate access control policies to ensure that sensitive equipment can’t be reached by unauthorized personnel.

If all access options are covered and well protected, then typically no further security measures are required. Nevertheless, you still need to properly document how these protections are enforced.

System-Level Security Measures

Further security issues arise if physical access can’t be reliably protected or a breach of a logical access point needs to be considered “possible.”

To better protect an existing system with such issues, introduce security monitoring and logging, which can be added to the main controller or as a separate module with its own communication link to the higher control level. Such a security monitor entity continuously scans the network for abnormal behavior and reports and logs these. Preferably, it has system-specific knowledge and, besides generic unexpected communication patterns, it recognizes configuration changes, timing deviations, abnormal resets, and other unusual communication.

If the physical exposure to the wiring is limited to a single segment of the entire network, then one additional step to increase security is to replace the communication on the affected segment with something secure. For example, secure CAN FD protocols and a classical CAN-to-CAN-FD router with such a protocol can be used as a bridge between unsecure classical CAN and secure CAN FD communications, only using secure CAN FD on the exposed segment.

Node-Level Cryptographic Security Measures

Note that the security measures described so far didn’t require security-specific updates to hardware, firmware, and protocols. However, if an attacker potentially still has network access, then we need to introduce cryptographic methods to authenticate nodes, protect configurations, and potentially encrypt sensitive data.

The ability of a main controller or system monitor to continuously verify that all connected nodes are authentic and their configurations cannot be changed without authorization significantly lowers the overall security risk. This functionality must be provided in a higher protocol layer. For CAN systems, such an enhancement is currently being specified for classical CANopen and CANopen FD.

While this ensures that all nodes are authentic and properly configured, it still leaves attackers the option to perform frame or message manipulations. While these can be recognized by the system monitor, reported, and logged, they can’t be prevented. Once cryptographic methods are in place, for the next security level up, we can review if and how these can be applied to individual frames or messages for their direct protection. Frames or messages not containing proper authentication will be discarded by receivers.

For resource-constrained communication systems, adding state-of-the-art IP security protection to individual frames or messages can be very challenging. Packet sizes might not allow for the required overhead, and larger tag (or MAC) sizes (of up to 32 bytes) are overkill for just a few bytes of sensor data. The MCU may not have the performance or resources to authenticate and/or encrypt all communication.

Cryptographic solutions addressing these requirements include CANcrypt, AUTOSAR SecOC, Modbus Secure Extensions, various proprietary solutions, and SPsec–Small Packet Network Security, jointly developed by Hochschule Offenburg and Embedded Systems Academy.

The security of SPsec is based on multiple pre-shared keys (PSK) and supports cTLS (Compact Transport Layer Security) communication as well as a secure grouped multicast communication mode that CAN-based applications often need. Various block ciphers, including AES (Advanced Encryption Standard) are supported via an AEAD (Authenticated Encryption with Associated Data) interface. SPsec is available as source code for integration into higher-layer protocol stacks like CANopen. The SPsec specification is available for download at the Embedded Systems Academy library section.

Security Evaluation and Applicable Measures Flowchart

The above flow chart shows an overview of the steps involved in preparing a fieldbus for CRA compliance. Depending on your individual risk assessment, it might make sense to add “optional” measures as the CRA asks for defense in depth. A single security breach should only expose parts of the system, never the entire system.

The steps of the flow chart are:

1. If gateways, bridges, or other interfaces to other networks exist within the fieldbus, secure them properly.
2. If physical access to the fieldbus wiring or connectors is potentially possible for attackers, verify which further access restrictions can be implemented, and add a security monitoring and logging entity.
3. If the exposure of the fieldbus wiring is physically limited, consider replacing that network segment with secure communication using security bridges or gateways.
4. If security monitoring alone is not sufficient, then ensure that nodes support authentication and configuration locking mechanisms, allowing the main control or security monitor to authenticate nodes.
5. If the delayed security detection of a security monitor is not good enough, then add authentication to frames or messages containing important data.
6. If privacy is required for sensitive data, add encryption to the corresponding frames or messages.

Summary and Outlook

Which security measures are required for an application using fieldbuses to be CRA compliant depends on the system-specific risk assessment. The attacks and measures explained in this article show that even without introducing cryptographic methods to every node, many existing fieldbus systems can pass CRA requirements. For those potentially requiring a standardized security level, such as SL2 or SL3 of IEC 62443, the cryptographic measures provided by security protocols such as SPsec should help reach the desired level.

---

Julian Goeppert received a B.Eng. degree in mechanical engineering from Baden-Württemberg State University, Karlsruhe, in 2019 and an M.Sc. degree in automotive systems engineering from Karlsruhe University of Applied Sciences in 2021. 

Christian Keydel is an associate of Embedded Systems Academy, where he supervises embedded software development. He studied electrical engineering with a focus on computer science at the Technical University in Karlsruhe and quickly navigated his career towards Embedded Systems hardware and then software design.

Olaf Pfeiffer studied technical computer science at the Cooperative University in Karlsruhe. He is a founder of the Embedded Systems Academy.

Axel Sikora is a full professor at Offenburg University of Applied Sciences, where he leads the Institute of Reliable Embedded Systems and Communications Electronics (ivESK), a renowned partner for applied research for intelligent industrial IoT connectivity and security solutions. Since 2019, he has served as chairman of the embedded world Conference, the world’s largest event on the topic.