Cyber Resilience Act Embedded Software Article Series

The Cyber Resilience Act (CRA), adopted by the EU Council in October 2024, defines binding cybersecurity requirements for digital products for the first time and directly links them to the CE marking. The Cyber Resilience Act thus has for manufacturers of Embedded Software and Embedded Systems have a structural change ready: Cybersecurity is no longer an optional component, but a prerequisite for market access. Products with software components – particularly firmware-driven systems on microcontrollers and microprocessors – will in the future have to demonstrate that security requirements have been considered throughout their entire lifecycle. This article explains how the Cyber Resilience Act changes embedded software.

The CRA does not address isolated IT systems, but rather physical devices with integrated software – in other words, classic embedded designs. Compliance with these requirements will become mandatory starting October 2026. This leaves manufacturers with a limited two-year window to adapt development processes, architectural decisions, and security concepts to demonstrably ensure both software integrity and system resilience against attacks. The EU Council's press release on the Cyber Resilience Act is at the following link to find.

For manufacturers of electronics and embedded systems, this means they will have to adapt their development and production processes over the next two years to integrate the new security standards. Previously, the CE marking primarily referred to physical safety aspects, such as electrical safety or health harmlessness. The CRA adds new requirements to ensure that digital products containing software and hardware components are also protected against cyberattacks. In the future, manufacturers will also have to prove that they have taken measures to ensure IT security before they can affix the CE mark. This last point often primarily concerns the IT and OT of companies, and many companies have already become active in this area in recent years.

Peculiarities of Embedded Systems

Embedded systems are function-bound computing units that perform specific tasks within an overall technical system, typically in the form of microcontroller or microprocessor-based architectures – either as a bare-metal implementation or based on a RTOS. Their behavior is designed to be deterministic, as they often take on time-critical control and regulation functions. In networked use, for example via CAN, Ethernet, or industrial fieldbuses, they become part of complex system landscapes and thus also potentially vulnerable.

This results in a close coupling of functional safety (safety) and Cyber Security (Security): While safety ensures that the system assumes defined states even in the event of errors, security addresses targeted external manipulation. Since embedded systems interact directly with physical processes, successful attacks or malfunctions can cause real-world damage—from system failures to critical endangerment of people and infrastructure. Accordingly, the focus is on controllable system behavior, robust architecture, and the security of all relevant interfaces.

In the Cyber Resilience Act Annex III specifically lists product categories that are classified as safety-relevant and are therefore subject to stricter requirements. These include:

• Network interfaces
• Firewalls
• Microcontroller

and additionally:

• CPUs
• „Secure Elements“
• Operating Systems
• Industrial Firewalls

These components form central building blocks of networked systems and are particularly relevant for cybersecurity and system integrity due to their function.

Cyber Resilience Act for Electronics in Products and Devices

First things first: Manufacturers of devices based on microcontrollers and microprocessors must do something! The Cyber Resilience Act and embedded software are usually strongly related. Even more so: The Cyber Resilience Act will significantly shape embedded software and the related architecture.

TARA and STRIDE

A central initial framework for action is the implementation of a Threat and Risk Assessment (TARA), to identify and assess potential security vulnerabilities. Manufacturers must assess which attacks and exploits can occur on the device, regardless of the attacker's motives. The focus is on programmable hardware and on-board communication interfaces.

Manufacturers often lack a measure for the structured analysis of attack scenarios. However, many IT security methods can also be applied to electronics, partly with some compromises. For example, the classification of attack scenarios, for instance by the STRIDE– method. This covers typical threats such as spoofing, tampering (Tampering), repudiation, information disclosure, denial-of-service attacks, and unauthorized privilege escalation. 

Protective measures as a function of impact

The protective measures are individual per device and should be balanced, taking into account Engineering Costs and the possible impacts (single device / many devices / all devices) are made. Nevertheless, there are must-haves for manufacturers of devices with electronics and embedded systems that every R&D department should reasonably have on its agenda in the coming years.

The Four Pillars of Cyber Resilience in Embedded Systems

Embedded systems are present in practically all commercially available products, such as industrial sensors, control technology, or camera systems. Even household appliances like washing machines and fully automatic coffee machines incorporate microcontroller-based controls. This places practically all distributors and manufacturers of „smarter“ systems under an obligation to implement measures.

The four pillars of secure Embedded Software are the following:

• Zero-Trust Communication
• Anti-Denial-of-Service Measures
• Secure updates
• Key Management

Measures Overview

So how does the Cyber Resilience Act affect embedded software?

Implementing zero-trust communication is an approach to prevent spoofing attacks. Spoofing describes the attempt to inject false identities or fake data in the form of messages into the system. To prevent this, the zero-trust principle is applied, where every communication attempt is fundamentally considered potentially insecure. There are two essential approaches to implement this. The first is the complete encryption of messages, so that only authorized participants can read the communication. The second approach is secure hashing, where unmanipulable cryptographic hashes are created to ensure the integrity of the messages.

Protection against Denial-of-Service (DoS) attacks is particularly problematic with weak threading behavior. DoS attacks aim to render systems inoperable by overwhelming them, which is especially dangerous for embedded systems on critical communication buses such as ModBus, CAN, Profibus, or RS485. An attacker could infiltrate the bus and „flood“ these systems with an overload of data, disabling them. This applies to both secure and insecure attempts. Anti-DoS mechanisms must ensure that such attacks are detected and repelled early on.

Furthermore, systems must have secure mechanisms to receive software updates and ensure that only authorized and intact software is used. In embedded systems, updates are often transmitted unencrypted or without adequate protective measures, which poses a significant risk. Flash images should therefore always be transmitted encrypted to prevent manipulation. Cryptographically relevant functions should be stored in secured TrustZones or encrypted in flash memory. Additionally, a secure boot process ensures that the system only starts from trusted software.

Ultimately, the management of cryptographic keys on the build and device sides is enormously important. These keys are used for data encryption and authentication and must be stored securely on both the device and the development side. On the development side, secure management is carried out, which severely restricts access to the keys. For secure transmission of the keys via bus protocols, encrypted and authenticated mechanisms must be used to ensure that no unauthorized party can access the keys, even in insecure environments.

Summary

The Cyber Resilience Act will change embedded systems in any case. This results in concrete measures on the one hand. On the other hand, cybersecurity for products with digital elements is a continuous development process from requirements, architecture, and implementation to verification, penetration testing, updates, and vulnerability management. The CRA strengthens precisely this lifecycle approach, making TARA, security requirements, and regular re-assessment cycles an integral part of product maintenance.