CRA Severe Incident Reporting: The 24h/72h/1-Month Clock and the Article 14(8) User Notice That Has No Fixed Deadline

Short answer: Under the Cyber Resilience Act, a severe incident is one that weakens, or could weaken, a product’s ability to protect sensitive or important data or functions, or that could get malicious code into the product or into its users’ systems. The regulation’s own example is an attacker who slips code into the channel you use to ship security updates. Since 11 September 2026, Article 14(3) and (4) give you 24 hours to send an early warning, 72 hours to send an incident notification and one month after that to file a final report, all through ENISA’s Single Reporting Platform. Article 14(8) then adds a duty most “24-hour” explainers skip: you must tell the impacted users what happened and what they can do about it. That duty has no hour count attached, which is exactly why it gets missed.

One disclosure: we sell a CRA reporting pack, and it is mentioned once below. Every legal statement here is checked against the Official Journal text of Regulation (EU) 2024/2847 or the Commission’s and ENISA’s own guidance.

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.

Does the severe-incident track apply to you?

In plain terms: if you make hardware or software that is sold or supplied in the EU, the severe-incident duty applies now. That holds for products launched years ago and for products you no longer patch.

Your situation	Report under Art. 14(3)?	Inform users under Art. 14(8)?	Basis
You place products with digital elements on the EU market, including from outside the EU	Yes	Yes	Art. 14(3), (8); Art. 14(7) sets which CSIRT a non-EU manufacturer reports to
The product was placed on the market before 11 December 2027	Yes	Yes	Art. 69(3)
The product’s support period has ended	Yes	Yes	Commission guidance, para. 210
You are an open-source software steward providing the systems a project is developed on	Yes, for incidents affecting those systems	Yes	Art. 24(3); Commission guidance, para. 81
Medical devices, in-vitro diagnostics, vehicles type-approved under Regulation (EU) 2019/2144	No, the CRA does not apply	No	Art. 2(2)
You use the product but did not make it	No CRA duty	No	Check NIS2 Art. 23 instead

The third row is the one that surprises people. The Commission’s guidance on applying the CRA, C(2026) 5252 of 27 July 2026, says the reporting obligations “continue to apply after a product with digital elements is no longer supported”. A router you stopped patching in 2023 no longer needs vulnerability handling, but if your update server for it is compromised, you still have to report. The Commission’s CRA FAQs (entry 5.3) say the same for older products: you must notify, even where the old build tooling no longer exists. Conformity, CE marking and support periods are covered in our cyber resilience act compliance guide. This article covers the second reporting track and the user duty attached to it.

What makes an incident “severe”: the Article 14(5) test

In plain terms: the test asks what the incident could do to the product’s security, not whether anyone has been harmed yet. Two words, “capable of”, make a contained intrusion into your update pipeline reportable.

Start with the definitions. Article 3(44) defines an “incident having an impact on the security of the product” as one that affects, or could affect, the product’s ability to protect the availability, authenticity, integrity or confidentiality of “data or functions”. Article 14(5) then says when such an incident is severe. It needs only one of two limbs:

• (a) it negatively affects, or is capable of negatively affecting, that protection for sensitive or important data or functions; or
• (b) it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of a user.

Limb (a) adds a filter of its own, “sensitive or important”. Limb (b) does not need one, because malicious code reaching a product or a user’s systems is serious enough on its face. Recital 68 says what the drafters had in mind: an incident that “affects the development, production or maintenance processes of the manufacturer” in a way that could increase risk for users. The textbook case it gives is malicious code introduced “into the release channel via which the manufacturer releases security updates”.

There is one tension you should know about. The Commission guidance (para. 213) says a manufacturer becomes aware when it has “a reasonable degree of certainty” that a severe incident “has occurred and has led to the security of its product with digital elements being compromised”. Read literally, “has led to” is narrower than the statute’s “capable of”. One reading is that the guidance describes when the clock starts, not what counts as severe. The other is that it requires actual compromise. The guidance is non-binding and the Regulation’s text controls. Our view is that a stolen signing key engages limb (b) on the statute’s wording, so treat it as reportable and write down why.

