If you sell a connected product in the EU, the Cyber Resilience Act is now your problem.
The first deadline is close. From 11 September 2026, if someone is actively exploiting a hole in your product, you have 24 hours to raise a flag. The rest of it, where security becomes part of the CE mark itself, starts on 11 December 2027.
We build and certify IoT hardware, so we've been following this one closely. Here's what it actually asks of you, who it applies to, and what's worth doing this year.
What the law is
The CRA is Regulation (EU) 2024/2847. It has been in force since December 2024, and it covers "products with digital elements" — anything with software in it that can connect to a device or a network, directly or through something else.
In practice that means every IoT product. Sensors, trackers, wearables, gateways, and the app and cloud service that ship with them.
The change is simple to state. Security is now a condition for the CE mark, the same way electrical safety and radio behaviour already are. If you can't show it, you can't sell.
The dates
| Date | What applies |
|---|---|
| 10 December 2024 | The CRA entered into force |
| 1 August 2025 | Radio Equipment Directive security rules (Article 3.3 d/e/f). Already mandatory for most wireless IoT devices |
| 11 September 2026 | You must report exploited vulnerabilities and severe incidents |
| 11 December 2027 | Everything else: the requirements themselves, assessment, documentation, CE marking |
Two things in that table catch people out.
Wireless products have had security requirements since August 2025 already, under the Radio Equipment Directive, checked against a standard called EN 18031. So if your device went through RED certification recently, you've done part of what the CRA will ask. If it didn't, you may already be non-compliant today, before the CRA even starts.
The September 2026 reporting duty also covers products that are already out in the field. Nothing is exempt because it shipped earlier. If your device is out there and someone exploits a hole in it, you report it, whenever you launched it.
What September 2026 actually asks
From that date, once you know that a vulnerability in your product is being exploited, or that you've had a serious security incident, you tell ENISA and your national CSIRT through the EU's reporting platform:
- A first warning within 24 hours of finding out
- The full notification within 72 hours, with what you know so far and what you're doing about it
- A final report once it's fixed, within 14 days for an exploited vulnerability or a month for an incident
Those windows are brutal if you've never run a security response before. You need someone whose job it is to watch the clock. You need a way for researchers and customers to reach you, which means at minimum a security.txt file and an inbox somebody actually reads. And you need to know your own firmware well enough to judge a report quickly.
That is work for this year, not next.
What changes in December 2027
From 11 December 2027, putting a product with digital elements on the EU market means meeting the CRA's requirements, going through an assessment, and having the paperwork to prove it. In short:
You design it secure and ship it secure. That means a risk assessment while you're building, no known exploitable holes at launch, a safe configuration out of the box, and data protected both in transit and at rest.
You can deliver security updates separately from feature updates, for a support period you state to your buyers. Five years is the general expectation.
You keep a Software Bill of Materials in your documentation. It's a list of every software component in your product, and the reason it matters is blunt: you can't patch a dependency you can't name.
You have a way to handle vulnerabilities. A disclosure policy, a contact point, and a process for testing and fixing.
Your documentation and CE marking plug into the same framework you already know from RED and EMC. Most ordinary IoT products can assess themselves. Only the "important" and "critical" classes need an outside body.
Products already on the market before that date only fall under the full requirements once you make a substantial modification to them. A big firmware overhaul can count, so "we shipped in 2027" protects you less than it sounds.
Fines go up to €15 million or 2.5% of worldwide turnover. For a small manufacturer the likelier problem is duller: a distributor turns your product away because the paperwork isn't there.
What to do this year
This is the order we recommend to teams we work with.
Start by listing what you're exposed to. Every product with digital elements you sell in the EU, its firmware stack, how it connects. Then decide per product whether it's default, important or critical class.
Generate an SBOM for each one. Modern build tooling like Zephyr, ESP-IDF and Yocto can produce one for you. Getting it accurate is the real job.
Set up the reporting process before you need it. Name an owner, publish a security contact, register on the ENISA platform when it opens, and walk through the 24 and 72 hour flow once as a rehearsal.
Decide your support period, publish it, and check that your OTA setup can actually deliver on it.
Close the RED gap now. If your wireless product hasn't been checked against EN 18031, that's a problem you have today.
Design new products against the CRA from the first sketch. Secure boot, signed updates, a unique password per device, a locked-down default configuration. All of it is cheap at design time and painful to retrofit.
And fold the CRA paperwork into your CE technical file, so certification stays one job instead of two.
Where this meets certification
The CRA runs on the same machinery as the rest of CE marking. That means the way through it is the way you already know: design compliance in early, keep the technical file up to date as you go, and test before the accredited lab does.
That's the model we run for CE and FCC certification. Pre-compliance designed into the PCB and firmware, documentation written during development, lab time booked for when passing is a formality. The CRA adds a security layer to that file — the SBOM, the risk assessment, the update policy — rather than a second file to keep.
If you're planning a connected product now, the cheapest time to deal with the CRA is before your first schematic. If you already have products in the field, September is the date that should worry you.
Talk to us if you want your roadmap checked against both deadlines, or read our CE certification guide for the wider picture.
Sources: European Commission — Cyber Resilience Act, European Commission — CRA reporting obligations.