CRA Reporting Requirements: 24h, 72h, 14 Days, 1 Month — and the Two Clocks That Don’t Start When You Become Aware

Short answer: Since 11 September 2026, Article 14 of the Cyber Resilience Act has required manufacturers to report two kinds of events, an actively exploited vulnerability in their product and a severe incident affecting its security. Each event triggers three filings: an early warning within 24 hours, a notification within 72 hours, and a final report. That adds up to four different deadlines, and only two of them run from the moment you become aware. The vulnerability final report runs from the day a fix or mitigation is available. The incident final report runs from the day you submitted the 72-hour notification. Most reporting errors come from treating all four as one countdown.

This guide puts both tracks on one worked timeline, lists what each filing must contain under the Official Journal text of Regulation (EU) 2024/2847, and shows how the deadlines are counted, including two portal behaviours that can move your dates. For the wider regulation (scope, CE marking, conformity assessment), start with our Cyber Resilience Act compliance guide.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Disclosure: we sell a CRA reporting template pack, mentioned once below. Everything about the law in this article is sourced to the regulation, the Commission or ENISA, and you can use it without buying anything.

Who has to report, and for which products

Plain-language summary: if you are the manufacturer of a product with digital elements sold in the EU, Article 14 applies to you now. That includes products you shipped years ago and products you no longer support. Two narrow situations fall outside it.

Situation	Reportable under Art. 14?	Basis
Product placed on the EU market before 11 December 2027	Yes	Art. 69(3) (legal rule)
Product whose support period has ended	Yes. Reporting continues, although vulnerability handling under Annex I Part II stops	Commission guidance, para. 210 (official interpretation)
Exploited flaw in a third-party library you ship	Yes, if it is exploited in your product. No, if the vulnerable code is unreachable or has not been exploited in your product	Commission guidance, para. 218
Exploitation you already knew about before 11 September 2026	No retroactive report. But a known flaw whose exploitation you learn about after that date is reportable	Commission guidance, para. 217
Open-source software steward	Only to the extent it is involved in development (vulnerabilities) or provides the development infrastructure (incidents)	Art. 24(3)
Medical devices and IVDs under MDR/IVDR, type-approved vehicles under 2019/2144	No. The CRA does not apply to these products	Art. 2(2)

For an SME owner, the practical point is the second row. Ending support for a product ends your duty to patch it, not your duty to report it. Keep discontinued products in the inventory your on-call team checks. The Finnish national CSIRT makes the same point in its NCSC-FI preparation notice for manufacturers, which tells them to include end-of-life products when they map scope.

When the clock starts: what “becoming aware” means

Plain-language summary: the 24-hour clock starts when a short, prompt initial assessment gives you reasonable certainty, not at the first rumour and not when the forensics are finished.

Article 3(42) defines an actively exploited vulnerability as one “for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.” The regulation itself never defines “becoming aware”. The Commission’s CRA guidance of 27 July 2026 fills that gap. When a suspicious event is detected or reported, the manufacturer “should assess the suspicious event immediately”, and it is “regarded as having become aware when, after such an initial assessment, it has a reasonable degree of certainty” that a vulnerability is being actively exploited or that a severe incident has compromised the product’s security (para. 213). The Commission aligned this test with the NIS2 implementing regulation and the GDPR breach guidelines so that one event does not get three different start times (para. 212).

The guidance is non-binding, and it cuts both ways. It allows a triage window, but para. 214 puts “the emphasis … on prompt action to carry out the initial assessment”. A team that lets a customer report sit in a queue for three days hasn’t extended its deadline. It has made its awareness timestamp hard to defend.

For the CISO or PSIRT lead, that means logging two timestamps on every case: when triage started and when the team reached reasonable certainty. The gap between them is what a market surveillance authority will ask you to explain. For the compliance officer, it means writing the awareness test into your reporting policy in the Commission’s words, so the person on call doesn’t have to interpret it at 2 a.m.

The six filings and what each one must contain

Plain-language summary: each track has three stages, and the content requirements grow at each one. Anything marked “where available” or “where applicable” can honestly be left open. The rest cannot.

The table reproduces the minimum content of Article 14(2) and 14(4) (legal rule). The SRP adds its own field list on top of it. NCSC-FI, for example, lists manufacturer name, product name, notification type, title and Member States for the early warning. For every platform field behind these six stages, form by form, see our CRA vulnerability reporting template.

