CRA Article 14 reporting: triggers, stages and deadlines

The legal statements below were checked on 21 October 2026 against the Official Journal text of Regulation (EU) 2024/2847 and its corrigenda. This page is information, not legal advice. It does not determine whether a particular case is reportable.

A report starts with a decision about what happened. A deadline calculator cannot make that decision for you.

Start with the trigger

Article 14 places the reporting duty on manufacturers of products with digital elements within the CRA's scope (Article 14(1), (3); scope: Article 2). The duty covers two cases. One is an actively exploited vulnerability contained in the product. The other is a severe incident having an impact on the security of the product (Article 14(1), (3)).

Article 14 applies from 11 September 2026 (Article 71(2)). It applies to all products within scope, including products placed on the market before 11 December 2027 (Article 69(3)).

An actively exploited vulnerability is "a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner" (Article 3(42)). A scanner finding or a database entry alone does not necessarily establish those facts. That is an interpretation, not another definition in the Regulation. Keep the evidence separate from your assessment of what it establishes.

An incident is severe if it negatively affects, or is capable of negatively affecting, the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions (Article 14(5)(a)). It is also severe if 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 of the product (Article 14(5)(b)). Use the full statutory wording for the assessment. A short label in a case record cannot replace it.

Awareness starts the first two clocks

The first question for your timeline is when the manufacturer became aware. Both the 24-hour and 72-hour limits run from the manufacturer becoming aware of the actively exploited vulnerability or severe incident (Article 14(2)(a)–(b), (4)(a)–(b)).

Submitting the early warning does not start a fresh 72-hour period. Both stages also require action "without undue delay". The hour limits are outer limits, not permission to wait.

Put what became known, when it became known and the evidence in the case record. Name the person responsible for the decision. Keep the factual awareness time separate from the time the record was created. The interpretation here is that a later entry does not move the awareness time.

For the final report, look at a different event.

For a vulnerability, the 14 days run from the availability of a corrective or mitigating measure, not from awareness (Article 14(2)(c)). For an incident, the one month runs from the submission of the incident notification, not from awareness (Article 14(4)(c)). Keep those events in separate fields.

Prepare the vulnerability report in stages

The early warning indicates, where applicable, the Member States on whose territory the manufacturer is aware that the product has been made available (Article 14(2)(a)).

For the vulnerability notification, provide general information, as available, about the product concerned and the general nature of the exploit and of the vulnerability. Include any corrective or mitigating measures taken, and corrective or mitigating measures that users can take. Where applicable, indicate how sensitive the manufacturer considers the notified information to be (Article 14(2)(b)).

The final report includes at least: a description of the vulnerability, including its severity and impact; where available, information about any malicious actor that has exploited or is exploiting the vulnerability; and details about the security update or other corrective measures made available to remedy the vulnerability (Article 14(2)(c)(i)–(iii)).

Separate confirmed findings from open questions in the final report. Keep the evidence for each conclusion. If the attacker's identity is an assumption, say so.

Prepare the severe-incident report

The early warning includes at least whether the incident is suspected of being caused by unlawful or malicious acts. Where applicable, it also indicates the Member States on whose territory the manufacturer is aware that the product has been made available (Article 14(4)(a)).

For the incident notification, provide general information, where available, about the nature of the incident and an initial assessment of the incident. Include any corrective or mitigating measures taken, corrective or mitigating measures that users can take and, where applicable, how sensitive the manufacturer considers the notified information to be (Article 14(4)(b)).

The final report includes at least: a detailed description of the incident, including its severity and impact; the type of threat or root cause that is likely to have triggered the incident; and applied and ongoing mitigation measures (Article 14(4)(c)(i)–(iii)).

Where necessary, the CSIRT designated as coordinator that first received the notification may request an intermediate report on relevant status updates (Article 14(6)). The first submission is not the end of the work. Keep someone responsible for updates.

Where reports go, and how users are informed

Notify the CSIRT designated as coordinator and ENISA simultaneously, via the single reporting platform established under Article 16 (Article 14(1), (3)).

