How EU CRA and IEC 62443 impact CANopen device manufacturers

What you need to know about the Cyber Resilience Act (CRA) and controller area network (CAN) components

March 9, 2026

4 min read

Key Highlights

The EU Cyber Resilience Act (CRA) is already in force and will require all non-exempt CAN-connectable products to fully comply with its cybersecurity requirements by December 11, 2027.
Because standard CAN protocols lack intrinsic security, manufacturers must conduct risk assessments and implement measures, ranging from physical access restrictions for Security Level 2 (SL 2) to advanced cryptography for SL 3—based on the IEC 62443 standard.
While the CRA applies to most digital and software products, certain sectors like medical devices, aerospace and automotive are exempt if they are already covered by specific cybersecurity regulations such as the MDR or IVDR.

Cyber resilience is shown using a text and picture of attention icon

The EU Cyber Resilience Act (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, for example, higher-layer protocol stacks and application programs. Therefore, a system-and-application-risk assessment is required.

The CAN data link layer protocols—classic (CC), flexible data-rate (FD) and extended data-field length (XL)—as standardized in ISO 11898-1:2024, as well as standardized higher-layer protocols such as CANopen CC/FD (CiA 301/CiA 1301), do not provide intrinsic cybersecurity measures. Cybersecurity measures can be added depending on the required security level (SL) as defined in the IEC 62443 standard series—security for industrial automation and control systems. 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.

Since December 11, 2024, the CRA is in force, applicable in all EU member states, and is being implemented gradually. Starting June 11, conformance assessment bodies (CABs) can assess the fulfilment of requirements. Starting September 11, 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.

EU regulations for medical device cybersecurity, primarily driven by the Medical Device Regulation (MDR) 2017/745 and In Vitro Diagnostics Regulation (IVDR) 2017/746, require manufacturers to implement secure-by-design principles across the entire product lifecycle. Compliance involves risk management for cyber threats, software validation and adherence to updated Medical Device Coordination Group (MDCG) guidelines and the EU Cyber Resilience Act.

Get your subscription to Control Design’s daily newsletter.

There are also other regulations in power that might need to be complied with, such as the U.S. Food & Drug Administration (FDA) cybersecurity guidance for medical devices—Quality System Considerations and Content of Premarket Submissions. This guidance, issued in the summer of 2025, adds Section VII to address FDA’s recommendations regarding Section 524B of the U. S. Federal Food, Drug & Cosmetic Act for cyber devices. This document supersedes the final guidance "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," released September 27, 2023.

CANopen and security

CAN in Automation (CiA) has a long history in developing security measures against unintended misuse, as well as intended manipulation of CANopen communication. This also covers 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; that, in case of service data object (SDO) transmission, SDO segments belong together; and that they have not been manipulated. Some CANopen specifications already provide dedicated security measures—for example, the CiA 710 generic CANopen bootloader or the CiA 417-1/CiA 814-1 CANopen lift bootloader.

According to the open systems interconnection (OSI) model, security controls can be applied to each of the seven OSI layers, depending on the required SL and expected attack scenarios. This is defined in the ISO 7498-2:1989, Information processing systems — Open Systems Interconnection — Basic Reference Model — Part 2: Security Architecture, framework. For the CAN XL data link layer, CiA members are developing the CANsec approach, a cybersecurity extension specified in CiA 613-2, CAN XL add-on services — Part 2: CANsec data plane. This CiA technical document is expected to be released in 2026.

CiA board of directors statement

The CiA board of directors, Magnus Hell (Infineon), Christian Schlegel (CHS Consulting), and Holger Zeltwanger, has worked out the following statement, evaluating the EU CRA regulation and impacts on CAN networks:

The nonprofit CiA (CAN in Automation) international users’ and manufacturers’ group informs its members that products using CAN and placed on the EU markets fall under the European 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. For now, suppliers of CAN-connectable devices are requested by their customers to comply with a dedicated SL (security level) 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. 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 are protected by means of firewalls or are made not accessible (e.g., the JTAG interface, named after the Joint Test Action Group).

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.

If cryptography is necessary, its use can be limited to core functions. 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 (e.g., by means of passwords). Such core security functions are currently under discussion in the CiA SIG (special interest group) HLP (higher-layer protocol) cybersecurity and expected to be integrated into CANopen CC and CANopen FD specifications.