CRA Reporting Obligations: Anatomy of a Notification, from Hour 0 to the Final Report

Tuesday, 4:47 PM. In the security inbox of a manufacturer of connected control units, an email arrives: a security researcher describes a vulnerability in the firmware, with proof of concept, and points to attacks he has already observed in the wild.

Until 10 September 2026, this would be an internal problem. From 11 September 2026 onwards, it becomes a regulatory one: on that date, the reporting obligation under Article 14 of the Cyber Resilience Act kicks in — and it counts in hours.

This article walks through the entire notification process chronologically: from the first suspicious email to the final report. Along the way, we examine the points where reporting processes break down in practice: the start of the deadline, the parallel obligation to your users, the reporting pathway via the new EU platform, and the question of who reports when the vulnerability is in a third-party component.

The Legal Situation in Four Sentences

The Cyber Resilience Act (Regulation (EU) 2024/2847) has been in force since 10 December 2024 and applies in full from 11 December 2027. Two sets of obligations start earlier: from 11 June 2026, the rules on notifying conformity assessment bodies apply; from 11 September 2026, the manufacturer reporting obligations under Article 14.

Two types of events must be reported: actively exploited vulnerabilities in the product and severe incidents affecting the security of the product. Recipients are simultaneously the national CSIRT designated as coordinator and ENISA.

And the point that throws off many manufacturers’ planning: Article 69(3) extends exactly this obligation to all products with digital elements placed on the EU market before 11 December 2027. For the reporting obligation, what counts is the installed base in the market — regardless of when it was manufactured.

Hour 0: When the Clock Starts

Back to the 4:47 PM email. Is the 24-hour deadline already running?

Not necessarily yet. The Commission clarifies in its CRA guidance (draft version): knowledge within the meaning of Article 14 exists when the manufacturer, following an initial assessment of the suspicious event, can conclude with reasonable certainty that an active exploitation or a severe incident has occurred. The deadline starts with the outcome of this initial assessment; mere suspicion is not sufficient.

The guidance also closes the obvious shortcut: the initial assessment must not be delayed in order to postpone the start of the deadline. A manufacturer who leaves the researcher’s email sitting for 3 days has already missed the deadline.

Operationally, this means: you need a designated role authorised to determine that awareness has been established, and a timestamp for that decision. In a dispute with a market surveillance authority, the documented initial assessment is your most important piece of evidence.

In our scenario, the product security team confirms the exploitation on Wednesday morning. 10:30 AM, decision documented. The clock is running.

Hour 24: The Early Warning

By Thursday, 10:30 AM, the early warning must be submitted. It is deliberately lean: the basic information that an actively exploited vulnerability or a severe incident exists, the affected product, and, where applicable, the member states in which the product is known to the manufacturer to have been made available.

That last point is routinely overlooked and is nearly impossible to fulfil without preparation: which sales data can tell you, within a morning, in which EU countries a specific product version is deployed in the field?

One reassurance for process design: you only report once. The notification is submitted via the central reporting platform and simultaneously reaches the CSIRT and ENISA. You do not need to maintain two separate reporting channels.

Hour 72: The Vulnerability or Incident Report

By Saturday morning, the second stage follows. It supplements the early warning with general information about the product, the nature of the exploitation or incident, an initial assessment, and the remediation and mitigation measures taken.

Two details from the regulatory text deserve attention. First: the report must also identify measures that users can take themselves. You are therefore already drafting the initial version of your customer communication. Second: the manufacturer can indicate how sensitive they consider the reported information. This classification is the basis on which the onward distribution of the report may be delayed in exceptional cases (more on this below).

A Second Clock Is Running in Parallel: Your Users

Article 14 does not end with the authorities — and this part is missing entirely from many CRA project plans. Paragraph 8 obliges the manufacturer, upon becoming aware, to inform the affected users, where necessary all users: about the vulnerability or incident and about remediation and mitigation measures that users can implement themselves. Where appropriate, this should be done in a structured, machine-readable format.

The regulation has built in an uncomfortable fallback for non-compliant manufacturers: if you fail to inform your users in time, the notified CSIRT can do so on your behalf. Your customers would then learn about the vulnerability in your product from an authority rather than from you.

