CRA Article 14: The 24h/72h/14-day Reporting Clock You Cannot Reset

· Updated · Yunus Yildiz

Updated 16 September 2026. First published in May 2026. This version follows the Commission's guidance C(2026) 5252 of 27 July 2026 and FAQ v1.4 of 4 September 2026, which define when a manufacturer "becomes aware" and which vulnerabilities are reportable at all, and ENISA's guidance of 12 September 2026 on registering with the reporting platform. The earlier version said awareness begins when a report is received and advised registering on the platform in advance. Both points are corrected below.

Context

Most of the Cyber Resilience Act applies from 11 December 2027. Article 14 — reporting obligations of manufacturers — has applied since 11 September 2026, fifteen months earlier. It is the first part of the Regulation to bind manufacturers operationally, and it does so on tight, fixed timelines. Under Article 69(3) it also covers products placed on the market before December 2027, not only new ones.

The clock starts when the manufacturer "becomes aware". Once it has started, nothing in Article 14 pauses it for weekends or internal sign-off. This article walks through what the OJ text and the Commission's guidance actually require, where organisations misread the obligation in both directions, and what has to exist for the deadlines to be met without panic.

Reality Check

Common Belief

"We have an incident response runbook, so we are ready for Article 14."

Why That's Incomplete

Article 14 is not an incident response obligation in the NIS2 sense, and it is not satisfied by an internal runbook alone. Three things make it specific:

  • Simultaneous reporting: The notification must go simultaneously to the CSIRT designated as coordinator under Article 14(7) and to ENISA — not to one then the other.
  • Single platform: Both reports are made via the single reporting platform established by Article 16, operated by ENISA. The platform routes the notification onward to the CSIRTs in the Member States where the product is made available.
  • Two distinct trigger events with different clocks: An actively exploited vulnerability (Art. 14(1)) and a severe incident (Art. 14(3)) each have their own 24h/72h/final-report sequence. Article 14(4)(c) gives severe incidents one month for the final report, whereas Article 14(2)(c) gives vulnerabilities 14 days after a corrective or mitigating measure is available.

A runbook that conflates the two will fail at least one of the clocks.

Engineering Implications

The Two Clocks, Decomposed

For an actively exploited vulnerability — Article 14(2):

  • (a) Early warning notification — within 24 hours of becoming aware, indicating Member States where the product has been made available
  • (b) Vulnerability notification — within 72 hours of becoming aware, with general information about the product, the nature of the exploit, mitigations taken, and mitigations users can take
  • (c) Final report — no later than 14 days after a corrective or mitigating measure is available, including severity, impact, malicious actor information where available, and details of the security update

For a severe incident — Article 14(4):

  • (a) Early warning — within 24 hours of becoming aware, including whether the incident is suspected of being caused by unlawful or malicious acts
  • (b) Incident notification — within 72 hours of becoming aware, with general information about the incident, an initial assessment, and mitigations
  • (c) Final report — within one month after the submission of the incident notification, including a detailed description, root cause, and applied/ongoing mitigations

Article 14(5) defines "severe": an incident is severe where it negatively affects (or can negatively affect) the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or where it has led, or is capable of leading, to malicious code being introduced into a product or network. The threshold is broad. "Severe" does not mean "headline-grade."

What "Aware" Means in Practice

The Regulation does not define "becoming aware". The Commission's guidance does, aligned with how the same term is read under NIS2 and the GDPR. When a manufacturer detects a suspicious event, or a customer, researcher, authority or anyone else brings one to its attention, it "should assess the suspicious event immediately". It is "to be regarded as having become aware when, after such an initial assessment, it has a reasonable degree of certainty" that a vulnerability in its product is being actively exploited, or that a severe incident has compromised the product's security (guidance C(2026) 5252, para. 213).