Event	Limb engaged	Severe-incident track?
Malicious code inserted into a signed firmware update that reached customers	(b), has led	Yes. This is recital 68’s own example
Code-signing private key exfiltrated; no malicious build found yet	(b), capable of	Yes on the statute’s wording; record your reasoning given para. 213
Cloud back-end that authenticates deployed devices breached; admin tokens exposed	(a), important functions	Yes
Attacker had write access to the CI/CD pipeline for three days	(b), capable of	Likely yes; scope by which builds were reachable
Ransomware on finance and HR systems with no path to build, signing or product back-ends	Neither	No CRA report; check NIS2 and GDPR
A flaw in your shipped product exploited at a customer site	Usually neither	Normally the actively exploited vulnerability track (Art. 14(1)–(2)). Both tracks run if the attacker also got into your own infrastructure
A researcher reports a bug with no evidence of exploitation	Neither	No mandatory report; voluntary notification under Art. 15 is possible

The vulnerability track has its own test, which our guide to the actively exploited vulnerability under the CRA applies to nine cases, and its own rules on coordinated disclosure, covered in our zero-day disclosure guide. The rest of this article stays with incidents.

Three reports, three clocks

In plain terms: 24 hours for a short warning, 72 hours for the substance, one month after that for the full account. All three go simultaneously to the CSIRT designated as coordinator and to ENISA through the Single Reporting Platform (Art. 14(3) and (7)).

Report	Deadline	Minimum content (Art. 14(4))	What people get wrong
Early warning	Without undue delay, within 24 hours of becoming aware	Whether unlawful or malicious acts are suspected; where applicable, the Member States where the product is available	The “malicious acts” field is unique to this track. The vulnerability early warning does not have it
Incident notification	Within 72 hours of becoming aware, unless the information is already provided	Nature of the incident, initial assessment, measures taken, measures users can take, sensitivity	The user-measures field is the raw material for your Art. 14(8) notice
Final report	Within one month after the incident notification was submitted	Detailed description with severity and impact; type of threat or likely root cause; applied and ongoing mitigation	It runs from the notification, not from containment or a fix
Intermediate report	Only if the coordinator CSIRT asks (Art. 14(6))	Relevant status updates	It does not reset the final-report deadline

So if your incident notification goes in on 14 October, the final report is due by 14 November, finished investigation or not. The vulnerability track works differently: its final report waits until a corrective measure exists, plus 14 days. Both tracks are laid out on one worked timeline in our guide to CRA reporting requirements, and every field of Forms 4 to 6 is mapped against the platform in the CRA vulnerability reporting template guide.

When the clock starts. The guidance (paras. 212–214) times awareness from the end of a prompt initial assessment, and aligns the test with NIS2 Implementing Regulation 2024/2690 recital 31 and the EDPB’s GDPR breach guidelines. A team that already logs awareness for NIS2 or GDPR can reuse the same discipline. What it cannot do is let the assessment drift. Para. 214 puts “the emphasis” on prompt action.

Don’t trust the portal’s countdown. According to ENISA’s Single Reporting Platform FAQ (question 26), the 72-hour counter currently shows a due time 48 hours after you submit the early warning, not 72 hours after you became aware. As long as your early warning went in within 24 hours, the counter’s date can never fall later than the legal one. It still measures the wrong event, so keep your own awareness timestamp. The same FAQ (question 11) lists the incident fields the platform asks for: nature of the incident, mitigation, severity and impact, and threat or root cause.

Fines. Infringing Article 14 falls under the top tier of Article 64(2): up to €15 million or 2.5% of worldwide annual turnover, whichever is higher. Article 64(10)(a) spares micro and small enterprises from fines only for missing the 24-hour early-warning deadline. The 72-hour notification, the final report and the user notice are still owed. One drafting oddity: paragraph 10 derogates from “paragraphs 3 to 9”, while Article 14 fines sit in paragraph 2. Recital 120 states the intended exemption plainly, but confirm how your market surveillance authority applies it.

Article 14(8) read clause by clause

In plain terms: filing with ENISA does not tell your customers anything. Article 14(8) is a separate duty to them. It is mandatory for impacted users, risk-based in how far you go and silent on hours.

