The EU Cyber Resilience Act for Hardware Makers
For most of the history of connected products, shipping something insecure carried no direct legal penalty. The EU Cyber Resilience Act ends that. It makes security a condition of putting a product with digital elements on the European market, backed by real fines and the power to pull a product from sale. If you build hardware that connects to anything, this is the regulation that will reshape how you plan a release.
What the CRA Actually Covers
The scope is deliberately broad. The CRA applies to any product with digital elements made available in the EU, which means almost anything with software that can connect directly or indirectly to a device or network. A smart sensor, a router, a medical wearable, an industrial gateway, the firmware inside them, and the companion app all fall in scope. There are carve-outs for products already covered by sector rules such as medical devices and cars, but for the vast majority of embedded products, the default assumption should be that the CRA applies.
It reaches you wherever you sit in the chain. Manufacturers carry the heaviest obligations, but importers and distributors have duties too, and a company that substantially modifies a product can inherit the manufacturer’s responsibilities. Selling into the EU from outside it does not exempt you; it just means an EU-based economic operator has to stand behind the product.
The Essential Requirements, in Engineering Terms
Strip away the legal language and the CRA’s core is a list of security properties your product has to have. Ship with a secure configuration by default. Do not ship known-exploitable vulnerabilities. Protect confidentiality and integrity of data and commands, usually meaning real cryptography and authenticated interfaces. Minimize attack surface. Provide security updates, and make them deliverable to the field. Log security-relevant events. None of this is exotic to anyone who has done embedded security work; the change is that it is now mandatory rather than aspirational.
The requirement that catches teams off guard is vulnerability handling across the whole support period. You have to identify and document vulnerabilities, which in practice requires a software bill of materials; ship free security updates for the defined support period; and have a coordinated disclosure policy so outside researchers can report to you. A device you built to be sealed and forgotten no longer fits the law.
| Obligation | What it means on the bench | Where teams get caught |
|---|---|---|
| Secure by default | Ship locked down, no universal passwords | Debug interfaces and default creds left enabled |
| No known vulns at ship | Track and patch components before release | No SBOM, so unknown what is inside |
| Security updates | Signed, deliverable OTA for the support period | No update path designed in |
| Incident reporting | 24h / 72h / final to CSIRT and ENISA | No one authorized to hit send in time |
Two Deadlines You Report On
Beyond the product requirements, the CRA imposes hard reporting timelines once you are in the market. An actively exploited vulnerability or a severe incident triggers an early-warning notification to your national CSIRT and ENISA within 24 hours, followed by a fuller notification within 72 hours, and a final report later. These are not annual-summary obligations; they are same-day and same-week duties that your incident process has to be built to meet.
Meeting a 24-hour clock is an organizational problem more than a technical one. It means someone is on the hook to recognize an exploited vulnerability, someone can authorize a report, and the contact paths to the CSIRT are known before the incident rather than discovered during it.
The Timeline You Are Actually On
The CRA entered into force in 2024, but its obligations phase in. The vulnerability and incident reporting duties apply first, and the full set of manufacturer obligations applies from 2027. That sounds distant until you count backward through a hardware program. A product you are architecting now will still be on sale then, and retrofitting an update mechanism, a secure boot chain, or a disclosure process into a shipped device is far more expensive than designing it in.
Conformity is self-assessed for most products, meaning you declare compliance and carry the technical documentation to back it, with third-party assessment reserved for the higher-risk classes. Self-assessment is not a loophole; it means the evidence has to exist and be defensible if a market surveillance authority asks.
What to Do Before It Bites
The practical starting move is to find out what you are actually shipping. Build a software bill of materials for your firmware so you know which third-party components and versions are inside and can react when one of them gets a CVE. From there, make sure every product in development has a secure update path, a sane default configuration, and an owner for incoming vulnerability reports. Those three things carry most of the weight.
This is exactly the kind of gap a focused assessment surfaces early, while it is still cheap to fix. A product security assessment or threat model against the CRA’s essential requirements will tell you where a given device falls short and what it takes to close the gap, long before a market surveillance authority or a customer’s procurement team asks the same question.
