Cyber Resilience Act reporting obligations since September 2026
Since 11 September 2026, manufacturers of products with digital elements sold in the EU must report actively exploited vulnerabilities and severe incidents within strict deadlines. The rest of the Cyber Resilience Act applies from 11 December 2027. Here is what applies now, to whom, and how to get ready.
Two dates to know
| Date | What applies |
|---|---|
| 11 September 2026 | Article 14 reporting obligations of manufacturers [1][3][4] |
| 11 December 2027 | Most other obligations, including the essential cybersecurity requirements of Annex I [1][5] |
The reporting duty came first, before the product requirements. So you can be in scope for reporting today even if your product redesign for Annex I is still planned for 2027.
Who must report
The obligation sits with the manufacturer of a product with digital elements made available on the EU market [1]. That covers hardware with software in it, such as routers, cameras and industrial controllers, and software products sold in the EU.
A point many companies miss: the reporting duty also applies to products placed on the market before 11 September 2026 [3]. If you still have a product in use in the EU from a few years ago and it is being exploited, you report.
What triggers a report
There are two triggers [1][2]:
- An actively exploited vulnerability in your product. The regulation defines this as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission [1][2].
- A severe incident having an impact on the security of your product [1][2].
A vulnerability found by your own team or a researcher, with no evidence of exploitation, does not start the Article 14 clock. Handle it through your normal process.
The three reports
| Report | Deadline | Main content |
|---|---|---|
| Early warning | Without undue delay, within 24 hours of becoming aware | Where applicable, the Member States where you know the product is made available [2] |
| Notification | Within 72 hours of becoming aware | General product information, general nature of the exploit and vulnerability, corrective or mitigating measures, how sensitive the information is [2] |
| Final report: vulnerability | No later than 14 days after a corrective or mitigating measure is available | Fuller description of the vulnerability and the fix [2] |
| Final report: severe incident | Within one month after the incident notification | Detailed description of the incident, its severity and impact [2][4] |
The final report for a vulnerability runs from the moment a fix or mitigation is available, not from awareness [2]. If your fix takes three weeks, the final report is due about five weeks after you first became aware.
Where reports go
Reports are submitted through the single reporting platform set up by ENISA. They reach the CSIRT designated as coordinator and ENISA at the same time [1][3][4]. The coordinator is normally the CSIRT of the Member State where you have your main establishment in the EU [1].
Informing users
After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer informs the impacted users, and where appropriate all users, about it and about risk mitigation and corrective measures they can take [2]. Prepare a short notice format in advance so you are not writing from zero during an incident.
Worked example: a software company
A company sells a self-hosted file sharing server to businesses in France, Spain and Italy. On Tuesday at 09:00 a CSIRT tells them a path traversal flaw in version 5 is being exploited against customers.
- Awareness: Tuesday 09:00.
- Early warning: by Wednesday 09:00, naming France, Spain and Italy.
- Notification: by Friday 09:00, with the nature of the flaw and the workaround (block one URL pattern at the proxy).
- Fix released: the next Monday. Final report due 14 days after that.
- User notice: emailed to customers the same Tuesday with the workaround, and again when the fix ships.
A preparation plan for this month
- List every product with digital elements you have on the EU market, including older versions still in use.
- For each, note the Member States where it is sold, as far as you know.
- Name a primary and a backup person who can submit reports, including outside office hours.
- Find out which CSIRT is your coordinator, based on your main establishment.
- Prepare templates for the early warning, notification, final report and user notice.
- Decide where you keep the case record: time of awareness, what you sent and when.
- Run a short drill: pretend you learn of an exploited flaw on Friday evening and time how long the early warning takes.
Short template: case record
Case ID: Type: actively exploited vulnerability / severe incident Product and versions: Became aware (date, time, zone): Early warning due (+24 h): sent: Notification due (+72 h): sent: Fix or mitigation available on: Final report due: sent: Users informed on: Owner: Backup:
For the hour-by-hour detail of the first day, see the 24-hour reporting guide. For the processes behind reporting, see the vulnerability handling and SBOM checklist. Weighing your options? Read spreadsheet vs tool vs consultant.
Related guides
- CRA 24-hour reporting: actively exploited vulnerabilities
- CRA vulnerability handling and SBOM checklist
- CRA reporting: spreadsheet vs tool vs consultant
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal, EUR-Lex: Articles 3, 14, 64, 69, 71 and Annex I
- Cyber Resilience Act text, Article 14 (reproduction of the official text)
- Crowell and Moring, It's live: CRA reporting is mandatory as of 11 September 2026
- Browne Jacobson, Cyber Resilience Act reporting obligations in force
- Wikipedia, Cyber Resilience Act (timeline overview)
This guide explains the rules in plain language. It is not legal advice. Check your own country's law and, when in doubt, ask a qualified adviser.