CAN networks can meet EU CRA requirements, but security levels matter

EU Cyber Resilience Act puts security scrutiny on CAN-based products
Feb. 17, 2026
4 min read

The nonprofit CAN in Automation (CiA) international users’ and manufacturers’ group has informed its members that products using controller area network (CAN) protocol and placed on the EU markets fall under the European Union Cyber Resilience Act (EU CRA), unless the relevant cybersecurity aspects are covered by application-specific EU legislation. In most cases, the required risk assessment may be a self-assessment, unless the product is considered critical, as defined in the CRA Annex III.

“It remains to be seen, which future standards best reflect the EU CRA requirements,” reads a statement released by the CiA board of directors on the EU CRA and its impact on CAN networks. “For now, suppliers of CAN-connectable devices are requested by their customers to comply with a dedicated security level (SL) as defined in the IEC 62443 standard series—security for industrial automation and control systems.”

CiA is confident that SL 2 can often be reached with minimal effort for CAN networks. “Achieving SL 3 requires more advanced security measures involving cryptography at CAN data frame (data link layer entity) or CANopen message (application layer entity) level,” the statement continues. “CiA’s assessment is that CAN networks with restricted and limited physical access usually comply with SL 2 or lower, not needing additional cybersecurity measures.” This assumes that gateway functions to other networks and external interfaces, such as the Joint Test Action Group interface, are protected by means of firewalls or are made not accessible.

“If restricted and limited physical access is difficult to enforce, cybersecurity measures do not necessarily require cryptography. In CiA’s view, a security monitoring entity that scans communication on abnormal behavior, detecting and reporting attack, is an efficient security measure as indicated in the CRA regulation and the IEC 62443 standard series. It reduces overall risks for undetected attacks, having a positive influence on the risk assessment and showing a defense in-depth approach,” the statement reads.

If cryptography is necessary, its use can be limited to core functions, according to the CiA board’s statement. While a secure software update mechanism might be mandatory for CRA compliance, in many cases, further use of security functions can be reduced to secure CAN node authentication and device configuration protection, by means of passwords, for example. “Such core security functions are currently under discussion in the CiA’s higher-layer protocol (HLP) cybersecurity special interest group (SIG) and expected to be integrated into CANopen CC and CANopen FD specifications,” the statement continues.

The CAN data link layer protocols—CC, FD and XL—as standardized in ISO 11898-1:2024, as well as standardized HLPs such as CANopen CC/FD (CiA 301/CiA 1301) do not provide intrinsic cybersecurity measures. Cybersecurity measures can be added depending on the required SL. Therefore, suppliers of CAN-connectable devices, vendors of products based on CAN networks and CAN network designers need to evaluate which SL is required by the targeted application.

CiA has a history in developing security measures against unintended misuse, as well as intended manipulation of CANopen communication. This covers also unauthorized access to CANopen devices and CANopen networks. There are password options for the CANopen object dictionary access. Furthermore, there will be an authentication signature option in CANopen messages specified, indicating that they are from the right origin and that in case of service data object (SDO) transmission, SDO segments belonging together and that they have not been manipulated. Some CANopen specifications, such as CiA 710 generic CANopen bootloader or the CiA 417-1/CiA 814-1 CANopen lift bootloader, already provide dedicated security measures.

The CRA is the first European regulation to set a minimum level of cybersecurity for products comprising digital elements or software. CAN interface implementations comprise digital elements—protocol controllers—and software, such as HLP stacks and application programs. Therefore, a system-and-application-risk assessment is required.

Since December 11, 2024, the CRA has been in force, applies in all EU member states and implemented gradually. Starting June 11, Conformance Assessment Bodies (CAB) can assess the fulfilments of requirements. Starting September 11, 2026, vulnerabilities and security incidents must be reported to defined authorities within 72 hours. Starting on December 11, 2027, all CRA requirements must be complied with.

The following CAN-connectable products do not fall under the CRA: free-of-charge open-source software and nonprofit products. Additionally, medical products, vehicles, in-vitro diagnostic devices, civil aviation, as well as marine equipment and products used in the context of national security, such as military equipment, are not in the scope of the CRA, when specific cybersecurity-related EU regulations are in place.

According to the open systems interconnection (OSI) model, security controls can be applied to each of the seven layers, depending on the required SL and expected attack scenarios. This is standardized in ISO 7498-2:1989. For the CAN XL data link layer, CiA is developing the CANsec approach, a cybersecurity extension specified in CiA 613-2.

Sign up for our eNewsletters
Get the latest news and updates