Stage	Actively exploited vulnerability (Art. 14(2))	Severe incident (Art. 14(4))
Early warning 24 h from awareness	That an actively exploited vulnerability exists; Member States where the product is available, “where applicable”	At least whether the incident is suspected of being caused by unlawful or malicious acts; Member States, “where applicable”
Notification 72 h from awareness	General information “as available” on the product, the general nature of the exploit and the vulnerability, corrective or mitigating measures taken, measures users can take; how sensitive you consider the information	General information on the nature of the incident, an initial assessment, corrective or mitigating measures taken, measures users can take; sensitivity
Final report	No later than 14 days after a corrective or mitigating measure is available: description incl. severity and impact; malicious-actor information “where available”; details of the security update or other corrective measure	Within one month after submission of the 72-hour notification: detailed description incl. severity and impact; type of threat or root cause “likely” to have triggered it; applied and ongoing mitigation measures

Three provisions around the table matter as much as the table itself:

• What makes an incident “severe” (Art. 14(5)). An incident is severe if it negatively affects, or is capable of affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or if it has led or could lead to malicious code being introduced or executed in the product or in a user’s systems. “Capable of” means you don’t have to wait for actual harm.
• The intermediate report (Art. 14(6)). The coordinator CSIRT “may request” an intermediate status report. It is not a scheduled fourth stage, but your plan should name who writes it.
• Informing users (Art. 14(8)). This is a separate duty to tell impacted users, and where appropriate all users, what they can do to mitigate. The Commission says it applies in a risk-based way and doesn’t require publishing exploit detail (guidance, para. 220). Filing with ENISA does not discharge it.

One worked timeline: both tracks running at once

The scenario is fictional but common. A manufacturer of network-attached storage devices, with its main EU establishment in Ireland, receives a customer report on a Friday evening. During the investigation, the team finds the attacker also touched its firmware-signing server. That second finding starts a second track while the first is still open. Times follow the literal hour count, the planning reading recommended in the next section.

When	What happens	Deliverable and deadline it sets
Fri 6 Nov 2026, 17:40	Customer reports unexpected outbound traffic from two devices. PSIRT opens a case and starts the initial assessment.	Not yet aware. Log the triage start time.
Sat 7 Nov, 09:10	Device logs show a firmware flaw used to plant a web shell. Reliable evidence of exploitation, so Track 1 awareness.	Early warning due Sun 8 Nov, 09:10. Notification due Tue 10 Nov, 09:10.
Sat 7 Nov, 15:00	Early warning filed through the SRP, listing the Member States where the model is sold.	The portal now shows the 72-hour notification due Mon 9 Nov, 15:00 (see the next section).
Mon 9 Nov, 11:30	Forensics find the attacker’s credentials used on the firmware-signing server. That compromise could lead to malicious code reaching products, which meets Art. 14(5)(b). Track 2 awareness.	Incident early warning due Tue 10 Nov, 11:30, stating whether malicious acts are suspected. Incident notification due Thu 12 Nov, 11:30.
Mon 9 Nov, 14:00	Vulnerability notification filed with a configuration workaround and the sensitivity flag. The manufacturer tells the CSIRT that a patch is expected within 72 hours.	The CSIRT may delay onward sharing under Delegated Regulation 2026/881, Art. 3(a).
Mon 9 Nov, 16:00	Incident early warning filed.	On time.
Tue 10 Nov, 10:00	Workaround advisory sent to customers (Art. 14(8)).	A mitigating measure is now available, so the conservative reading puts the vulnerability final report due Tue 24 Nov.
Wed 11 Nov, 16:00	Incident notification filed, a day before its deadline.	Incident final report due Fri 11 Dec.
Mon 16 Nov	Signed firmware patch released.	If only the patch counted, the vulnerability final report would be due Mon 30 Nov. Plan to 24 Nov.

Two decisions in this timeline are judgement calls. First, does a workaround count as a “mitigating measure” that starts the 14-day clock? Article 14(2)(c) says “corrective or mitigating measure”, not “patch”. Delegated Regulation 2026/881 treats “a security update or user guidance” as an effective risk mitigation measure. That regulation governs dissemination, not your deadline, so the read-across is our interpretation and has not been confirmed by the Commission or ENISA. The cautious course is to diary the 14 days from the first published workaround. Second, filing the incident notification a day early moved the final-report deadline a day earlier. If it had been filed at the deadline on Thursday 12 November, the month would have ended on Saturday 12 December.

