One misconception is proving stubborn: that the Cyber Resilience Act only concerns manufacturers from late 2027. That holds true for part of the obligations — but not for the first one, and that one is the most uncomfortable. It takes effect already on 11 September 2026. As I write this, that is less than a quarter of a year away.
I do not regard the CRA as bureaucracy for its own sake. It forces an industry that treated security as an optional extra for decades into something that has long been a matter of course in safety-critical fields: proving what you do. Even so, many underestimate how early the clock starts. Hence this article.
What the CRA demands — and from when
The Cyber Resilience Act (Regulation (EU) 2024/2847) has been in force since December 2024. It sets out how secure "products with digital elements" must be against attacks — meaning anything that contains software or connects to a network. From the smart thermostat to the industrial controller. There are two key dates, and they should not be confused:
11 September 2026 — the reporting obligation. From this date I have to report any actively exploited vulnerability and any severe security incident within 24 hours to the relevant bodies — the EU agency ENISA and the national response teams (CSIRTs). This also applies to products that have long been on the market and are still in support.
11 December 2027 — everything else. From then the product must be securely designed from the ground up, receive security updates across its lifetime, present a complete software bill of materials, pass a conformity assessment and carry the CE mark.
Put both dates side by side and the real problem appears: you can only report what you know is in your product. And that leads straight to the underestimated hurdle.
Why the reporting obligation is the real hurdle
Reporting a vulnerability within 24 hours sounds like an organisational detail. It is not. To judge at all whether a newly disclosed flaw affects my own product, I need a complete list of every software component built in — the so-called SBOM (software bill of materials), the parts list for program code. Without it I sit in the dark with every new vulnerability report, guessing whether one of my components is affected.
In other words: the SBOM that officially only becomes mandatory in 2027, I effectively need by September 2026. Whoever starts inventorying their dependencies only then has already lost the first real incident. On top of that comes the plain logistics: who notices an exploited flaw, who assesses it, who reports it — and does that chain work on a Saturday evening too? Twenty-four hours are twenty-four hours.
Reliability and attack resistance are growing together
This is where it gets interesting for my core work. For more than three decades I have developed safety-critical embedded software, much of it to ISO 26262 — the standard for functional safety in vehicles. Functional safety asks: what happens if a component fails? The CRA places a second question beside it: what happens if someone attacks the device on purpose?
These two questions were separate worlds for a long time. They no longer are. A vivid example is the remote intrusion into a Jeep Cherokee in 2015: two security researchers took control of the brakes and transmission through a flaw in the infotainment system — remotely, over the cellular network. 1.4 million vehicles had to be recalled. Every safety case for the brake was worthless, because the brake did not fail at random but on an attacker's command. A flaw in the software had become a safety problem in the literal sense.
This is exactly where the expensive gaps arise today: with manufacturers who have their reliability under control but never looked at the attack side systematically. Anyone thinking ISO 26262 without a flanking security analysis no longer closes their chain of argument.
What concretely changes in the firmware
The CRA is readily dismissed as a lawyers' topic. I consider that a mistake. Behind the requirements lie very concrete tasks for the firmware — the control software that sits permanently inside the device. Four points are central in my view:
The software must be stored encrypted in the device. Anyone who can read the program code out of the flash unencrypted has an open door. Modern microcontrollers offer protection for this — secure read-out locking, signed boot, key-bound memory regions. What matters is managing them cleanly in production as well, instead of losing the keys along the way.
Updates must be tamper-proof. A device must be able to receive security updates across its entire lifetime — and in such a way that no one can inject smuggled-in software. A product without a signed, verified update path is simply no longer marketable from 2027.
Every component must be known and watched. Every bought-in library, every building block of the real-time operating system, every crypto stack belongs in the parts list and must be monitored for known vulnerabilities. That includes recognising outdated components no longer maintained by their original supplier — before an authority does.
Clean code pays off. In safety-critical projects I develop to strict coding rules, such as MISRA-C. Many of those rules eliminate precisely the undefined behaviours from which exploits are later built. Whoever works that way from the start has already done part of the CRA homework — but should be able to prove it, too.
The small manufacturer is a "manufacturer" too
A widespread fallacy holds that this only concerns large corporations. Wrong. The CRA applies to anyone who places a product with digital elements on the EU market — from the mid-sized firm to the specialised solo developer. Whoever imports or resells devices carries their own duties as well. And the fines are no bogeyman: they reach up to 15 million euros or 2.5 percent of worldwide annual turnover.
Anyone who used to think security was an option for "later product versions" no longer has that choice.
What I advise manufacturers now
The coming months decide whether September 2026 finds an orderly procedure in place or hectic improvisation. My advice is unspectacular, but it works: start. Take stock of which products are affected and still supported. A first software bill of materials per product. A defined reporting path that organisationally really carries the 24-hour deadline. And in parallel, harden the firmware — as a considered architecture, not as a patch tacked on afterwards.
An honest self-assessment to close: anyone looking for a stamp certifying that everything is already fine is in the wrong place with me. Anyone who wants to know where their products actually stand in September 2026, and what has to be done in the firmware before then, is in the right place.
Free downloads and resources
I have condensed the most important points into a compact, plainly written PDF — with a checklist to tick off. No registration, no payment required.
Conclusion
The CRA is not a distant problem for the day after tomorrow. The first binding deadline falls in September 2026, and it assumes that I already know today what is inside my products. Whoever starts early spreads the work and avoids expensive last-minute fixes just before the deadline.
The greatest leverage rarely lies in the technology alone. It lies in the clean interplay of parts list, reporting process and device hardening — and in finally thinking of reliability and attack resistance as one shared concept, not as two separate drawers. That is exactly the bridge I most enjoy working on.
Preparing for the CRA, or looking for support?
Whether it is the software bill of materials, the reporting process, secure updates or hardening your firmware — I support your team in implementing the CRA requirements. Initial consultation free of charge.