The notification uses the electronic notification end-point of the CSIRT designated as coordinator of the Member State where the manufacturer has its main establishment in the Union (Article 14(7)).

The main establishment is where decisions related to the cybersecurity of the products are predominantly taken; if that cannot be determined, it is the establishment with the highest number of employees in the Union. Manufacturers with no main establishment in the Union follow a fixed order in Article 14(7). See the platform guide before preparing the submission route.

Reporting to authorities does not replace informing users. After becoming aware, the manufacturer must inform the impacted users and, where appropriate, all users, of the vulnerability or incident and, where necessary, of any risk mitigation and corrective measures they can deploy (Article 14(8)). Where appropriate, this information is given in a structured, machine-readable format that is easily automatically processable (Article 14(8)). Tell users what they can do. Make it clear which measure is available and which is still being developed.

Worked example: two separate final-report dates

This is an invented example, not an assessment of a real case. All times below use UTC.

The sequence is signal → awareness → early warning within 24 hours → notification within 72 hours → final report no later than 14 days after a corrective or mitigating measure is available (Article 14(2)(a)–(c)). The first two limits run from awareness and both require action without undue delay (Article 14(2)(a)–(b)). Assess what the signal establishes before using an awareness time. The example starts after that assessment; it does not decide when a real signal amounts to awareness.

Assume awareness of an actively exploited vulnerability at 10:00 on Monday 2 November 2026. Count elapsed hours from that point. The outer limits are 10:00 on 3 November for the early warning and 10:00 on 5 November for the notification. Treat these as the planning limits.

Now assume a mitigating measure becomes available on Friday 6 November. The final report is then due by the end of Friday 20 November, even if a permanent fix comes later.

Now assume a separate severe incident with the same awareness time. Its first two outer limits are the same. Submit the incident notification on 4 November in this example, and the final report is due by the end of 4 December. Use the actual submission date, not the latest permitted notification time (Article 14(4)(c)).

The dates above follow the counting rules in Article 3 of Regulation (EEC, Euratom) No 1182/71: the day of the event is not counted, and a month ends on the same date in the following month. The CRA does not itself refer to that Regulation. Under its Article 3(4), a period in days or months that ends on a Saturday, Sunday or public holiday runs to the end of the next working day; hour-based limits are not extended. Check public holidays and time zones before treating the calculation as a legal deadline.

What Article 14 does not require

Article 14 does not make every vulnerability finding a mandatory report; the duty concerns actively exploited vulnerabilities (Article 14(1); Article 3(42)). Nor does it treat every incident as severe (Article 14(3), (5)). Voluntary reporting has a separate basis in Article 15.

The early warning does not require a completed root-cause investigation; the likely root cause belongs in the incident final report (Article 14(4)(c)(ii)). Do not wait for a permanent fix where a mitigating measure has already started the vulnerability final-report period (Article 14(2)(c)). Saving the draft does not submit it. Keep a separate record of the submission.

Check the reporting duty separately from the question of fines. Article 64(10)(a), as corrected by OJ L 2025/90555, excludes administrative fines for manufacturers that qualify as micro or small enterprises for a missed 24-hour early-warning deadline. It does not remove the reporting duty itself.

Sources

• Regulation (EU) 2024/2847 (opens in a new tab), Official Journal text (Publications Office): Article 2(1), Article 3(42), Article 14(1)–(8), Article 15, Article 16(1), Article 64(10), Article 69(3), Article 71(2).
• Corrigendum OJ L 2025/90555 (opens in a new tab) of 2 July 2025: in the English text it corrects only Article 64(10) ("paragraphs 2 to 9" instead of "3 to 9"). The other English corrigenda (OJ L 2024/90780, title; OJ L 2025/90828, Article 67) do not affect Article 14.
• Regulation (EEC, Euratom) No 1182/71 (opens in a new tab): Article 3, rules for periods, dates and time limits.
• European Commission: Cyber Resilience Act — Reporting obligations (opens in a new tab) (read 21 October 2026).
• ENISA: Single Reporting Platform (opens in a new tab) (read 21 October 2026).

For a date worksheet, use the crAcken reporting deadline calculator.