CRA Article 14: the 24-hour reporting deadline, explained

From 11 September 2026 the Cyber Resilience Act starts a 24-hour clock the moment you become aware of an actively exploited vulnerability in your product. This page explains what triggers it, what each filing must contain, and the eight ways companies miss it.

Last reviewed 2026-09-04 · IncidentReady, Harmony Future Holdings Limited, Dublin

Who this applies to

The obligation falls on the manufacturer of a product with digital elements placed on the EU market. That is a broad category: it covers software sold or licensed commercially, connected hardware, and firmware. If you place such a product on the EU market, Article 14 reporting is yours to do — it does not transfer to your distributor, your reseller or your cloud host.

If your product is not placed on the EU market, Article 14 is not triggered. That does not make you clear: GDPR, NIS2 and your own customer contracts have separate clocks with separate triggers, and this page does not cover them.

The two tracks

Article 14 has two independent triggers. An event can hit one, both, or neither. When it hits both, both sets of obligations run — they do not merge into one filing.

Track 1 — actively exploited vulnerability

A vulnerability in the product for which there is reliable evidence that it has been exploited by a malicious actor in or against a product with digital elements, without the consent of its user (Art. 3; Art. 14(1)).

The word doing the work is exploited. A published CVE against your product is not, on its own, this trigger. Evidence that someone is actually using it against users is.

Track 2 — severe incident

An incident having an impact on the security of the product: negatively affecting its ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions (Art. 14(3); Art. 3).

The clocks

All three clocks below run in absolute hours. Weekends, public holidays and your own working week do not extend them. An event you become aware of at 18:40 on a Friday has its early warning due by 18:40 on Saturday.

What each filing must contain

The early warning, at 24 hours

Whether the vulnerability or incident is suspected of being caused by unlawful or malicious acts; and the member states in which the product is made available, where known.

The notification, at 72 hours

• General information about the product concerned.
• The general nature of the exploit or incident.
• Any corrective or mitigating measures taken, or available to users.
• Where relevant, an update to the early-warning information.

The final report

For an exploited vulnerability: a description of the vulnerability, its severity and impact; where available, information on the malicious actor; and details of the corrective or mitigating measure made available.

For a severe incident: a detailed description of the incident, its severity and impact; the type of threat or root cause likely to have triggered it; and applied and ongoing mitigation measures.

Where the filings go

Notifications are submitted through the ENISA Single Reporting Platform (SRP), which routes simultaneously to ENISA and to the CSIRT designated as coordinator of the member state where the manufacturer has its main establishment (Art. 14, Art. 16). One submission, two recipients.

The duty to tell users

Separately from the regulator filings, the manufacturer must inform impacted users of the product — and where appropriate all users — about the incident or the actively exploited vulnerability and, where necessary, about risk-mitigating measures they can deploy, without undue delay (Art. 14(8)).

Deciding whether it is even reportable

At 2 a.m. the hard question is not what the deadline is — it is whether this is reportable at all. These are the questions in the order our classifier asks them. The free tool on this site walks the same four questions and computes the dates.

1. Does this concern a product with digital elements you place on the EU market?

   No — Article 14 CRA reporting is not triggered. Stop here for CRA, but check GDPR, NIS2 and your contracts separately; they have their own clocks.

2. Is there reliable evidence that a vulnerability in it is being exploited by a malicious actor, without the users’ consent?

   Yes — the actively exploited vulnerability track is live, and the 24-hour clock started when you became aware. No — reassess the moment new evidence arrives.

3. Does the event negatively affect the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive data or functions?

   Yes — the severe incident track is live, in addition to any vulnerability track. Both sets of obligations run.

4. Are users at risk, such that they need to take action?

   Yes — issue the user notice under Art. 14(8). No — document the reasoning for deciding not to notify. The decision itself is evidence, and “we discussed it” is not a record.

What makes an incident severe

The regulation gives a definition, not a threshold. These are the factors that carry the judgement in practice:

• Number of users affected, and whether they can be identified and reached.
• Whether sensitive data or a safety-relevant function is involved.
• Whether the product can still be operated safely in the meantime.
• Whether a workaround exists that users can apply themselves today.
• Whether the issue is public, or under coordinated disclosure.
• Geographic spread across member states — the early warning asks which ones.
• Whether other products of yours share the affected component.

Have this in hand before you open the form

• Your manufacturer identity and main establishment as registered.
• The product name and the exact affected version range.
• The timestamp you became aware, and how.
• Whether malicious acts are suspected — yes, no or unknown is acceptable at 24 hours.
• The member states where the product is made available.
• A one-paragraph description in plain language.
• Your own reference number for the event, so later filings tie to it.
• Who is submitting, and a contact address the CSIRT can reply to.

The eight ways companies miss the 24 hours

1. Nobody was monitoring, so awareness came from a customer weeks after exploitation began. The clock is measured from awareness — but a late awareness is itself the finding.
2. The first person who knew did not recognise it as reportable and sat on it for two days.
3. It began on a Friday evening. Weekends do not pause the clocks and nobody had an out-of-hours path.
4. The early warning was delayed while the team tried to finish the technical analysis. The 24-hour filing does not require it.
5. No one could say which member states the product is sold in — which the early warning asks for directly.
6. The user notice was treated as a later step rather than a parallel decision, so users learned from the press.
7. Version ranges were unknown because no SBOM existed, so the notification could not say what was affected.
8. Everything was done correctly and none of it was written down, so none of it could be shown afterwards.

Out of hours

The clocks do not observe your working week. Agree now: who is called first, on what number, what happens if they do not answer within fifteen minutes, and who is authorised to file without waiting for anyone else.

Penalties

Non-compliance with essential requirements and core obligations is subject to administrative fines of up to €15,000,000 or 2.5% of worldwide annual turnover, whichever is higher (Art. 64).

Three scenarios worth rehearsing

Friday 18:40 — a researcher’s tweet

A security researcher posts a working proof of concept against your current firmware. No customer has reported anything. Your incident lead is at a wedding with their phone on silent. Is this ‘actively exploited’? Who decides, and by when? What time does the 24-hour clock expire, and who files if the lead is unreachable?

Tuesday 09:15 — a customer’s SOC

An enterprise customer reports traffic from your device to an unknown host. You cannot reproduce it. Their security team wants a statement within the hour. What do you say before you know? Does a customer’s evidence make you ‘aware’? Who talks to them, and who talks to the regulator?

Thursday 14:00 — a shared component

A CVE lands in a third-party library used in four of your products, and exploitation is confirmed in the wild against other vendors. Which of your products are affected, and how fast can you answer that? Is one report needed, or four? Where is the SBOM?