Cyber Resilience Act: what actually changes for an embedded product
Regulation (EU) 2024/2847, the Cyber Resilience Act, is not a set of good-practice recommendations. It is a directly applicable regulation, tied to CE marking. Its Article 64 provides, for non-compliance with the essential requirements of Annex I and the obligations of Articles 13 and 14, administrative fines of up to EUR 15 000 000 or 2.5% of total worldwide annual turnover, whichever is higher. For a manufacturer of embedded products it turns security from a selling point into a condition for placing the product on the market.
The real deadlines
Three dates matter, and two are already here or close.
10 December 2024: entry into force, twenty days after publication in the Official Journal. Nothing enforceable yet.
11 September 2026: the reporting obligations start to apply. This is the first operational constraint, and it is routinely underestimated because it lands more than two years before the rest.
11 December 2027: full application. Any product with digital elements placed on the market after that date must comply.
The part that catches teams out: the CRA applies to the product placed on the market, not the product designed. Firmware written in 2025 and sold in 2028 is in scope. Architecture decisions taken today, in particular picking an SoC with no secure boot or no OTP memory for keys, commit you to 2028 compliance.
The three classes, and why yours matters
The regulation classifies products by criticality, and the class decides who assesses conformity.
Default products, the vast majority: self-assessment. The manufacturer applies the requirements, assembles the technical documentation and affixes the CE marking itself.
Class I (Annex III), which covers password managers, operating systems, microprocessors and microcontrollers with security-related functionalities, routers, VPNs: self-assessment is possible only if harmonised standards are applied in full. Otherwise, a notified body is required.
Class II, the most critical, covering hypervisors, industrial firewalls and hardware secure elements among others: notified body mandatory.
The line about "microcontrollers with security-related functionalities" deserves careful reading. An STM32 with TrustZone, a secure element, or a communication module with an embedded TLS stack can move a product into that class depending on its role. This classification changes the whole timeline and cost of compliance, so it is the first thing to settle.
Annex I requirements, translated into firmware decisions
Annex I, Part I lists the essential requirements. Here is what they mean in code rather than in a document.
Shipped with no known exploitable vulnerability. Impossible to guarantee without knowing what you ship: it presupposes a software bill of materials and automated CVE monitoring on third-party components, which is exactly what an SBOM is for.
Secure by default configuration. No identical default password across a production run. No debug port left open. No network service enabled without a reason. Concretely this means disabling JTAG or SWD in production, which is irreversible on many microcontrollers and therefore has to be decided before manufacturing.
Protection from unauthorised access, and integrity. That is secure boot, with signature verification at every stage, and key storage that cannot be recovered by simply dumping the flash.
Confidentiality and data minimisation. Encryption at rest and in transit, and above all collecting only what the function requires.
Security updates, free of charge and where possible automatic. The regulation requires an update mechanism. A product whose firmware cannot be replaced in the field is, in effect, non-compliant.
Access logging and monitoring. The product must be able to record security-relevant events, which implies persistent storage and a rotation policy.
The support period, the most structural constraint
The manufacturer must provide security updates for the expected product lifetime, with a minimum of five years, unless the lifetime is clearly shorter.
Five years of security patches, for embedded firmware, is not an administrative clause. It is an engineering constraint that reaches back to the choice of silicon and software stack. You must be able to rebuild, re-sign and redeploy firmware five years later, which means freezing a reproducible toolchain, archiving the sources of every dependency, and keeping the signing keys usable.
It is also what makes a layered build system, with source archiving and licence manifests, considerably more comfortable than a hand-patched tree.
The 24-hour reporting duty
This is the most operational obligation, and it starts in September 2026.
For an actively exploited vulnerability or a severe incident affecting product security, the manufacturer must send an early warning to ENISA and the relevant CSIRT within 24 hours of becoming aware of it. Then a notification within 72 hours. The final report is due no later than 14 days after a corrective or mitigating measure is available for a vulnerability, and within one month of the 72-hour notification for a severe incident.
Twenty-four hours implies an on-call rota, a channel to receive reports, and a written procedure that does not depend on one person. That is a process to put in place, not a line of code.
What to decide now
| Decision | Why now |
|---|---|
| Product class (default, I or II) | Decides whether a notified body is needed, so the whole timeline |
| SoC with secure boot and key storage | Cannot be retrofitted once the silicon is chosen |
| Field update mechanism | Without it, compliance is impossible |
| SBOM generation in the build | Prerequisite for CVE monitoring and the technical file |
| Reproducible builds over five years | The condition for being able to patch at all |
| 24-hour reporting procedure | Enforceable from September 2026 |
The classic trap is treating the CRA as a documentation exercise to open in 2027. The first four rows of that table are hardware and software architecture decisions: taking them late means rebuilding the product.
References
- Regulation (EU) 2024/2847, full text on EUR-Lex
- European Commission, Cyber Resilience Act, application dates
- European Commission, summary of the legislative text, 24 h, 72 h, 14 day and one month reporting deadlines
- Article 64 of the Regulation, administrative fines
Going further
These requirements become concrete when translated into a technical file and implementation choices, product by product. That is the subject of our dedicated Cyber Resilience Act course, and of our courses on developing secure embedded systems.