EU Cyber Resilience Act for embedded systems
Embedded products, compliant from first release to last update.
From a bootloader sold on its own to the finished device, two things set the workload of every embedded variant under the Cyber Resilience Act: its product class and the length of its support period.
Last reviewed:
- Applies in full
- 11 December 2027
- Early warning
- 24 hours · Art. 14(2)(a)
- Support period
- at least 5 years · Art. 13(8)
- Most common class here
- Default product
How long must manufacturers provide security updates for embedded products?
Under Article 13(8) of the Cyber Resilience Act, manufacturers of embedded products set a support period that reflects how long the product is expected to be in use, and that period is at least five years. Only a product expected to be in use for under five years may get a shorter one. According to the EU Commission guidance (C(2026) 5252, section 5), a substantial modification does not automatically reset the support period. Each security update stays available for at least ten years after release, or until the support period ends if that is later (Art. 13(9) EU CRA).
Product classes
Which embedded products fall under the EU CRA, and in which class?
The Cyber Resilience Act covers any embedded product whose intended use includes a direct or indirect, logical or physical data connection to a device or network (Art. 2(1)); a USB port counts. The class follows the core functionality of the product you place on the market, not where it ends up being used (Art. 7(1)). The mapping is our assessment based on typical core functions.
Spread in this sector
Pick a product
Sensor or actuator firmware without a security function
Why this class
No Annex III or IV category; self-assessment under Art. 32(1) EU CRA (module A).
Conformity route
- 1Risk assessment
- 2Self-assessment (module A)
- EU declaration of conformity + CE
Self-assessment by the manufacturer, Art. 32(1) EU CRA.
An assessment based on typical core functions. Your product's intended purpose and design decide.
All product examples as a table+
| Product | EU CRA class | Why |
|---|---|---|
| Sensor or actuator firmware without a security function | Default product | No Annex III or IV category; self-assessment under Art. 32(1) EU CRA (module A). |
| Motor controller or HMI panel with an Ethernet or USB port | Default product | The data connection brings the device into scope; Annex III does not list it. Product page → |
| Data logger or edge device without a routing core function | Default product | No category in Annex III or IV. |
| Battery management system with CAN or Bluetooth interface | Default product | No category in Annex III or IV. |
| Single-board computer or embedded PC | Default product | No category; its operating system is only class I item 11 when sold as a product of its own. |
| Microcontroller without security-related functionalities | Default product | Under Implementing Regulation (EU) 2025/2392, item 14 requires functions that secure other products, networks or services. Secure boot, a TEE or crypto functions that protect other parts already qualify. |
| Boot manager, RTOS or embedded Linux distribution sold on its own | Important product, class I (Annex III) | Annex III, class I, point 8 (boot managers) and point 11 (operating systems). |
| Microcontrollers, microprocessors, ASICs and FPGAs with security-related functionalities | Important product, class I (Annex III) | Annex III, class I, points 13, 14 and 15. |
| Embedded gateway with a routing core function, network or radio module | Important product, class I (Annex III) | Routers, point 12; physical network interfaces including Wi-Fi and Bluetooth modules, point 10 (Implementing Regulation (EU) 2025/2392). |
| Tamper-resistant microcontrollers and microprocessors | Important product, class II (Annex III) | Annex III, class II, points 3 and 4; assessment with a notified body under Art. 32(3) EU CRA. |
| Embedded hypervisor, firewall or IDS appliance | Important product, class II (Annex III) | Annex III, class II, points 1 and 2. |
| Secure element, smartcard controller or hardware security module (HSM) | Critical product (Annex IV) | Annex IV, point 3 (secure elements) or point 1 (HSMs as hardware devices with security boxes, Implementing Regulation (EU) 2025/2392); procedure under Art. 32(4) EU CRA. |
Your product isn't listed? The maturity assessment gives a first classification for your own product. Start the EU CRA assessment →
Outside the Cyber Resilience Act: spare parts that replace identical components and are made to the same specification (Art. 2(6)), and products developed exclusively for national security or defence (Art. 2(7)). Corrected on 9 November 2026: this table listed hardware security modules under Annex IV, point 2. Implementing Regulation (EU) 2025/2392 places them in point 1, hardware devices with security boxes.
Obligations
What the Cyber Resilience Act asks of embedded manufacturers
Six obligations start with a firmware product's first release and stay with it through the support period; record-keeping can run on past it.
- 01
An inventory of every component
Bootloader, RTOS or kernel, crypto and network libraries and the chip vendor's SDK are the components a firmware inventory typically covers. Annex I Part II(1) EU CRA asks manufacturers to identify and document components and vulnerabilities, including in a software bill of materials (SBOM) in a commonly used, machine-readable format that covers at least the top-level dependencies. Because each build can pull in different versions, keeping one SBOM per release is common practice.
- 02
Patched until support ends
Art. 13(8) EU CRA; Annex I Part II(2) and (8)
Security fixes reach users free of charge (Annex I Part II(8) EU CRA) and, where technically feasible, separately from new features (point 2). The duty behind them runs for the whole support period: the manufacturer addresses vulnerabilities in the product and its components without delay, usually through a security update (Art. 13(8)).
- 03
Trustworthy update delivery
Signed images, A/B partitions and protection against rollback to older builds are common state-of-the-art choices; the Cyber Resilience Act itself prescribes no technique. Annex I Part II(7) requires mechanisms that distribute updates securely, so vulnerabilities are fixed or mitigated in time, automatically where appropriate for security updates.
- 04
Vetting code you didn't write
Art. 13(5) and (6) EU CRA
Art. 13(5) EU CRA requires due diligence whenever a manufacturer integrates third-party components, including binary blobs from a chip SDK and open-source libraries such as mbedTLS or lwIP, so that none of them compromises the product's cybersecurity. Art. 13(6) adds a duty to report any vulnerability found in such a component to the party that makes or maintains it.
- 05
The 24-hour clock
Art. 14(2)(a) of the Cyber Resilience Act took effect on 11 September 2026 and gives the manufacturer 24 hours from becoming aware of an actively exploited vulnerability to send an early warning to the coordinating CSIRT and ENISA. Point (b) sets 72 hours for the fuller notification.
- 06
Records kept for a decade
For at least ten years after the product is placed on the market, or for the support period if that runs longer, the manufacturer keeps the technical documentation and the EU declaration of conformity available to market surveillance authorities (Art. 13(13) EU CRA).
Related regulation
How the EU CRA sits alongside other rules for embedded products
For embedded systems, the end product often decides whether the Cyber Resilience Act applies at all.
Medical devices, Regulations (EU) 2017/745 and 2017/746
The EU CRA excludes products covered by these regulations, so firmware in a medical or in vitro diagnostic device falls outside it (Art. 2(2)(a) and (b) EU CRA).
Vehicles, Regulation (EU) 2019/2144
ECUs in vehicles subject to the type-approval regulation sit outside the Cyber Resilience Act (Art. 2(2)(c) EU CRA).
Aviation and marine equipment
Art. 2(3) EU CRA carves out products certified under Regulation (EU) 2018/1139; Art. 2(4) does the same for equipment under the Marine Equipment Directive 2014/90/EU.
Machinery Regulation (EU) 2023/1230
Machinery gets no carve-out in Art. 2 EU CRA. A machine with an embedded controller therefore has to satisfy both regulations.
Radio Equipment Directive 2014/53/EU, Delegated Regulation (EU) 2022/30
Recital 30 EU CRA states that the essential cybersecurity requirements of the Cyber Resilience Act cover every element of Art. 3(3)(d), (e) and (f) of the Radio Equipment Directive, which makes the EU CRA the yardstick for radio-module cybersecurity.
AI Act, Regulation (EU) 2024/1689
Under Art. 12(1) EU CRA, a high-risk edge AI module that meets Annex I, with the EU declaration of conformity showing it, is deemed to meet the cybersecurity requirements of Art. 15 AI Act.
IEC 62443-4-1 and -4-2
Useful for implementation, but a presumption of conformity under Art. 27(1) EU CRA comes only from harmonised standards referenced in the Official Journal.
In practice
Where embedded compliance stalls
One stack, many products
The bootloader, RTOS, TLS library and chip SDK run in many variants at once. A new CVE in the shared library hits every one of them, and for each variant someone has to be able to show which firmware build contains the fix.
Components that arrive as binaries
Chip vendors often ship radio stacks, drivers and crypto accelerators as binaries only. The SBOM and the due diligence under Art. 13(5) EU CRA both depend on knowing the name, version and origin of each one.
The device outlives the SDK
If a chip vendor stops maintaining its SDK while the device is still in the field, upstream fixes dry up. Art. 13(8) EU CRA allows the support periods of bought-in core components to be taken into account when a manufacturer sets its own, and that reasoning goes into the technical documentation.
Installed base with no update path
Older devices without a secure update channel cannot simply be patched. If a vulnerability in one of them is actively exploited, containment and reporting are what is left, and both work better when the procedure exists before the incident.
With Kunnus
How Kunnus supports embedded manufacturers
Kunnus covers the Cyber Resilience Act layer of conformity: classification, SBOMs, vulnerabilities, reporting and technical documentation. Machinery, radio and EMC requirements stay in your existing CE process.
Worked example
How do manufacturers handle EU CRA compliance across many embedded product variants?
The EU Commission guidance (C(2026) 5252, section 7.4) lets variants that share architecture, security-relevant design, intended purpose and risk exposure use one risk assessment, one technical documentation set and one EU declaration of conformity. Variants that differ in components, configurations or enabled functionality, on the other hand, count as distinct products (section 2.1). Grouping variants by security-relevant differences and maintaining the shared stack once is therefore the cost-effective route under the Cyber Resilience Act.
- 1Portfolio1 microcontroller platform, 12 variants: 3 radio options (Wi-Fi, LTE-M, no radio) × 2 memory sizes × 2 brands
- 2Groups3, split by radio interface. Per the EU Commission guidance (section 7.4), memory size and branding do not separate variants; differing communication interfaces do.
- 3Firmware builds12 variants × 3 releases a year = 36 builds with their own SBOM per year, 180 over a 5-year support period (Art. 13(8) EU CRA)
- 4Shared stackBootloader, RTOS, TLS library, network stack and chip SDK in all 12 variants
- 5One CVE in the TLS libraryhits 12 products at once; assessment, fix and, where needed, reporting under Art. 14 EU CRA run for all of them in parallel
- 6What you maintain1 stack, 3 risk assessments and documentation sets, 12 clearly identified variants in the declarations of conformity
Illustrative figures, not market data. Whether variants may share documentation depends on whether their differences are relevant to cybersecurity (EU Commission guidance, section 7.4).
Products
Which products from this sector have their own page?
Frequently asked questions
Is firmware a product with digital elements if it only ships inside the hardware?+
Firmware that ships on the device is part of the hardware product and is assessed with it. Article 3(1) of the Cyber Resilience Act defines a product with digital elements as a software or hardware product, including components placed on the market separately. Firmware sold on its own, such as a licensed RTOS or a commercial bootloader, is therefore a product in its own right. As an operating system or boot manager, it also appears in Annex III Class I (points 11 and 8).
Does using a Class I microcontroller make my product a Class I product?+
A microcontroller with security-related functionalities is listed in Annex III Class I, point 14 of the Cyber Resilience Act. Building it into a device does not by itself make that device an important product: Art. 7(1), second sentence, states that integration alone does not trigger the procedures of Art. 32(2) or (3). What counts is the core functionality of the end product. If the end product is itself a router or a boot manager, its own class applies.
What if a vulnerability can only be fixed in hardware?+
Annex I Part II(2) EU CRA requires vulnerabilities to be addressed and remediated without delay, and point 7 speaks of vulnerabilities being fixed or mitigated. Where a flaw in silicon cannot be closed in firmware, our reading is that mitigation is the route: disabling a service or changing a configuration, with the risk assessment updated under Art. 13(7). A manufacturer that develops a hardware change shares the relevant documentation with the maker of the component, as Art. 13(6) provides.
We sell a mini PC with preinstalled Linux under our own brand. Are we the manufacturer?+
If you market the mini PC under your own name or trademark, you fit the manufacturer definition in Art. 3(13) of the Cyber Resilience Act, and Art. 21 says the same for importers and distributors who place a product on the market under their own brand. The obligations of Articles 13 and 14 then apply, including an SBOM for the shipped image and security updates for the Linux distribution you preinstall.
Does the EU CRA require a certified compiler or toolchain?+
The Cyber Resilience Act does not name a certified compiler, toolchain or build system. Annex I sets outcomes: products are designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks (Annex I Part I(1)), and the manufacturer documents how. A qualified toolchain from functional-safety work can count as evidence in the risk assessment. In our reading of the text it is neither required nor enough on its own.
Do spare boards and devices already in the field fall under the EU CRA?+
Spare parts that replace identical components and are made to the same specification are excluded under Art. 2(6) of the Cyber Resilience Act; per the EU Commission guidance (section 4.1), identical means identical security-relevant characteristics. Devices placed on the market before 11 December 2027 only have to meet the requirements after a substantial modification (Art. 69(2)). Reporting under Art. 14 is the exception: since it took effect on 11 September 2026, Art. 69(3) has applied it to these devices as well.
Which class do your embedded products fall into?
The EU CRA assessment gives you a first estimate of class, obligations and next steps for your portfolio in a few minutes.
Further reading
Other sectors
EU CRA compliance in other industries
Source: Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal of the EU. https://eur-lex.europa.eu/eli/reg/2024/2847/oj
This page is an orientation on the Cyber Resilience Act for this sector, not legal advice. Whether and how the regulation applies to a specific product depends on its intended purpose and design.