11 September 2026 brings the first hard deadline of the Cyber Resilience Act. It is not a design requirement or a documentation requirement, which is exactly why it catches people off guard: it is an operational one.
From that day, any manufacturer placing a product with digital elements on the European market has to be able to raise an alert within 24 hours. Not fix the problem in 24 hours — report it. And reporting requires something most small companies do not have in place: somebody who answers.
This is not a legal topic, it is an engineering process topic. The regulation itself takes twenty minutes to read. What takes work is having a channel, a named person on call, and an inventory of what firmware is out there.
Table of contents
What exactly starts on 11 September
The reporting obligations under Article 14 of Regulation (EU) 2024/2847 become enforceable. The rest of the regulation does not apply in full until December 2027, but this piece arrives early.
The two things you must report
- Actively exploited vulnerabilities in your product. The word "actively" is doing the work: this is not any flaw you find, it is a flaw somebody is using.
- Severe incidents affecting the security of the product.
The deadlines, with the nuance almost everyone gets wrong
- Early warning: 24 hours from becoming aware. It is a warning, not a full analysis.
- Notification: 72 hours, this time with technical detail.
- Final report: here is where most summaries go wrong. For an actively exploited vulnerability, 14 days from the moment a corrective measure is available — not from when you found out. For a severe incident, the deadline is one month.
Look closely at the 24-hour clock. It starts when you become aware, not when your team gets round to it on Monday morning. If the alert lands on a Friday afternoon in an inbox nobody reads until Monday, the entire window is already gone.
It applies even to products you sold years ago
This is the part that surprises people most. The reporting duties are not limited to products you place on the market after 11 September: they reach products that are already on the market.
Which means that connected device you shipped in 2022, still running in customers' homes, the one you barely think about, is in scope. If an actively exploited vulnerability affecting it turns up tomorrow, the clock runs just the same.
Which leads straight to an uncomfortable question: do you know exactly which firmware versions are out there?
You report once, not twice
There is a common misconception here. You do not send one alert to ENISA and a separate one to your national CSIRT.
The notification goes once, through the single reporting platform, and from there it is distributed automatically: to the CSIRT acting as coordinator — the one in the country of your main establishment — to ENISA, and to the CSIRTs of other territories where the product is available.
What you need in place before that date
Four things. None of them expensive; all of them requiring a decision before you need them.
1. A channel where people can reach you
A published, visible address a researcher, a customer or a CERT can write to. If the only route to tell you about a security flaw is the commercial contact form, the alert will take days to reach whoever needs to read it.
The standard approach is a dedicated security address plus a published disclosure policy stating what you expect to receive and how quickly you respond.
2. Someone able to respond within 24 hours
You do not need a 24/7 rota. You need it written down who that person is, with a backup, and the channel above actually reaching their phone rather than a shared mailbox.
3. An inventory of what firmware is in the field
This is the real engineering part, and the most work if it was not done at the time. You need to answer quickly: which versions are deployed, across how many units, with which third-party components inside, and how they get updated.
If you already have tidy version control, this is half done. It is the same discipline needed to know whether a firmware update affects CE marking.
4. A written definition of what you consider "severe"
The day of the incident is not the moment to debate whether a flaw crosses the threshold. It pays to have written down in advance, even on a single page, which combinations of impact and exploitability trigger a notification and which do not.
The mistake almost everyone is going to make
Reading the regulation, understanding it, agreeing with it, and appointing nobody.
The typical failure will not be one of legal interpretation. It will be an email arriving on a Friday, landing in a generic inbox checked on Mondays, and by the time anyone reads it the early-warning window has expired. The obligation is a process, and processes without a name attached do not exist.
Quick test: ask your team today who would answer if a vulnerability report arrived this afternoon. If it takes thinking about, or the answer is "well... someone", that is your work for the next few days.
How we approach it at RobotUNO
To be clear: we are not legal advisors and we do not file reports on your behalf. The obligation belongs to the manufacturer and cannot be delegated.
What we do is the technical work that makes compliance possible:
- Set up firmware versioning and traceability so the field inventory can be looked up rather than reconstructed.
- Design signed, verifiable remote updates, which is what turns "we need to patch" into something you can actually do.
- Document the third-party components inside the product, so you know which public advisories touch you.
- Help define the technical severity criteria, which is an engineering decision before it is a legal one.
It follows naturally from the work on any connected device and from what we cover in our guide to CE marking and pre-compliance.
And no, this does not replace CE marking. The marking demonstrates conformity at the moment the product is placed on the market. The CRA adds duties that live across the product's whole life. They are different layers.
Frequently asked questions
Does the CRA apply to me if I only sell in one country?
Yes. The CRA is a directly applicable European regulation: what matters is not how many countries you sell in, but that you place a product with digital elements on the EU market. Selling in one member state is selling on the EU market.
Do I have to report every vulnerability that turns up?
No. The duty covers two specific cases: vulnerabilities that are being actively exploited, and severe incidents affecting the security of the product. A vulnerability you find yourself and patch before anyone exploits it does not start the 24-hour clock.
What if the flaw is in a third-party library I did not write?
You are still the one who reports. The obligation sits with the manufacturer, meaning whoever develops the product and sells it under their own name or trademark. Code coming from someone else's component changes how you fix it, not who answers for it.
Who exactly do I report to?
You submit once, through the single reporting platform. From there it reaches the CSIRT acting as coordinator — the one in the country of your main establishment — and ENISA at the same time. There is no need to send separate notifications.
Does this replace CE marking?
No, it adds to it. CE marking demonstrates the product's conformity at the moment it is placed on the market. The CRA reporting duties are continuous and live for the whole life of the product, even years after it was sold.
Do you have connected product on the market?
We can review your versioning, remote update path and component traceability so that 11 September does not find you rebuilding an inventory from scratch.