In practice, paragraph 8 means: prepared advisory templates, a publication channel that customers are familiar with, and the ability to identify affected users down to the version level. Anyone who only starts thinking about what a security advisory looks like when an incident occurs will lose exactly the hours that Article 14 does not provide.

Day 14 or Month 1: The Final Report

The two triggers diverge at the end of the cascade. For an actively exploited vulnerability, the final report is due no later than 14 days after a remediation or mitigation measure becomes available: a description of the vulnerability with severity and impact, information on exploiting actors (where available), and details of the security update.

For a severe incident, 1 month is available from the 72-hour report, but with more substance: a detailed incident description, the nature of the threat or probable cause, and the ongoing and completed countermeasures. The longer deadline buys the root-cause analysis.

In the interim, the authority is not silent: the coordinating CSIRT may request interim progress reports. Your process must therefore be capable of providing information at any time, beyond the 3 reporting stages.

The Reporting Channel: One Platform, One Endpoint, Clear Jurisdiction

Technically, all notifications are submitted via the central reporting platform (Single Reporting Platform) that ENISA is building under Article 16. It is due to be operational by 11 September 2026, with a test phase beforehand. You should not wait for it, however: the obligation applies from the deadline, and your internal process (triage, decision, content, approvals) is independent of the platform.

The responsible endpoint is the CSIRT in the member state where your company has its main EU establishment. For manufacturers without an EU establishment, Article 14(7) defines a cascade: first the member state of the authorised representative, then the importer, then the distributor, and finally the state with the most users. Manufacturers based outside the EU should clarify this allocation before an incident occurs, not during one.

Upon receipt, the first-receiving CSIRT distributes the report via the platform to the CSIRTs of the member states where the product has been made available, and supplies the market surveillance authorities with the necessary information. In exceptional cases — for example, during ongoing coordinated disclosure or where particular sensitivity applies — this onward distribution may be temporarily withheld on justified cybersecurity grounds. A notification therefore triggers a European distribution system and does not remain in any single inbox.

The Vulnerability Is in a Component: Who Reports?

Modern products consist largely of third-party code. If the actively exploited vulnerability is in an integrated component, the product manufacturer remains subject to the reporting obligation; if the component was made available on the market separately, its manufacturer has its own reporting obligation. The regulation also expects manufacturers to report identified vulnerabilities back to the party responsible for the component.

The question “are we affected?” can only be answered with accurate bills of materials. The Software Bill of Materials (SBOM) — which Annex I Part II already requires — is therefore also the backbone of your reporting capability: without machine-readable knowledge of which component is in which product version, even the 72-hour report becomes a research exercise.

What a Failure Costs

Article 64(2) subjects violations of Articles 13 and 14 to fines of up to EUR 15 million or, for companies, up to 2.5% of total worldwide annual turnover from the preceding year, whichever is higher. The reporting obligation therefore sits in the highest penalty tier of the regulation, on a par with violations of the essential cybersecurity requirements in Annex I.

The regulation provides some relief for smaller companies: micro- and small enterprises within the meaning of Recommendation 2003/361/EC will not be penalised with fines for missing the 24-hour early warning, company size feeds into every penalty calculation, and open-source stewards are fully exempt from fines. The reporting obligation itself, however, applies to everyone. Manufacturers who are uncertain may ask their national CSIRT directly: the regulation obliges national CSIRTs to support manufacturers — particularly SMEs — with their reporting obligations.

Why 11 December 2027 Does Not Help You Here

The obligations around coordinated disclosure from Annex I Part II (CVD policy, contact address for vulnerability disclosures, central point of contact for users) only become legally binding with full applicability on 11 December 2027. You should not rely on that buffer.

The reason is stated above: awareness is the trigger for the 24-hour deadline, and external notifications from researchers, customers, or CSIRTs are among the most common ways awareness arises. A manufacturer without a functioning reporting channel is installing the smoke detector after the fire: the deadline starts running anyway — just unnoticed. A published reporting pathway (such as a security.txt file per RFC 9116 plus a monitored security inbox) therefore belongs among the first work packages, not the last.

Three Capabilities That Determine Your Reporting Readiness

