CRA Article 14: reporting actively exploited vulnerabilities within 24 hours
Updated 2 November 2026 · General information, not legal advice. Quotes are from the official text of the Cyber Resilience Act.
Since 11 September 2026, every manufacturer that sells a product with digital elements in the EU must report actively exploited vulnerabilities in that product. The first report is due within 24 hours of becoming aware. This is Article 14 of the Cyber Resilience Act (CRA), and it applies whether or not you are based in the EU.
It also applies to products you shipped years ago. The rest of the CRA only covers products placed on the market from 11 December 2027, but Article 14 is the exception:
By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027.
What counts as an actively exploited vulnerability
‘actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner
The definition speaks of exploitation "in a system", not necessarily in your product. So when a library you ship turns up on a list of exploited vulnerabilities, you need to decide quickly whether the vulnerability is contained in your product and affects it. How far that reaches, for example when the vulnerable code is never used, is a judgement to document and, where unclear, to check with your adviser. The main public sources of evidence are CISA's Known Exploited Vulnerabilities (KEV) catalogue and the exploited-vulnerability list in ENISA's EU Vulnerability Database (EUVD), along with vendor advisories and your own incident data.
The three reports and their deadlines
Article 14(2) sets out three notifications. Each later one is only needed if you haven't already given that information.
| Report | Deadline | What it contains |
|---|---|---|
| Early warning | Within 24 hours of becoming aware | That an actively exploited vulnerability exists, and where applicable the EU Member States in which you know the product has been made available. |
| Vulnerability notification | Within 72 hours of becoming aware | General information about the product, the general nature of the exploit and the vulnerability, corrective or mitigating measures taken and those users can take, and how sensitive you consider the information. |
| Final report | No later than 14 days after a corrective or mitigating measure is available | A description of the vulnerability including its severity and impact, information about any malicious actor exploiting it where available, and details of the security update or other corrective measures. |
The CSIRT that receives your notification may also ask for an intermediate report with status updates (Article 14(6)). Severe incidents affecting the security of your product follow a similar pattern, with a 24-hour early warning and a 72-hour incident notification, but the final report is due within one month of the incident notification (Article 14(3) to (5)).
Who receives the reports
You submit through the single reporting platform that ENISA runs under Article 16. The notification goes to the CSIRT designated as coordinator in the Member State where you have your main establishment in the EU, and is simultaneously accessible to ENISA (Article 14(7)). Your main establishment is where decisions about the cybersecurity of your products are predominantly taken, or failing that, your EU establishment with the most employees.
If you have no establishment in the EU, Article 14(7) gives an order to follow, based on the information you have:
- the Member State of your authorised representative acting for the highest number of your products;
- otherwise, the Member State of the importer placing the highest number of your products on the market;
- otherwise, the Member State of the distributor making the highest number of your products available;
- otherwise, the Member State where the highest number of users of your products are located.
Work this out now, not during your first 24-hour window.
Tell your users too
After becoming aware of an actively exploited vulnerability or a severe incident having an impact on the security of the product with digital elements, the manufacturer shall inform the impacted users of the product with digital elements, and where appropriate all users, of that vulnerability or incident and, where necessary, of any risk mitigation and corrective measures that the users can deploy
If you don't inform users in time, the CSIRTs you notified may do it themselves.
Why the 24 hours are hard
The clock starts when you become aware, not when you finish investigating. Writing an early warning takes minutes. The hard part is knowing, within hours, that a component buried in one of your releases has just been added to an exploited-vulnerability list. That needs two things most teams don't have yet: an accurate list of components for every release still on the market, and something that checks those lists every day.
Non-compliance with Article 14 can be fined up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher (Article 64(2)).
How to prepare: a checklist
- Keep an SBOM for every release still on the market. The CRA already requires one (Annex I, Part II). See CRA SBOM requirements.
- Check every component against exploited-vulnerability lists daily, including releases you no longer actively develop.
- Name who triages and who submits, with a backup. The 24 hours include weekends and holidays.
- Identify your CSIRT using the main-establishment rules above.
- Prepare templates for the early warning, the 72-hour notification, the final report and the notice to users.
- Record when you became aware and what you decided, so you can show a regulator your timeline.
- Plan how you reach users, for example through your update channel, your app or email.
How ShipAttest helps
ShipAttest stores an SBOM for each release you upload from CI, re-checks every component daily against OSV, CISA KEV and ENISA EUVD, and opens a case the moment a shipped component becomes actively exploited. Each case shows the 24-hour, 72-hour and final-report deadlines, drafts the reports from the facts you've recorded, and keeps a time-stamped audit trail. See how it works.