Three consequences follow:

  • The clock does not start at intake, but the assessment must. Receiving a report starts an obligation to assess promptly, not the 24-hour clock. The guidance stresses "prompt action to carry out the initial assessment", particularly where the risk may be significant (para. 214). A report left in a queue for a week is not an assessment that is still running.
  • Most CVD reports are not reportable at all. A vulnerability found by ethical hackers or a testing lab, with no evidence of previous malicious exploitation, "is not an actively exploited vulnerability subject to mandatory reporting" (FAQ v1.4, 5.2; Recital 68). Article 14 is about exploitation, not discovery. You can still notify it voluntarily under Article 15.
  • Component vulnerabilities count only if they are exploited in your product. If a third-party component contains a vulnerability that cannot be exploited in your product (for example, the vulnerable code is not reachable) or has not been exploited there, it is not reportable for you. You still owe Annex I Part II vulnerability handling and an upstream report under Article 13(6) (guidance para. 218).

There is no retroactive reporting: exploitation you were already aware of before 11 September 2026 is not reportable, but exploitation that begins, or that you learn about, after that date is (para. 217). And once you are aware, internal escalation latency counts against the 24-hour clock; Article 14 has no provision that pauses it for working hours or weekends.

The Single Reporting Platform

Article 16 requires ENISA to establish and maintain a single reporting platform for notifications under Article 14 and Article 15 (voluntary reporting). The architecture allows Member States and ENISA to operate their own electronic notification end-points. From a manufacturer's perspective, this means:

  • A single technical integration target rather than 27 national CSIRTs.
  • Routing to relevant Member States happens after submission; the manufacturer indicates which Member States are concerned (Article 14(2)(a)).
  • Article 16(2) allows the receiving CSIRT to delay dissemination "in exceptional circumstances" and "based on justified cybersecurity-related grounds for a period of time that is strictly necessary" — for example where a vulnerability is subject to a coordinated vulnerability disclosure procedure under Article 12(1) of NIS2 (Directive (EU) 2022/2555). The manufacturer can flag sensitivity under Article 14(2)(a), but the delay decision is the CSIRT's.
  • The notification goes to the CSIRT designated as coordinator in the Member State of your main establishment (Article 14(7)). For a manufacturer established in the Netherlands, that is the NCSC.
  • Do not register pre-emptively. ENISA advises manufacturers "to register and initiate the validation process only when they need to submit a specific notification, rather than registering pre-emptively". The coordinating CSIRT's validation of who may report for a manufacturer "is not a prerequisite for submitting a notification". Access requires an EU Login account with multi-factor authentication (ENISA, 12 September 2026).

Failure Modes

Pattern 1: An Initial Assessment That Never Ends

A report of exploitation comes in. It sits in a queue over the weekend, then waits for the one engineer who knows the component. Each delay feels reasonable, and none of them is an assessment. The guidance ties awareness to an initial assessment that is carried out promptly; an organisation that stretches the assessment to postpone the clock will struggle to show it acted as the guidance expects.

The opposite mistake is just as common: waiting for a full severity analysis after certainty is already reasonable. The 24-hour notification is an early warning (Art. 14(2)(a)) with limited information. The fuller assessment belongs in the 72-hour notification, and the complete picture in the final report.

Pattern 2: Single Point of Failure on the Reporting Channel

The team handling submissions to the single reporting platform has no defined backup. An incident on a Friday evening with the primary person on leave means the 24-hour notification is sent late.

Article 14 places the obligation on the manufacturer, not on individual employees. The competent national authorities will not accept "the on-call rotation had a gap" as mitigation.

Pattern 3: No Trail of Awareness

A regulator asks: "When did you first become aware of this vulnerability?" The answer cannot come from a Slack search done six months later. Awareness needs to be a recorded event: ticket creation timestamp, monitoring alert ID, email receipt timestamp.

If awareness is not durably recorded, the burden of proving compliance with the 24-hour clock falls on documents that did not exist when they were needed.

Pattern 4: Conflating Article 14 With NIS2 Reporting

NIS2 (Directive (EU) 2022/2555) Article 23 imposes reporting obligations on essential and important entities. Article 14 of the CRA imposes obligations on manufacturers of products with digital elements. These overlap (the same incident can trigger both) but they have different reporting bodies, different scopes, and different deadlines.

A "NIS2 report" filed with the national CSIRT does not discharge the CRA obligation to notify ENISA simultaneously through the single reporting platform.

