Which CSIRT do I report to under the CRA, and how does the ENISA single reporting platform work?

Article 14(1) and (3) require a manufacturer to notify an actively exploited vulnerability, and a severe incident having an impact on the security of the product, simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform.^[1]

Article 14(7) decides which CSIRT that is. The notification goes to 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, and is simultaneously accessible to ENISA.^[1]

Main establishment has a specific meaning here. It is the Member State where the decisions related to the cybersecurity of the manufacturer's products with digital elements are predominantly taken. Where that Member State cannot be determined, it is the Member State in which the manufacturer has the establishment with the highest number of employees in the Union.^[1]

Note what the test is not. It does not follow the registered office, the group headquarters, the place of incorporation or the largest market. It follows where product security decisions actually get made, which for many groups is an engineering site rather than a corporate seat.

A manufacturer with no main establishment in the Union works down a strict order, based on the information available to it:

1. The Member State where the authorised representative acting for the highest number of that manufacturer's products is established.
2. The Member State where the importer placing the highest number of those products on the market is established.
3. The Member State where the distributor making the highest number of those products available is established.
4. The Member State where the highest number of users of those products are located.

There is a stability provision attached to the fourth limb. Where a manufacturer reaches step 4, it may submit notifications about any subsequent actively exploited vulnerability or severe incident to the same coordinating CSIRT it first reported to, rather than recalculating user distribution each time.^[1]

Article 16(1) requires ENISA to establish the single reporting platform for the notifications under Article 14(1) and (3) and Article 15(1) and (2), expressly in order to simplify manufacturers' reporting obligations. ENISA manages and maintains its day-to-day operations, and its architecture allows Member States and ENISA to put in place their own electronic notification end-points.^[3]

The practical consequence is the one manufacturers most often get wrong. You file once, at your coordinating CSIRT's end-point, and that single submission is simultaneously accessible to ENISA. There is no separate ENISA filing, and no obligation to notify each Member State where the product is sold.

Distribution is handled for you. Under Article 16(2), the coordinating CSIRT that initially receives the notification must without delay disseminate it via the platform to the coordinating CSIRTs of the Member States where the manufacturer has indicated the product has been made available.^[3]

That indication is your job, and it is made at the first step. Article 14(2), point (a), requires the 24-hour early warning to indicate, where applicable, the Member States on whose territory the manufacturer is aware the product has been made available.^[1] Getting that list wrong at hour 24 is what narrows or misdirects the dissemination that follows.

The Article 16 explainer covers the platform architecture, the European Vulnerability Database and ENISA's wider coordination role.

Two tracks run on the same clock shape and diverge at the final report. Both start when the manufacturer becomes aware.

For an actively exploited vulnerability, under Article 14(2):^[1]

1. Early warning, without undue delay and in any event within 24 hours, indicating where applicable the Member States where the product has been made available.
2. Vulnerability notification, within 72 hours, giving general information about the product, the general nature of the exploit and of the vulnerability, corrective or mitigating measures taken, and measures users can take. This is also where the manufacturer indicates how sensitive it considers the information to be.
3. Final report, no later than 14 days after a corrective or mitigating measure is available, describing the vulnerability including severity and impact, any information on the malicious actor exploiting it, and details of the security update or other corrective measures.

For a severe incident, under Article 14(4):^[1]

1. Early warning within 24 hours, including at least whether the incident is suspected of being caused by unlawful or malicious acts.
2. Incident notification within 72 hours, with the nature of the incident, an initial assessment, and corrective or mitigating measures.
3. Final report within one month after the submission of the incident notification, with a detailed description including severity and impact, the type of threat or likely root cause, and applied and ongoing mitigation measures.

The two final-report clocks are the most commonly swapped pair in this Regulation. A vulnerability final report runs 14 days from a fix being available. An incident final report runs one month from the 72-hour notification, so it is anchored to a filing rather than to a remedy.

