Embedded systems form the backbone of connected products – from industrial controllers and medical devices to smart home components. With the Cyber Resilience Act (CRA), the EU establishes clear security requirements for all products with digital elements sold on the European market. For embedded systems manufacturers, this means cybersecurity must be considered from development through to end of product life.
Why Embedded Systems Are Particularly Affected by the CRA
Embedded systems are a primary focus of the CRA because they often operate in the field for years, are difficult to update, and are increasingly connected. A controller in an industrial plant typically has a lifespan of 10 to 20 years – a period during which numerous new security vulnerabilities will emerge.
The CRA distinguishes between standard products and critical or important products. Many embedded systems fall into the category of "important products" (Class I or II), particularly when deployed in critical infrastructure, industrial control systems, or safety-relevant applications. This directly affects the required conformity assessment procedure.
For standard products, self-assessment is sufficient. Important products in Class I can also be self-assessed, provided harmonized standards are applied. Class II and critical products require involvement of a notified body.
Technical CRA Requirements for Embedded Devices
The essential security requirements of the CRA affect several technical areas for embedded systems that must be anchored in the architecture.
Secure boot and firmware integrity: The CRA requires products to have mechanisms ensuring software integrity. For embedded systems, this specifically means a secure boot process that ensures only authenticated, unmodified code runs. The entire boot chain – from bootloader through operating system to application – must be cryptographically secured.
Secure update mechanisms: Firmware updates must be transmitted encrypted and signed. The update mechanism must provide rollback protection and ensure a failed update does not render the device unusable. This is particularly challenging for resource-constrained embedded systems, where over-the-air updates place significant demands on storage and bandwidth.
Default passwords and authentication: Products must not ship with identical default passwords. Each device must have a unique initial password or prompt the user to set one during first setup. For embedded systems without a user interface, alternative authentication mechanisms must be implemented – such as certificate-based authentication.
Data protection and secure communication: All stored and transmitted data must be appropriately protected. For communication between embedded systems, this means TLS 1.2 or higher for network connections, encrypted storage of sensitive data, and protection of cryptographic keys – ideally in a Hardware Security Module (HSM) or Trusted Execution Environment (TEE).
SBOM Requirements for Embedded Systems
Creating an SBOM for embedded systems is particularly demanding. Beyond typical software components, you must document firmware blobs from chip manufacturers, proprietary drivers, and real-time operating systems.
The challenge often lies with third-party components: if you source a WiFi module or Bluetooth stack as a binary, you depend on your supplier providing the corresponding SBOM data. Begin early to incorporate these requirements into your supplier contracts.
For CRA compliance, the SBOM must cover all components contained in the shipped product – regardless of whether they are open-source or proprietary software. The SBOM must be updated with each firmware version.
Deadlines and Transition Periods
The CRA regulation was published in the Official Journal in November 2024. For embedded systems manufacturers, these are the key deadlines: From September 2026, the obligation to report actively exploited vulnerabilities takes effect. From December 2027, all newly placed products must be fully CRA-compliant.
For products already on the market: if an existing product undergoes substantial modification (e.g., a major firmware update affecting the security architecture), it must meet CRA requirements. Pure bugfixes and minor updates do not trigger a reassessment.
Given the typical development cycles for embedded systems – often 12 to 24 months – manufacturers should begin implementation now if they plan to bring new products to market from late 2027 onwards.
Practical Implementation: How to Get Started
The most efficient approach for CRA implementation with embedded systems is a phased process. Start with a gap analysis: Where does your current product stand relative to CRA requirements? Which security mechanisms are already in place, and which are missing?
Then prioritize measures by effort and risk. Typically, the largest gaps are in SBOM documentation, vulnerability management, and update mechanisms. Secure boot is already supported in hardware on many modern microcontrollers and only needs to be enabled and configured.
Document everything from the start. Technical documentation is a central component of CRA compliance and encompasses the security architecture, risk analysis, SBOM management, and vulnerability handling processes.
Kunnus supports embedded systems manufacturers in structuring and automating the entire CRA compliance process – from SBOM management through vulnerability monitoring to documentation.
Start now with our free CRA readiness assessment and find out in just a few minutes where your organization stands and what concrete steps come next.