CAN Networks Can Meet EU CRA Requirements, but Security Levels Matter

Why It Matters

EU CRA creates a baseline cybersecurity mandate for CAN devices, forcing manufacturers to embed risk‑based controls or face market restrictions. Early alignment with SL 2‑3 standards reduces compliance costs and protects critical industrial networks.

Key Takeaways

• CAN devices now subject to EU CRA compliance.
• SL2 achievable with minimal effort; SL3 needs cryptography.
• Security monitoring can replace cryptography for limited access.
• Firmware updates and node authentication are core CRA requirements.
• Exemptions include open-source, medical, automotive, and defense products.

Pulse Analysis

The European Union Cyber Resilience Act marks the first continent‑wide mandate that sets a minimum cybersecurity bar for any product containing digital elements, including CAN controllers and software stacks. While the regulation officially took effect in December 2024, its enforcement timeline stretches to December 2027, giving manufacturers a window to assess risk, select an appropriate IEC 62443 security level, and prepare for third‑party conformity assessments beginning June 2025. Understanding the CRA’s scope—excluding open‑source, medical, automotive, and defense‑specific items—is essential for supply‑chain planning and market entry strategies across the EU.

Security Level 2 (SL 2) is positioned as the baseline for most CAN networks, achievable through basic hardening measures such as password‑protected object dictionaries and secure firmware update mechanisms. For higher‑risk applications, SL 3 calls for cryptographic protection at the data‑link or application layer, which can be costly to implement on legacy hardware. CiA suggests that, where physical access is tightly controlled, continuous monitoring of traffic anomalies can satisfy CRA requirements without full‑blown encryption, aligning with IEC 62443’s defense‑in‑depth philosophy. This approach balances compliance costs with operational practicality, especially for industrial automation environments where gateway firewalls already limit external exposure.

Looking ahead, the industry is preparing new security extensions like CANsec (CiA 613‑2) and integrating authentication signatures into upcoming CANopen CC/FD specifications. These developments aim to embed cryptographic identity checks and secure bootloader functions directly into the protocol, simplifying future CRA compliance. Manufacturers should therefore prioritize participation in CiA’s cybersecurity special interest groups, update their product roadmaps to include secure node authentication, and establish incident‑response processes ahead of the September 2026 reporting deadline. Proactive alignment not only avoids regulatory penalties but also strengthens the overall resilience of CAN‑based control systems in an increasingly threat‑rich landscape.

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

Control Design · 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, indicating that they are from the right origin and that, in case of Service Data Object (SDO) transmission, SDO segments belonging together 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 12 December 2024, the CRA has been in force, applies in all EU member states and is being implemented gradually.

• Starting 11 June 2025, Conformance Assessment Bodies (CAB) can assess the fulfilment of requirements.

• Starting 11 September 2026, vulnerabilities and security incidents must be reported to defined authorities within 72 hours.

• Starting 11 December 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 (e.g., military equipment) are excluded 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.