Words in Art. 14(8)	What it means in practice
“After becoming aware of … a severe incident”	Same trigger as the reporting duty. No 24- or 72-hour count is attached
“the manufacturer shall inform the impacted users”	Mandatory. No “where appropriate” qualifier applies to this group
“and where appropriate all users”	Widen the audience when you cannot tell who is affected, or when the risk justifies it
“where necessary, of any risk mitigation and corrective measures that the users can deploy”	If users can do something (update, rotate credentials, block a channel), say so concretely
“where appropriate in a structured, machine-readable format that is easily automatically processable”	Aimed at business users with vulnerability tooling. The law names no format
“Where the manufacturer fails to inform … in a timely manner”	The notified CSIRTs may inform users themselves where proportionate and necessary, and you lose control of the message

The Commission adds two limits that most commentary misses. Para. 220 says the duty applies “in a risk-based and proportionate manner” and “does not imply that such information must be made public or disclosed indiscriminately”. For products used in sensitive or essential environments, you may limit detail to the customers concerned, because public technical detail could help further attacks. Para. 221 says broader disclosure may be appropriate once the incident is addressed. Two provisions pull the other way. Under Article 17(2), where public awareness is necessary, the coordinator CSIRT may, after consulting you, inform the public or require you to do so. And recital 67 gives the default channels: publishing on your website, or contacting users directly where you can and the risk justifies it.

Compare the timing words with the two regimes your legal team already knows:

	CRA Art. 14(8)	NIS2 Art. 23(1)	GDPR Art. 34(1)
Who is told	Impacted users; all users where appropriate	Recipients of services, where appropriate	Data subjects
Trigger	Aware of a severe incident or actively exploited vulnerability	Significant incident likely to adversely affect the service	Breach likely to result in high risk
Timing words	None; “timely” appears only in the CSIRT backstop	“without undue delay”	“without undue delay”

The NIS2 Directive and the GDPR both say “without undue delay”. The CRA does not. No fixed deadline is not the same as no deadline, though: the test is whether you informed users “in a timely manner”, judged by a CSIRT holding your own 72-hour notification.

When to send the user notice: a sequence that holds up

Our recommendation: send the first user notice no later than your 72-hour incident notification, unless you document a containment reason to hold it. The logic is simple. By hour 72, Article 14(4)(b) has already made you write down the “corrective or mitigating measures that users can take” for the CSIRT. Once those words exist, giving them to a regulator but not to the people who can act on them is hard to call timely. The CSIRT can also forward them itself. The exception is para. 220: in sensitive deployments, brief the affected customers directly first and publish later.

1. T+0 (Low effort): record the awareness timestamp, meaning the moment of reasonable certainty, not first detection. Owner: PSIRT lead.
2. By T+24 h (Medium): file the early warning, and decide in writing whether the notice goes to impacted users only or to all users. Owner: CRA officer with Legal.
3. By T+72 h (Medium): file the incident notification. Build the user notice from its user-measures field, so there is one source of truth, and send it through channels users actually read: registered-customer email, in-product messages, distributors. Owner: PSIRT with Communications.
4. Where appropriate (High, first time): publish a machine-readable advisory next to the human-readable one. CSAF 2.0, the OASIS JSON advisory standard, is the common choice for business customers, but neither the CRA nor the Commission names it. Owner: PSIRT.
5. Within one month of the notification (Medium): update the notice as facts change, and record the date and channel of every user notice in the final report file. Owner: CRA officer.

On language, Article 14(8) says nothing, and the platform itself accepts English only (ENISA FAQ question 24). Article 13(18) does require your user instructions to be in “a language which can be easily understood by users”. Sending the incident notice in those same languages is the defensible default.

Role	Owns	Watch-out
CISO / PSIRT lead	Awareness timestamp, severity call, technical content of the notice	Don’t hold the 72-hour notification or the user notice for a root cause. That belongs in the final report
Compliance / Legal	Parallel-regime check, audience decision, evidence file	Every “where appropriate” choice needs a written reason
Board / management	Approving any decision to limit disclosure under para. 220	If users are not told in time, the CSIRT can tell them for you
SME owner	Making sure someone can file at 02:00 on a Sunday	A micro or small company is not fined for a late early warning, but the 72-hour notification, final report and user notice are still owed

One incident, three regimes