What "Good" Looks Like

A manufacturer that can meet Article 14 without heroics has these properties:

  1. Awareness instrumentation: A defined set of channels through which suspicious events arrive — CVD policy intake, security telemetry alerts, customer support tickets tagged "security". Each records two immutable timestamps: when the event was received, and when the initial assessment reached reasonable certainty. The gap between them is the evidence that the assessment was prompt.

  2. Pre-submitted Member-State scope: For each product, the list of Member States where it is made available is maintained as data, not pulled together during an incident. Article 14(2)(a) requires this in the 24h notification.

  3. Pre-authored notification templates: The 24h early warning contains a narrow set of fields. They are filled by populating the template, not by drafting from scratch under pressure.

  4. A defined notifier-of-record: A named role (not a person), with backups, that holds an EU Login account with multi-factor authentication and has rehearsed registering on the single reporting platform. Following ENISA's advice, the registration itself happens when a notification is actually needed, so the rehearsal is what has to exist in advance.

  5. Clock as a first-class metric: Time-to-24h-notification is measured, not assumed. Internal SLA: notification submitted by the 18-hour mark, leaving six hours of slack for failures.

  6. Audit trail for CVD interactions: When CSIRT Article 16(2) discretion applies (delayed dissemination during a CVD procedure), the manufacturer needs records of the request and decision to demonstrate it acted in good faith.

Limits & Trade-offs

This does not:

  • Make the deadlines safe: The 24h clock is genuinely tight for a globally distributed organisation. Compliance reduces risk; it does not eliminate it.
  • Cover Article 11 obligations to consumers: Article 11 governs the relationship with the General Product Safety Regulation. Where the same defect creates a safety risk to consumers, additional reporting under Regulation (EU) 2023/988 may apply.
  • Substitute for legal review: Whether a specific finding qualifies as an actively exploited vulnerability under Art. 14(1), or as a severe incident under Art. 14(5), is a judgment call that benefits from internal counsel. Legal review can inform the initial assessment; it cannot be used to delay it.
  • Cover voluntary reporting: Article 15 allows voluntary reporting of vulnerabilities and incidents not covered by Article 14. Some organisations will choose to use it; the platform is the same.

Key Takeaways

  • Article 14 has bound manufacturers since 11 September 2026, fifteen months ahead of full CRA application, and covers products already on the market (Art. 69(3)). Exploitation you knew about before that date is not reportable.
  • Two distinct trigger events: actively exploited vulnerabilities (Art. 14(1)) and severe incidents (Art. 14(3)). Each has its own 24h/72h sequence and its own final-report deadline (14 days for vulnerabilities, one month for incidents).
  • The clock starts after a prompt initial assessment gives reasonable certainty of active exploitation or a severe incident. Undisclosed discovery without exploitation, and unreachable component vulnerabilities, are not reportable.
  • The 24h early warning carries limited information; the fuller assessment goes in the 72h notification.
  • Reporting is simultaneous to the CSIRT coordinator (Art. 14(7)) and to ENISA, via the single reporting platform. NIS2 reports do not discharge it.
  • Record both the moment a report arrives and the moment the assessment reached certainty. Without both, neither the promptness of the assessment nor the 24h clock can be defended.
  • Do not pre-register on the reporting platform; have an EU Login with MFA ready and register when you need to notify.

Sources

  • Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 13, 14, 15, 16 and 69: on-site OJ text, EUR-Lex
  • European Commission, guidance on the implementation of Regulation (EU) 2024/2847, C(2026) 5252, 27 July 2026, section 9.1, paras. 212–218: announcement
  • European Commission, CRA implementation FAQ, version 1.4, 4 September 2026, FAQ 5.2 and 5.4: FAQ page
  • ENISA, CRA Single Reporting Platform guidance on user registration, 12 September 2026: ENISA

This article reflects the Eurtifact platform team's reading of the Cyber Resilience Act, first published May 2026 and updated 16 September 2026 against the sources above. Article and Annex references are linked to the on-site CRA explorer. It is not legal advice. For obligations specific to your products, consult qualified legal counsel.