If this manufacturer is also an essential or important entity under NIS2, the signing-server compromise may be a significant incident with its own separate filing. That one goes to the national CSIRT or competent authority on NIS2’s own 24-hour, 72-hour and one-month schedule. See our guides to Article 23 incident notification and the 72-hour notification requirements. No CRA article merges the two filings.

How the deadlines are counted (and what the portal shows)

Plain-language summary: count hours literally, expect month-based deadlines to land on the same calendar date, and don’t rely on the portal’s countdown.

The general EU counting rule. Regulation 1182/71 on periods, dates and time limits is the EU’s default method. Under Article 3(1), the hour or day in which the triggering event occurs is not counted. Under Article 3(2)(c), a month ends on the same date in the following month, or on the last day of that month if the date doesn’t exist. Under Article 3(4), a period “expressed otherwise than in hours” whose last day is a Saturday, Sunday or public holiday ends at the close of the next working day. So the 24- and 72-hour windows never roll over a weekend, but the 14-day and one-month windows can. Example: a 72-hour incident notification submitted on 31 January 2027 makes the final report due 28 February 2027. That date is a Sunday, so on this reading it moves to Monday 1 March.

There is a caveat that competing guides skip. Article 1 of Regulation 1182/71 applies it to “acts of the Council or Commission”, and the CRA was adopted by Parliament and Council. We found no statement from ENISA or in the Commission’s guidance that the roll-forward applies to Article 14. Treat it as a fallback argument, not a planning assumption. File by the literal clock.

The portal’s counters. ENISA’s Single Reporting Platform FAQ (updated 15 October 2026) explains three behaviours in FAQ 26:

• The 72-hour counter shows a due time 48 hours after you submit the early warning, not 72 hours after awareness. File the early warning early and the portal will flag the notification as due earlier than the law requires. File it late and the counter shows a time after your legal deadline. ENISA plans to base the counter on the awareness field in a later release.
• There is no counter at all for the vulnerability final report, because the platform can’t know when your fix became available.
• The incident counter runs one month from the 72-hour notification. ENISA says the counters are visibility aids and don’t replace your legal obligations.

Where the report goes, and who sees it

Every mandatory notification goes through the SRP to the coordinator CSIRT of your main establishment and is simultaneously accessible to ENISA (Art. 14(7)). Your main establishment is the Member State where cybersecurity decisions about your products are predominantly taken. If that can’t be determined, it is the Member State of your largest EU establishment by headcount. Manufacturers with no EU establishment follow a fixed order: authorised representative, then importer, then distributor, then the Member State with the most users. ENISA’s FAQ 18 warns that picking the wrong CSIRT can invalidate a notification, and FAQ 8 says one notification per event is enough even for groups with several EU entities.

Operational rules from the same FAQ that belong in your procedure:

• Every filer needs an EU Login account with multi-factor authentication. Each manufacturer has one Primary Assigned Representative and up to 20 Secondary representatives (FAQ 9). Register a deputy before you need one.
• The platform is English-only (FAQ 24) and has no API (FAQ 15). NCSC-FI expects API submission may become possible from spring 2027.
• If the SRP is down, wait and submit when it is back. Contact the CSIRT directly only if immediate communication is necessary, and still file through the SRP afterwards (FAQ 25). We had this wrong in the first version of our own SRP submission guide, which told readers to file directly with the CSIRT. We corrected it once ENISA published the FAQ.

After receipt, the coordinator CSIRT passes the notification on to the CSIRTs of the Member States you listed (Art. 16(2)). It can delay that “for a period of time that is strictly necessary” on cybersecurity grounds. The Commission Delegated Regulation (EU) 2026/881, adopted on 11 December 2025, sets the conditions. One of them is that you have told the CSIRT an effective mitigation is expected within 72 hours. That is why the sensitivity flag in your 72-hour notification is worth filling in deliberately.

Penalties, and the small-company carve-out

Breaching Article 14 can attract administrative fines of up to EUR 15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher (Art. 64(2)), the same ceiling as the essential requirements. The actual penalty rules are set by each Member State (Art. 64(1)), and fines are weighed case by case, with explicit regard to the size of microenterprises and SMEs (Art. 64(5)(c)).