A manufacturer that is also a NIS2 entity, such as a managed service provider that ships its own endpoint agent, can trigger three filings with one compromise. Those are a CRA notification through the platform, an article 23 incident notification to its national CSIRT, and a GDPR Article 33 notice if personal data was breached. They are separate reports with different addressees and content, and one does not discharge another. The early warnings do line up, since NIS2 Article 23(4)(a) also asks whether unlawful or malicious acts are suspected, so draft that sentence once.

There is also a commercial reason to write a good user notice. Many of your business customers are NIS2 entities, and they will use your Article 14(8) notice to decide whether your incident is a significant incident for them. That is the problem our supply chain incident response guide works through from the customer’s side. A vague notice leaves them guessing, and it costs your account managers a week of calls. One last limit: Article 17(4) protects the act of notifying the CSIRT and ENISA from “increased liability”, but it says nothing about what you tell customers. Have Legal review the user notice before it goes out, though not at the expense of its timing.

Readiness checklist for the severe-incident track

• A written severity test that quotes Article 14(5) and records “capable of” decisions, such as a stolen key or pipeline access. Owner: PSIRT lead.
• An awareness log that captures the reasonable-certainty moment separately from first detection. Owner: PSIRT lead.
• At least two people with working platform accounts who can file the early warning out of hours. Owner: CRA officer.
• A user notice template plus a current list of channels: customer registry, distributors, in-product messaging, advisory URL. Owner: Communications.
• A pre-approved rule for when the audience widens from impacted users to all users, and who approves limiting disclosure. Owner: Management.
• Coverage for legacy and out-of-support products, because reporting outlives both (Art. 69(3); guidance para. 210). Owner: Product management.
• A parallel-regime check (NIS2, GDPR, contracts) done within the first 24 hours. Owner: Legal / DPO.

Frequently asked questions

Is there a deadline for informing users under CRA Article 14(8)?

Not a fixed one. Article 14(8) applies “after becoming aware” and attaches no hours. The practical limit is “timely”: if you fail to inform users in a timely manner, the notified CSIRTs may inform them. We recommend informing users no later than your 72-hour incident notification unless you document a reason to wait.

Does informing users mean publishing a public security advisory?

Not necessarily. The Commission’s guidance (para. 220) says the duty “does not imply that such information must be made public”. Where public detail could raise risk, you may limit it to the users or customers concerned. A CSIRT can still require public communication under Article 17(2).

Does the CRA require reporting severe incidents for products sold before December 2027?

Yes. Article 69(3) applies Article 14 to all in-scope products placed on the market before 11 December 2027, and the guidance adds that reporting continues after the support period ends.

Are small companies exempt from CRA incident reporting?

No. Article 64(10)(a) only removes fines for micro and small enterprises that miss the 24-hour early-warning deadline. The 72-hour notification, the final report and the user notice still apply.

Is a ransomware attack on our office network a CRA severe incident?

Only if it reaches something that protects your product’s security, such as build systems, signing keys, update servers or device back-ends. Ransomware confined to corporate IT is usually a NIS2 or GDPR question, not a CRA one.

Sources

1. Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal text — EUR-Lex. Articles 2(2), 3(44), 13(18), 14(1)–(8), 15, 17(2) and 17(4), 24(3), 64(2) and 64(10), 69(3), 71(2); recitals 67, 68 and 120.
2. Commission guidance on the application of Regulation (EU) 2024/2847, Annex to C(2026) 5252 of 27 July 2026 — European Commission. Paragraphs 81 and 209–221.
3. FAQs on the Cyber Resilience Act, version 1.1 of 17 December 2025 — European Commission services. Entry 5.3.
4. CRA Single Reporting Platform: Frequently Asked Questions — ENISA, consulted 19 October 2026. Questions 11, 24 and 26.
5. Cyber Resilience Act: reporting obligations — European Commission, consulted 19 October 2026.
6. Directive (EU) 2022/2555 (NIS2 Directive), Official Journal text — EUR-Lex. Article 23(1), (2) and (4).
7. Regulation (EU) 2016/679 (GDPR), Official Journal text — EUR-Lex. Articles 33(1) and 34(1).
8. Common Security Advisory Framework Version 2.0, OASIS Standard — OASIS Open.