A distributor emails asking for your declaration of conformity. It goes to sales, who forward it to the product manager, who forwards it to engineering, where it stops. The device has shipped for four years. The firmware builds on one engineer’s machine. Nobody has an inventory of what is in it, the update mechanism was scoped out of v1 to hit a launch date, and the person who wrote the bootloader left in 2023.
None of that was negligent. It was normal, and it was fine right up until the moment somebody in the value chain needed an answer in writing.
The EU Cyber Resilience Act is what changed that. It is a market-access regulation, not a security best-practice guide: products with digital elements sold into the EU have to meet its requirements, and the obligations sit on the manufacturer across the life of the product rather than on a certificate issued once.
This article is about the engineering consequences — what CRA compliance actually changes about how firmware is built, updated and documented, and how to judge whether your own team can absorb that alongside the roadmap. If you are earlier than that and still working out how the software itself gets built, start with the embedded software development guide.
- The Cyber Resilience Act turns update capability and vulnerability handling from engineering preferences into conditions of selling into the EU, which moves them from the backlog into the architecture.
- Three dates set the schedule: the regulation entered into force on 10 December 2024, reporting obligations begin on 11 September 2026, and the main obligations apply from 11 December 2027.
- The obligations attach to the product lifecycle — planning, design, development and maintenance — not to a document produced at the end, which is why retrofitting is the expensive path.
- The engineering work this creates is concrete: a signed and recoverable update path, a dependency inventory you can regenerate, and a vulnerability process that runs for as long as the product is sold.
- The build-versus-buy question is not whether your engineers can do this. It is whether they can do it while also shipping the roadmap, and for products already in the field as well as the next one.
- Nobody ranking for this regulation today is writing from a device-software engineering position, which tells you how much of the available guidance is legal rather than practical.
What CRA Compliance Actually Means for a Device Maker
The European Commission describes a regulation covering connectable hardware and software — its own examples run from baby monitors and smartwatches to apps and computer programs — and it places the obligation on manufacturers to address cybersecurity through the planning, design, development and maintenance of the product, and to handle vulnerabilities across its lifecycle. Products carry CE marking to show conformity, and higher-risk categories require third-party assessment by a notified body before they can be sold.
Read that as an engineer rather than as a lawyer and three things follow.
It attaches to the process, not to the release. “Planning, design, development and maintenance” is the whole lifecycle. A conformity exercise run in the last sprint before launch can describe a process; it cannot create one retroactively.
It continues after shipment. Handling vulnerabilities across the lifecycle means the obligation is still live on a product you sold three years ago. That is the requirement most likely to be underestimated, because it converts a one-time project cost into a standing operational one.
It applies to what you sell, including what you did not write. A device is mostly other people’s code — an RTOS, a TCP/IP stack, a crypto library, a vendor BSP, a dozen open-source components pulled in by the build. The obligation to handle vulnerabilities does not distinguish between the code you authored and the code you shipped.
The Three Dates That Set Your Schedule
The middle date is the one that catches teams out. Reporting arrives more than a year before the main obligations, and reporting is not a documentation task — you cannot report an actively exploited vulnerability in your product unless something is watching for it, someone owns the decision, and there is a path to ship the fix. In practice the September date requires the machinery that the December 2027 date formally demands.
Working backwards from a product on a two-year hardware cycle, the architecture decisions that make this affordable are being made now, in the design of whatever you started this year.
What the September Clock Actually Requires
The reporting obligation is not open-ended. The European Commission publishes the deadlines, and they are short enough that no team improvises them on the day.
Read that as a monitoring specification rather than a reporting one. The 24-hour clock starts the moment someone becomes aware, so everything upstream of that moment — dependency watch, triage, and a named owner who can decide — determines whether the deadline is reachable at all. Source: the European Commission’s CRA reporting page, current as at 31 August 2026.
The Cyber Resilience Act Requirements That Change Your Firmware
Four things move from “we should” to “we must”, and each one is an architecture decision rather than a feature.
A Signed Update Path That Can Fail Safely
An obligation to handle vulnerabilities over a product’s lifetime is an obligation to be able to ship a fix, which means the firmware over the air update mechanism stops being optional. The engineering content is specific: secure boot so the device will only run firmware you signed, integrity validation on the image, and rollback protection so a half-applied update on a device in a customer’s basement leaves a working product rather than a brick. Products already in the field without this are the hard case, because the update mechanism itself has to arrive through a channel that does not yet exist.
An Inventory of What You Actually Ship
Handling vulnerabilities in components you did not write requires knowing which components you shipped, in which version, in which firmware image, on which units. Most teams can reconstruct this with a week of effort and cannot regenerate it on demand — which is the difference that matters, because a vulnerability disclosure in a widely used library is a question you answer in hours, repeatedly, for years. The practical test is whether your build produces that inventory automatically or whether a person assembles it.
Vulnerability Handling as a Running Process
Somebody has to be watching disclosure feeds against your component list, triaging what applies to your product, and deciding what ships and when. This is the obligation that most changes the shape of an engineering team, because it is continuous and it competes directly with roadmap work. It is also the one where the honest answer for a lot of product companies is that no such process exists today.
Documentation That Survives the People Who Wrote It
Conformity rests on being able to show how the product was designed, what was assessed, and what was decided. That is a different artifact from an architecture diagram drawn once — it is documentation kept current alongside the code, which is a discipline rather than a deliverable. Embedded software security work has a habit of living in the heads of two people; this requirement is what forces it out of them.
Which Products Are In Scope, and Who Carries the Obligation
The scope is broader than most hardware teams assume on first reading. It is not limited to products marketed as security devices, and it is not limited to consumer goods — the test is whether the product has digital elements and can connect, which covers most of what an industrial, medical or consumer device maker currently ships.
The obligation sits with the manufacturer. That matters for two situations that come up constantly:
- You had the firmware built by someone else. The obligation is still yours. A development contract that ends at delivery leaves you carrying a lifecycle duty with no engineering capacity attached to it, which is a scoping question to settle before the contract, not after.
- You sell into the EU through a distributor. The requirements must be met across the value chain, so the request eventually arrives at your engineering team regardless of who sold the unit.
For higher-risk product categories, third-party assessment by a notified body is required before sale, which adds an external dependency with its own lead time to a schedule that already has hardware in it.
Can Your Team Absorb This In-House?
This is the real question, and it is not a question about competence. Most embedded teams can build secure boot and an update path; many have already built both. The question is capacity and continuity, and it resolves into four honest checks.
Can you regenerate your component inventory today, on demand? If the answer involves a person and a spreadsheet, the gap is tooling, and tooling is the cheapest of the four gaps to close.
Does a fielded product have a working update path? If not, the work is not compliance work — it is a firmware project with a bootloader change, a signing infrastructure and a rollout plan, and it needs to be scheduled as one.
Who is on the hook when a disclosure lands on a Friday? A named person with the authority to ship, or nobody. This is an operating-model question that engineering leadership cannot answer alone.
What comes off the roadmap? The work is real and it is recurring. A plan that assumes it will be absorbed without displacing anything is a plan that will quietly not happen.
Where teams choose to bring in help, it is usually for the second and third of those: a discrete project to build the update and signing path into an existing product, and a process someone else runs until it is routine. Where the answer is to hire or to partner more broadly, the top embedded software development companies roundup compares eleven firms on the capability each one actually publishes, including which of them name secure boot, OTA and long-term maintenance as their own work rather than as a client’s problem.
What This Costs, and Where the Cost Actually Lands
There is no single number, and the ranges circulating in vendor marketing are not sourced well enough to repeat. What is predictable is where the cost concentrates, which is more useful when you are building a business case.
Retrofit is the expensive category, by a wide margin. Adding a signed update path to a product designed without one touches the bootloader, the memory map, the manufacturing process and the field rollout. Building it into a product now costs a fraction of that.
The recurring cost is the one that gets missed. Monitoring, triage and patch releases continue for as long as the product is sold and supported. A business case that prices only the first project understates the commitment, and it is the recurring line that determines whether this is absorbed or resourced.
Fleet fragmentation multiplies everything. Four hardware revisions and three firmware branches means every fix is four or more releases. Consolidating variants is often the single most useful thing a team can do before the obligations bite, and it is a pure engineering exercise with no regulatory content at all.
Documentation is cheap when it is continuous and expensive when it is archaeological. Kept alongside the code it is a small tax per change. Reconstructed after the fact, on a codebase whose authors have left, it is a project.
Where Crunch-IS Fits
Our firmware development services build bootloaders and field-update mechanisms with secure boot verification, rollback protection and integrity validation as standard, and scope hardening — encrypted communications, secure storage, access control, attack surface reduction — from the architecture stage rather than after the product works. That is the same set of decisions this regulation now makes non-optional, which is why the work is more often a firmware project than a compliance project.
The other half of it is release discipline, because an obligation to ship fixes reliably is an obligation to have a release process that does not itself break things. On a telecom network management system, rebuilding around cleaner boundaries and a disciplined release process cut deployment-related issues by 60% and improved system uptime and reliability by 50% — the same capability, measured on a different problem.
Conclusion
The Cyber Resilience Act does not ask device makers to do anything the better embedded teams were not already arguing for. What it changes is that update capability, dependency visibility and a running vulnerability process are now conditions of selling rather than things to fund next year — and that the products already in the field are in scope alongside the next one.
The two decisions worth making now are architectural: design the update path into whatever you start this year, and make your component inventory something the build produces rather than something a person assembles. Both are cheaper now than at any later point, and neither requires the regulation to be fully settled before you act.
