CRA Article 14 reporting: 24 hours, 72 hours, 14 days
This one is live now. Article 14 of the Cyber Resilience Act applies from 11 September 2026 — fifteen months before the rest of the regulation. If you place a product with digital elements on the EU market, you already owe reports on actively exploited vulnerabilities and severe security incidents, on a 24-hour first clock.
What triggers a report
Two distinct triggers, and the difference matters because manufacturers routinely over-report the first and under-report the second.
1. An actively exploited vulnerability
A vulnerability in your product that is being exploited by a malicious actor. The key word is actively. A vulnerability you discovered in an internal audit, or that a researcher disclosed to you privately, is not reportable under Article 14 simply because it exists — it becomes reportable when you become aware it is being exploited. Your ordinary vulnerability handling duties still apply to it either way.
2. A severe incident having an impact on product security
An incident that negatively affects, or is capable of negatively affecting, the ability of the product to protect the availability, authenticity, integrity or confidentiality of data or functions. A compromise of your build pipeline that could have injected code into a shipped product is the textbook case, and it is the one manufacturers most often fail to recognise as reportable. The incident does not have to be in the product itself.
The three deadlines
Each trigger runs its own sequence. The clock starts when you become aware, which is not the same as when you have confirmed, diagnosed or fixed anything.
| Stage | Deadline | What it must contain |
|---|---|---|
| Early warning | 24 hours | That you are aware of an actively exploited vulnerability or severe incident. Where known, the Member States affected. This can be thin — it is a flag, not a report. |
| Full notification | 72 hours | General information about the product, the nature of the exploit or incident, severity and impact, and any corrective or mitigating measures taken or available. |
| Final report | 14 days / 1 month | For an actively exploited vulnerability: within 14 days of a corrective or mitigating measure being available. For a severe incident: within one month of the 72-hour notification. Full description, severity, impact, root cause, and the mitigations applied. |
Who you report to
Reports go through the single reporting platform operated by ENISA. You submit once; the report reaches the CSIRT designated as coordinator and ENISA at the same time. The platform went live alongside the obligation on 11 September 2026.
Practical consequence: register and test your access before you need it. A 24-hour clock is not the moment to discover that nobody at your company has an account, that the person who does has left, or that your out-of-hours process routes security mail to an unmonitored inbox.
You also have to tell your users
Article 14 is not only an authority-facing duty. Where an actively exploited vulnerability or a severe incident affects the security of the product, you must inform the users of the product without undue delay, and where necessary tell them what corrective action to take. In practice that means you need a route to reach your installed base that does not depend on them logging in to something.
What to have in place before an incident
- A named person and a deputy with platform access, and a rota that survives holidays.
- A monitored intake address published in your coordinated vulnerability disclosure policy — Annex VII requires evidence that one exists.
- A written severity triage rule so that "is this a severe incident?" is answered against criteria you decided calmly in advance, not at 2am.
- A pre-drafted early warning. Twenty-four hours sounds generous until it contains a weekend.
- A user notification channel — release notes plus a security advisory feed plus, for enterprise customers, direct contact.
- A log of decisions not to report, with the reasoning. If a market surveillance authority ever asks why you did not report something, a contemporaneous note is worth far more than a reconstruction.
How this interacts with NIS2 and GDPR
Separate regimes, separate clocks, overlapping facts. A single breach can be a personal data breach under the GDPR (72 hours to your supervisory authority), a significant incident under NIS2 if you are an in-scope entity (24-hour early warning), and a severe incident under the CRA. The CRA does not absorb the others. Build one internal trigger that fans out to three assessments rather than three separate detection processes.
Get told when the requirements change
None of the 35 CRA harmonised standards is published yet. When they land — and when deadlines move — we email you. No more than twice a month.
Frequently asked
We are a US company with EU customers. Does this apply?
Yes. The trigger is placing the product on the EU market, not where you are established. The scope test in full →
Does this apply to open-source projects?
Non-commercial open source is out of scope. Open-source software stewards have a lighter, separate reporting duty. The open-source position →
What if the vulnerability is in a third-party component we ship?
If it is in your product as placed on the market, it is your report. This is the practical reason the regulation cares about your SBOM — you cannot report on a component you did not know you were shipping.