Embedded Systems Academy

The EU Cyber Resilience Act does not make an exception for a device because it speaks CAN rather than Ethernet. If you build or integrate industrial control units on CAN or CAN FD, you now have to show that your product resists tampering, updates itself safely, and manages its keys with care. We have gathered what that takes into a new and free reference at https://cansecurity.net/.

The pressure comes from regulation: the Cyber Resilience Act and the Machinery Regulation turn security into a legal obligation for products with digital elements, and IEC 62443 sets the technical bar an assessor will measure you against. On some CAN nodes based on constraint microcontrollers, clearing that bar is an engineering problem rather than a checkbox.

The reference works through that problem in the order an engineer meets it. It names the threats a broadcast bus exposes, walks a risk assessment built on CVSS v4.0 and IEC 62443-3-2, and catalogs the controls that fit a fieldbus: bus-load monitoring, local injection detection, cryptographic frame security, anomaly and event monitoring, secure object access for CANopen, zoning and
segmentation, and an authenticated secure bootloader. A separate section covers key management, from the choice between symmetric and asymmetric keys through per-device diversification, the manufacturer-to-integrator-to-operator handover, and the point where a minimal public-key infrastructure is enough.

A few resources stand on their own. There is a Cyber Resilience Act Annex I requirements matrix and an IEC 62443 SL2 component-requirements table, a maintained list of CAN FD microcontrollers that pair the interface with on-chip security such as a true random number generator, secure key storage or cryptographic accelerators. Plus a set of measured benchmarks showing what SHA-256, HKDF, AES-128-GCM, Ed25519, and X25519 cost in flash, RAM, stack and time on real parts. When a datasheet claims a hardware accelerator, the benchmark page shows what improvements you can expect.

Take a look at https://cansecurity.net/ and tell us what you are missing. We will keep adding to it.

Latest cybersecurity acts and regulations now expect a Defense in Depth approach. As our figure illustrates, several protection layers can be applied to CAN-based systems. With our CANcrypt/SPsec solution we offer cryptographic protection just above the data link layer. For many applications, however, the CANopen higher-layer protocol still needs cybersecurity of its own.

EmSA has been working on exactly that, and we want to share where it stands. Two white papers set the foundation. EmSA-WP-104 covers key provisioning for minimal fieldbus systems, and EmSA-WP-105 describes SOFA, our Secure Object Fieldbus Access method. Together they define how base keys are provisioned and how a per-transfer challenge-response, FBsec, authenticates each access. The idea is deliberately simple to adopt. Security lives in new, secure Object Dictionary entries that run entirely above the application layer. A secure entry mirrors existing data into an authenticated object, so a client can read an authentic device identity or a server can accept only an authentic write. Reads and writes are authenticated and encryption is optional. Because nothing inside the CANopen stack has to change, the method ports to existing CANopen CC and CANopen FD devices with little effort. The practical payoff shows up in everyday operations. A client can read an authenticated 1018h identity record. A server can accept a concise Device Configuration File only when it is authentic. A single secure 32-bit function code can activate a bootloader, lock write access to selected entries or authenticate Network Management (NMT) commands.

To make these features interoperable across vendors, we are working with CiA standardization groups to define common objects for security methods and configurations, so the same entries are available regardless of device or application profile.

We have gathered the full picture on a new web page at https://can-security.net, where you can follow the work as it develops.

A beta of our open-source reference implementation is available on request.

As 2025 concludes, we at EmSA (Embedded Systems Academy) would like to thank our clients, partners and suppliers for their trust and cooperation over the past year. We truly appreciate all the projects and shared challenges that you bring to us.

For 2026 our focus will be on fieldbus security and the practical compliance support of the EU Cyber Resilience Act (CRA). By the end of 2027, most of our clients must have their products CRA compliant, this is a huge task, and we are here to help. We already have new CRA training in place to support not only development teams and product managers but also system integrators (emsa.courses). The training is designed for real-world embedded fieldbus products with various downloadable templates and examples.

In 2026 we will also publish our commercial SPsec software solution. SPsec is a security sublayer for small-packet networking technologies and the result of a joint research project with Hochschule Offenburg. It is designed to provide authentication and optional encryption for constrained communication systems such as CAN. The SPsec specification is publicly available in our technical library (SPsec specification).

In addition, we will introduce new hardware CAN modules and interfaces that help to strengthen the security and resilience of CAN-based systems.

Our recommendation to CAN system integrators is simple: Contact your suppliers early about their CRA compliance. Building your CRA compliant product with off-the-shelf CAN components is drastically easier when all suppliers have done their homework and can provide CRA documentation including risk-assessment details. Eventually, system integrators will start rejecting products with below-average or poor CRA documentation.

We look forward to supporting you in making your products more secure and more resilient, ready for the Cyber Resilience Act.

We wish you a successful and innovative year 2026!

The first part of the EU Cyber Resilience Act (CRA) obligations will apply from September 11th, 2026. For many companies, this still feels far away, but the reality is that compliance takes months of preparation, don’t start too late to establish or verify your vulnerability handling processes.

