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

· Eurtifact Platform Team

Context

Most of the Cyber Resilience Act applies from 11 December 2027. Article 14 — reporting obligations of manufacturers — applies fifteen months earlier, from 11 September 2026. It is the first part of the Regulation to bind manufacturers operationally, and it does so on tight, fixed timelines.

The clock starts at “becomes aware.” It cannot be stopped by triage workflows, weekends, or internal sign-off processes. This article walks through what the OJ text actually requires, where most organisations underestimate the obligation, and what infrastructure has to exist before September 2026 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)© gives severe incidents one month for the final report, whereas Article 14(2)© 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
  • © 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
  • © 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 “aware” with a single rule, but reading Article 14 together with Annex I Part II point (5) — which requires a coordinated vulnerability disclosure policy — and Article 13(8) on the support period, the operational reading is:

  • A vulnerability reported through your CVD policy: awareness begins at intake, not at triage completion.
  • An indicator of compromise from your own telemetry: awareness begins when an analyst confirms the indicator is real, not when an executive is briefed.
  • A report from a customer or downstream user: awareness begins at receipt by the manufacturer’s organisation, not by the specific team that owns the product.

Internal escalation latency counts against the 24-hour clock. There is no provision in Article 14 that pauses the clock 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.

Failure Modes

Pattern 1: Triage as a Gating Function

A vulnerability comes in. Engineering wants to confirm exploitability before notifying. By the time the assessment is complete, 36 hours have passed. The 24-hour clock was already breached at hour 25.

The 24-hour notification is an early warning (Art. 14(2)(a)), not a determination of severity. The 72-hour notification is where the manufacturer’s assessment is conveyed. Treating triage as a precondition to the 24h notification compresses every assessment into an impossible window.

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 “awareness” is recognised — CVD policy intake, security telemetry alerts, customer support tickets tagged “security.” Each writes an immutable timestamp at intake.

  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) that is on the ENISA single reporting platform’s allowlist, with backups and clear escalation if the primary cannot act within the window.

  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. The deadline starts before that judgment is final.
  • 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 binds from 11 September 2026 — fifteen months ahead of full CRA application. It is the first directly operational obligation manufacturers face.
  • 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 24h early warning is not a triage output. It can and must be sent with limited information; the 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.
  • “Awareness” needs to be a recorded event. Without timestamped intake, the 24h clock cannot be defended.

This article reflects the Eurtifact platform team’s reading of the Cyber Resilience Act as of May 2026. Article and Annex references were verified against the consolidated EUR-Lex text (CELEX 32024R2847) and are linked to the on-site CRA explorer. It is not legal advice. For obligations specific to your products, consult qualified legal counsel.