The requirements from the chronology above can be condensed into 3 capabilities. These are the honest measure of your own maturity level.

Portfolio transparency. You know at all times which products and versions with digital elements are on the EU market, in which member states, with which components (SBOM), and with what risk profile. Without this data foundation, even the early warning fails at the requirement to name the affected countries.

An open, monitored intake channel. There is exactly one documented channel through which vulnerability information reaches you — internal and external — with clear ownership for triage. Published, linked, staffed.

A practised decision pathway. A designated role determines awareness; the approval chain through to notification is defined; and the whole thing has been tested under realistic conditions: with incomplete information, at a deliberately inconvenient time, with deputy arrangements in place. Paper processes that have never run will fail first in a real incident.

Where itemis Can Help

The quickest starting point is the question of applicability: the free online applicability check from the CRA Interest Group (CRAIG) shows you whether and how your products fall under the CRA. CRAIG is a non-profit initiative with the goal of making CRA implementation accessible, particularly for SMEs; itemis is a strategic sponsor, and Dirk Leopold serves as its chairman.

For the technical side of preparation, there is itemis SECURE: model-based threat and risk analyses (TARA) according to ISO/SAE 21434, IEC 62443, and the CRA, with AI support for threat analysis and attack tree creation, and with audit-ready documentation. The result is a living risk model of your products — and that is precisely what accelerates the initial assessment in a reporting scenario: manufacturers who know their attack surfaces per product and version decide the question of awareness in hours rather than days.

An honest assessment to close: anyone still at zero in the summer of 2026 will find September tight. It remains achievable if you address the 3 capabilities above in that order — and do not schedule the first rehearsal for 10 September.

Frequently Asked Questions about CRA Reporting Obligations

Do I also need to inform my users, in addition to the authorities? Yes. Article 14(8) obliges manufacturers, upon becoming aware, to inform the affected users (where necessary all users) about the vulnerability or incident and about possible countermeasures — where appropriate in machine-readable format. If this is omitted, the coordinating CSIRT may inform users directly.

My company has no establishment in the EU. Which CSIRT do I report to? Article 14(7) sets out a priority order: the member state of the authorised representative; failing that, the importer; then the distributor; and finally the member state with the most users of your products. This allocation should be clarified and documented before the first reporting incident.

The vulnerability is in a third-party component we integrated. Who reports? The manufacturer of the end product reports the actively exploited vulnerability in their product. If the component was made available separately on the market, its manufacturer is also independently subject to the reporting obligation. Identified component vulnerabilities must also be reported back to the party responsible for that component.

Does the reporting platform exist yet? ENISA is building the central reporting platform under Article 16; it is due to be operational by 11 September 2026, with a preceding test phase. Your internal processes (triage, awareness decision, content for the 3 reporting stages, approvals) should be built independently of this, now.

Can a notification be treated as confidential? The manufacturer may indicate in the notification how sensitive the information is. In exceptional cases — for example, during ongoing coordinated disclosure — onward distribution to other CSIRTs may be temporarily withheld on justified cybersecurity grounds. The default remains prompt distribution to the affected member states; the classification does not create a right to confidentiality.

What happens after I submit a notification? The first-receiving CSIRT distributes the report to the CSIRTs of the member states where the product has been made available, and informs the market surveillance authorities. Until the final report is submitted, the coordinating CSIRT may request interim progress reports.

Does every known vulnerability trigger the reporting obligation? No. Article 14 reporting is required for actively exploited vulnerabilities and severe incidents with an impact on product security. A known but unexploited vulnerability falls under the general obligations for vulnerability handling (for example, remediation via a security update), but does not start a 24-hour deadline.

Sources: Regulation (EU) 2024/2847 (Cyber Resilience Act), in particular Articles 14, 15, 16, 64 and 69 (EUR-Lex); European Commission, “Cyber Resilience Act: Reporting obligations” and CRA summary (digital-strategy.ec.europa.eu); Commission CRA guidance (draft version) on the interpretation of awareness.

EU Cyber Resilience Act at itemis — Deadlines, applicability and the path to conformity with itemis SECURE and the CRAIG community: EU Cyber Resilience Act →