CRA Article 14: the reporting duty starts 11 September 2026
The CRA's reporting duty lands fifteen months before the rest of it. Three clocks — 24 hours, 72 hours, 14 days — and you cannot report what you cannot see.
Almost everyone planning for the Cyber Resilience Act has one date in their calendar: 11 December 2027, when the essential requirements, conformity assessment and CE marking apply.
There is an earlier one, and it is the one that catches people.
From 11 September 2026, Article 14 requires manufacturers to report actively exploited vulnerabilities and severe security incidents. That is fifteen months before the rest of the Regulation, and it lands on products that will not need to be CE marked for another year after that.
What has to be reported
Two things, and they are not the same:
An actively exploited vulnerability in your product. Not every vulnerability — one being exploited. The trigger is exploitation, not severity.
A severe incident affecting the security of your product.
Who it goes to, and how
To your coordinator CSIRT and ENISA simultaneously, through a single reporting platform. Not one then the other; not whichever you reach first.
The three clocks
All three run from becoming aware — not from confirming, not from fixing.
| Clock | Deadline | What it is |
|---|---|---|
| Early warning | 24 hours | You are aware; say so. Not a full analysis. |
| Notification | 72 hours | A fuller account of what it is and what you know. |
| Final report | 14 days after a fix is available | For a vulnerability. |
| Final report | one month after the notification | For a severe incident. |
Twenty-four hours is the number to sit with. It is not long enough to investigate, decide, draft, get legal sign-off and route the submission — unless all of that was arranged in advance.
The obligation behind the obligation
The clocks start when you become aware. Which raises a question the Regulation does not have to ask, because it assumes the answer:
How would you know?
If you have no way to learn that a vulnerability in your product is being exploited in the field, you will not report it in 24 hours. You will report it whenever somebody happens to tell you — which may be a customer, a researcher, or a journalist.
So Article 14 quietly requires something upstream of itself: a way to find out. Telemetry, a monitored disclosure channel, a relationship with the researchers who look at your product, and someone whose job it is to notice.
Four gaps that stop a 24-hour report
These are the ones we see most often, and none of them are exotic:
No reliable way to learn that a vulnerability is being exploited. (Article 14(1)) The clock cannot start if nothing starts it.
No workable path to a 24-hour notification. (Article 14(2), (4) and (7)) Knowing is not reporting. Someone has to be able to submit, out of hours, without a committee.
No named owner for security incident reporting. A duty that belongs to everybody belongs to nobody at 2am on a Sunday.
No coordinated vulnerability disclosure policy. (Annex I, Part II, point (1)) This one is an essential requirement in its own right, but it is also how most manufacturers learn about problems at all. Without a published way to reach you, a researcher’s next move is a blog post.
Two more that bite at the same time
Annex I, Part II carries obligations that turn out to be prerequisites for handling a report well:
A maintained software bill of materials (Annex I, Part II(2), with Article 13(8), (9) and (19)) — covering at least the top-level dependencies. When a vulnerability lands in a library, an SBOM is the difference between answering “are we affected?” in an hour and in a fortnight.
Security updates that cover the expected support period (Annex I, Part II, points (5) and (6)) — because a final report is due within 14 days of a fix being available, and a product you can no longer patch has no such date.
What to do before September 2026
The reporting duty is unusual among compliance obligations in that it cannot be satisfied by writing a document. It is operational, and it either works at 2am or it does not.
- Decide who is on the hook. A named person, and a named deputy. Not a team.
- Find out how you would learn. Trace, honestly, the path by which news of an exploited vulnerability would actually reach that person today.
- Publish a disclosure policy and monitor the address it names. This is an Annex I requirement anyway.
- Work out the submission path before you need it — which CSIRT is your coordinator, what the platform expects, who has credentials.
- Rehearse the 24 hours. Once. On a Friday afternoon, with the person who would actually do it.
The fifth one is what separates the manufacturers who will make the deadline from the ones who have written it down.
Why the gap exists
The staggering is deliberate. The essential requirements in Annex I need product engineering, and the EU gave three years for that. Reporting needs a process and a person, and the legislator took the view that eighteen months was enough for those.
Whether or not that is generous, it means the first thing the CRA asks of you is not a redesign. It is a phone number that works.