Article 14(8) sits alongside the notifications and is easy to miss because it points at customers rather than authorities.

After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer has to inform the impacted users of the product, and where appropriate all users, of that vulnerability or incident, and where necessary of any risk mitigation and corrective measures users can deploy. Where appropriate this should be in a structured, machine-readable format that is easily automatically processable.^[1]

That last clause is the practical argument for producing a CSAF advisory rather than a prose security bulletin, since CSAF is the machine-readable advisory format the ecosystem has settled on.^[8]

There is an enforcement tail. Where the manufacturer fails to inform users in a timely manner, the notified coordinating CSIRTs may provide that information to users themselves, where considered proportionate and necessary to prevent or mitigate impact.^[1] Losing control of your own disclosure to a national CSIRT is a reputational outcome worth engineering against.

Partly, and the decision is never yours.

Article 16(2) allows dissemination of a notification to be delayed on justified cybersecurity-related grounds for a period that is strictly necessary, in exceptional circumstances and in particular on the manufacturer's request, taking into account the sensitivity the manufacturer indicated under Article 14(2), point (a). It names an ongoing coordinated vulnerability disclosure procedure under Article 12(1) of Directive (EU) 2022/2555 as an example. A CSIRT that withholds a notification must immediately inform ENISA of the decision, the justification and when it intends to disseminate.^[3]

In particularly exceptional circumstances the restriction goes further, where the manufacturer indicates that the vulnerability has been actively exploited and, on available information, in no Member State other than that of the receiving CSIRT, and that immediate further dissemination would carry the risks the provision sets out.^[3]

Commission Delegated Regulation (EU) 2026/881, adopted under Article 14(9) on 11 December 2025 and published in the Official Journal on 20 April 2026, specifies the terms and conditions for applying those cybersecurity-related grounds.^[6]

Two points of realism. The receiving CSIRT decides, and it is permitted to delay rather than obliged to. And the mechanism affects dissemination between CSIRTs, so it does nothing to the 24-hour and 72-hour deadlines that apply to you.

Article 71(2) applies Article 14 from 11 September 2026, more than a year before the rest of the Regulation applies on 11 December 2027.^[5]

The part that catches people out is the legacy portfolio. Article 69(2) generally exempts products placed on the market before 11 December 2027 from the Regulation unless they undergo a substantial modification. Article 69(3) then derogates from that specifically for Article 14, so the reporting obligations apply to all products within scope that were placed on the market before that date.^[4]

So the exposure on an existing product line is the reverse of the common assumption. The Article 13 design and risk assessment duties generally do not reach it. The Article 14 reporting duties do, and they start first.

Voluntary reporting is available on the same platform. Article 15 lets manufacturers, and other natural or legal persons, voluntarily notify vulnerabilities, cyber threats and incidents that fall outside the mandatory triggers.^[2]

Not yet. ENISA states that the platform is scheduled to be operational by 11 September 2026, the date the mandatory reporting obligations enter into application, with a testing period before then.^[9][10]

That leaves no slack. The platform becomes available on the same day the 24-hour clock starts running, so there is no grace period in which to discover how it works.

Two pieces of onboarding can be done ahead of launch, and one of them has a lead time outside your control.

• Create an EU Login account in advance. ENISA directs manufacturers to register at the Commission's authentication service before using the platform.^[9][11]
• Expect validation to run in parallel rather than in advance. ENISA indicates that the designated coordinating CSIRT validates a manufacturer's representatives after first access to the platform, alongside the reporting process rather than as a prerequisite completed beforehand.^[9]

The work that genuinely cannot wait is the determination in the first section. Establish which CSIRT is yours under Article 14(7), write down the reasoning, and keep the record with your technical documentation. That question has a defensible answer today, and answering it during an active exploitation is how a 24-hour deadline gets missed.

ENISA maintains a dedicated FAQ for the platform, updated as implementation proceeds. Treat it as the operational source and this answer as the legal one.^[9]