Article 64(10)(a) says fines “shall not apply” to microenterprises and small enterprises “with regard to any failure to meet the deadline referred to in Article 14(2), point (a), or Article 14(4), point (a)”. That covers the two 24-hour early warnings and nothing else. A small manufacturer that misses a 72-hour notification or a final report has no carve-out. A drafting point for compliance officers: paragraph 10 is framed as a derogation “from paragraphs 3 to 9”, while the Article 14 fine ceiling sits in paragraph 2. The intent to exempt late early warnings is clear from the text of point (a), but confirm how your national market surveillance authority applies it before treating the 24-hour deadline as soft. Open-source software stewards are exempt from CRA fines altogether (Art. 64(10)(b)).

Readiness by role: what each person needs before the next case

Recommended internal practice, based on Article 14 and the ENISA FAQ (practical framework, not legal text):

Role	Have ready	Effort
CISO / PSIRT lead	Awareness test in the Commission’s words; two-timestamp case log; triage criteria for Art. 14(5) severity; on-call rota with a registered Secondary AR	Medium
Compliance officer / legal	Main-establishment determination on file; deadline calculator using the literal clock; 14-day trigger rule for workarounds; NIS2 dual-filing check	Low
SME owner	Product inventory including end-of-support products; one named deputy; a single rehearsal before the first real case (NCSC-FI recommends practising at least once)	Low
Board / management	Pre-delegated authority to file without sign-off out of hours; budget for the user-notification channel under Art. 14(8)	Low

If you are a manufacturer that is also a NIS2 entity, our comparison of NIS2 and CRA obligations for manufacturers and the guide to zero-day disclosure under NIS2 cover the overlap in more depth.

Frequently asked questions

Does the 24-hour clock start when a researcher reports a vulnerability to us?
Not on its own. Article 14 is triggered by awareness of active exploitation, meaning reliable evidence that someone has exploited the flaw without permission. A vulnerability report with no evidence of exploitation goes through your coordinated disclosure and vulnerability handling process instead. If evidence of exploitation appears later, the clock starts then.

Can we combine the early warning and the 72-hour notification?
Articles 14(2)(b) and 14(4)(b) require the notification “unless the relevant information has already been provided”, so a complete early warning can satisfy both in law. In practice, the SRP works stage by stage and carries fields forward (FAQ 16), so expect to submit each stage.

Is the vulnerability final report due 14 days after awareness?
No. It is due no later than 14 days after a corrective or mitigating measure is available. If no fix exists yet, the clock hasn’t started. The coordinator CSIRT can still request an intermediate report under Article 14(6).

Do we have to publish details of the vulnerability to users?
Article 14(8) requires informing impacted users, and where appropriate all users, about the issue and the measures they can take. The Commission’s guidance says this is risk-based and doesn’t require indiscriminate public disclosure of technical detail before the issue is addressed (paras. 220–221).

Does the CRA apply to vulnerabilities we knew were exploited before 11 September 2026?
No retroactive report is required for exploitation you were already aware of before that date (guidance, para. 217). A vulnerability you knew about earlier becomes reportable if you learn of its exploitation after it.

Sources

1. Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal text — EUR-Lex. Articles 2(2), 3(40)–(45), 14, 16, 24(3), 64, 69(3) and 71.
2. Commission guidance on the application of Regulation (EU) 2024/2847, Annex to C(2026) 5252, 27 July 2026 — European Commission. Section 9.1, paras. 209–221.
3. CRA Single Reporting Platform: Frequently Asked Questions, updated 15 October 2026 — ENISA. FAQs 8, 9, 15, 16, 18, 21, 24, 25 and 26.
4. Manufacturers – prepare in advance for reporting vulnerabilities and incidents under the Cyber Resilience Act, 28 August 2026 — National Cyber Security Centre Finland (Traficom).
5. Regulation (EEC, Euratom) No 1182/71 determining the rules applicable to periods, dates and time limits — EUR-Lex. Articles 1 and 3.
6. Commission Delegated Regulation (EU) 2026/881 on the conditions for delaying the dissemination of notifications, OJ L 20.4.2026 — EUR-Lex. Article 3.
7. Commission publishes new guidance to support timely Cyber Resilience Act implementation, 27 July 2026 — European Commission, Shaping Europe’s digital future.