Vulnerability Reporting Under CRA

From that date forward, vulnerability handling and reporting obligations apply to ALL products with digital elements offered on the EU market.

Manufacturers must:

• Maintain a 24/7 process to accept and review vulnerability reports from customers, researchers or suppliers.
• A 24h/72h clock starts the moment your organization becomes aware of a potential vulnerability in your product, whether confirmed or not.
• Within 24 hours: if the vulnerability is actively exploited or under attack, send an early warning notification to ENISA or your national notification body.
• Within 72 hours: if the vulnerability could impact the cybersecurity of your product, provide a notification with initial assessment details to ENISA or your national notification body.
• Continue evaluation and proper scoring (e.g. CVSS) while investigation is ongoing, updating notifications as more data becomes available.
• Support the product: provide mitigation documentation or updates with fixes as long as it is still offered on the EU market or supported.
• Keep customers informed without undue delay once a fix or mitigation exists.
• Within 14 days after a fix or mitigation is available: submit a final detailed vulnerability report including root cause and corrective measures.

This is not optional! Failure to comply can mean heavy fines or even blocked market access. Do not underestimate the effort of setting up such a process.

Our free CRA Intro Course

To help companies get started, we published a free 30-minute session on our online academy at https://emsa.courses/course/cra-can-opener

This course gives you:

• A CRA overview and what it really means for product manufacturers,
• A practical look at vulnerability handling and CVSS scoring,
• Examples specific to embedded systems with CAN or CANopen channels.

Our commercial in-depth CRA training is not just theory. It includes guidelines, checklists and templates that you can use in your own CRA preparation.

The CRA will significantly affect all digital products, including those based on the Controller Area Network (CAN) and using protocols like CANopen. Under the CRA, manufacturers must manage and report vulnerabilities with clear severity scoring. This applies not only to newly developed products but also to products already placed on the EU market.

To support companies in this transition, Embedded Systems Academy continuously publishes white papers that address the different aspects of CAN security and CRA compliance. Currently three papers are published at:
https://www.esacademy.com/en/library/security-white-papers.html

The first, Security Justification for Classical CAN Systems (EmSA-WP-101), explains under which circumstances lightweight or non-cryptographic measures can be sufficient. It shows how techniques like physical access control and event monitoring can provide compliance where full cryptography is impractical. The paper maps these measures against IEC 62443, BSI TR-02102 and CRA requirements and presents structured arguments that auditors can follow.

The second, Interface Driven Security Evaluation for Sensors (EmSA-WP-102), analyses how the choice of sensor interfaces, from memory bus and SPI/I²C to CAN, changes the security evaluation. The central message is that risk depends more on the exposure of the interface than on the protocol itself. Deeply embedded CAN systems may be sufficiently secure. But exposed systems, such as wiring accessible behind easily opened panels, often require additional mitigations. Methods could be as simple as timing checks but also involve cryptography like an authenticated heartbeat. The paper aligns these evaluations with IEC 62443, ISO/IEC 27005 and CRA expectations.

The third, Common Vulnerability Scoring System (CVSS) for CAN (EmSA-WP-103), provides guidance on applying CVSS v4.0 to CAN devices. Because CRA requires vulnerabilities to be reported with standardized severity scores, this paper adapts the CVSS methodology to include CAN-specific considerations. It explains how confidentiality, integrity and availability impacts should be assessed at both node and system levels. It demonstrates how measures such as event monitoring or cryptographic authentication can reduce scores from high to low risk.

These papers are a practical toolkit for organizations producing CAN nodes or machinery using CAN systems. By adopting these approaches now, companies can prepare for the CRA with confidence and ensure that their products remain secure and compliant.

Turning Compliance into a Market Differentiator

The Shift Has Already Begun

Full CRA enforcement begins in December 2027, but purchasing departments will already soon start auditing suppliers about planned compliance. Early adopters have a window to build long-term relationships based on trust and readiness.

Customers will soon ask:

• Do you have a CRA technical file?
• Can you provide an SBOM?
• How and for how long will you provide updates?
• What’s your vulnerability disclosure process?

If you can answer swiftly and confidently, your product becomes more than compliant, it becomes attractive.

Defense in Depth Starts at the Component Level

CRA embeds specific cybersecurity principles, especially defense in depth: limiting attack surfaces, managing access, validating inputs, secure updates, and ongoing vulnerability management.

Even minor components can be attack vectors. An unmaintained module or undocumented interface can compromise a full system. Your customers want components that help them build secure systems. Your documentation must show that you’re part of the solution.

Short-Term Effort, Long-Term Advantage

Yes, CRA adds some effort:

• Documenting processes
• Clarifying support periods
• Generating SBOMs
• Setting up secure update mechanisms

But these are reusable across product lines. And they become selling points:
“We provide a pre-filled CRA technical file, saving you time and audit effort.”
Soon, CRA alignment will be part of RFQs, especially in regulated industries. Early movers will already have what’s needed.

How to Start Now

You don’t need a full conformity assessment yet. Start with these:

1. Draft the basic technical documentation: risk analysis, update policy, SBOM, and contact point.
2. Educate your team: make sure product and sales staff can explain how you support CRA obligations.
3. Label your products: terms like “CRA-ready” or “CRA-aligned” will gain traction fast.

Conclusion: Be the Easy Choice

CRA isn’t just a legal requirement, it’s a new trust signal. Vendors who invest in documentation and defense in depth today won’t just be compliant, they’ll be strategic partners.

Integrators will ask: does your component help us get CRA-certified?

If the answer is yes, you’re the easy choice.

If you want to stay updated on our upcoming CRA training classes, follow us on LinkedIn or check this blog regularly. We’ll share practical tips, updates, and announce training availability as we go live.

Consider joining one of our upcoming presentations by our tutors Olaf Pfeiffer, Christian Keydel and Peter Scheydt. We will share latest insights on cybersecurity regulations and secure communication in embedded networks. If you’re working with CAN, CAN FD, CANopen, or other resource-constrained communication systems, these talks contain vital information about regulatory requirements and potential solutions.

Upcoming Presentations

1. Consequences of the Latest Cybersecurity Acts and Regulations for CAN CC and CAN FD Systems

• CiA Member Days, Frankfurt – February 26, 2025
• Embedded World Conference, Nuremberg – March 13, 2025

New cybersecurity regulations also effect non-Internet embedded networks! This talk explores how evolving laws, including the EU Cyber Resilience Act (CRA), impact CAN, CAN FD, and other small-packet networks. Learn about security-by-design approaches, compliance strategies, and best practices to safeguard your embedded communication systems against modern threats.

2. Minimizing TLS: TLS-PSK variations for Secure Communication in Resource-Constrained Embedded Networks

• Embedded World Conference, Nuremberg – March 13, 2025

Traditional security protocols often introduce too much overhead for low-power, small-packet networks like RS485 or CAN based systems. This presentation introduces TLS-PSK variations optimized for resource-limited environments. Discover how you can enable strong encryption, authentication, and integrity while minimizing processing time, memory usage, and bandwidth consumption.

Key take-a-ways

• Stay ahead of new cybersecurity regulations impacting embedded networks
• Learn practical security solutions for CAN, CAN FD, and other fieldbus systems
• Gain insights from real-world application examples

Mark your calendars and join us!

Links:

• https://can-cia.org/about-us/member-services/cia-member-days-2025
• https://events.weka-fachmedien.de/embedded-world-conference/program

As we step into 2025, the team at EmSA (Embedded Systems Academy) extends our warmest wishes for a prosperous and successful New Year to all our customers and partners!

We have been working on cybersecurity options for embedded small-packet networks for years, but adoption has been slow. Most of our customers know that they need to invest in “some security” eventually. However, without real customer demand or immediate regulatory pressure, the implementation of cybersecurity measures has lagged.

In 2025, we at EmSA plan to publish several white papers to help you “get a grip” on the security aspects of your embedded applications using embedded networks. There will also be a number of non-cryptographic measures applicable to CAN and CANopen networks to help achieve at least one of the lower security levels.

For those who need to go “all the way,” we will offer cryptographic solutions for CAN FD, CANopen FD, RS232 connections, and other embedded small-packet networks.

Follow us on this blog, our LinkedIn page, and our YouTube channel to stay up to date with security measures for small-packet networks.

Learn from Arm’s Christopher Seidl and NXP’s Kyle Dando as they explore how different software layers interact to create efficient industrial systems.

Chris Keydel from EmSA will talk about industrial networking with CANopen and how to integrate Micro CANopen Plus into your own application using Open-CMSIS-Packs.

Perfect for embedded software developers eager to expand their understanding of Open-CMSIS-Packs.

Register now and reserve your spot: https://okt.to/BdKjSE

We are pleased to introduce the latest software update for the CANgineBerry, which now includes a Python example aimed at simplifying network management for developers working across Linux, Windows, and macOS. This new example uses the provided CANopen Manager firmware as an efficient way to visualize and manage devices on a CANopen network.

Unlike basic CAN interfaces (only passing through CAN frames), the CANgineBerry handles the entire CANopen Manager functionality. This allows the module to automatically scan the network, identify new devices, and configure the appropriate Process Data Objects (PDOs) without requiring manual intervention. Through this automated functionality, users can directly access the Object Dictionary entries for both the Manager and the connected devices, reducing the need for writing complex code.

The Python example showcases these features through a lightweight graphical user interface (GUI). Once connected to a CANgineBerry, the script accesses detected devices, retrieves their details on demand, and presents them in an intuitive display. No matter the platform—Linux, macOS, or Windows—this tool provides rapid access to multiple devices on your CANopen network.

By delegating low-level CANopen management tasks to the CANgineBerry, developers are free to concentrate on higher-level application development. The Python-based GUI makes the configuration and monitoring of CANopen networks easy and gives you instant control over your devices.

This update further reinforces CANgineBerry’s position as more than a CAN bus interface. It remains a robust solution that simplifies CANopen network management, providing both flexibility and user-friendliness for embedded systems developers.

To download the example, go to: https://cangineberry.com/