Which CSIRT to notify under the CRA: the decision rules

Which CSIRT to notify under the CRA for a manufacturer with EU operations

Under Article 14, a manufacturer notifies an actively exploited vulnerability or severe incident to the CSIRT designated as coordinator in the Member State where its cybersecurity decisions on the product are predominantly taken. Where that Member State cannot be identified, the notification goes to the CSIRT of the Member State where the EU establishment with the most employees is located. This duty has applied since 11 September 2026, so a manufacturer with EU operations needs to settle the question before the first 24-hour early warning is due, not during it. The answer depends on the structure of the company, and the reader should not assume it from the location of the legal entity that signs the contract. For a group with EU subsidiaries, the analysis starts with the question of where product security decisions are actually made: who approves vulnerability fixes, who decides on coordinated disclosure, who signs off on support periods and who holds the authority to order a patch. A subsidiary in one Member State may run the engineering team while a parent in another Member State takes the decisions, and the coordinating CSIRT follows the decisions. A non-EU parent with several EU subsidiaries still files one notification per event, according to ENISA's platform FAQ, but the manufacturer must coordinate internally to decide which subsidiary's Member State it is. Reporting lines, board minutes and product security governance documents are the evidence to gather and to keep on file. If the manufacturer has no EU main establishment, Article 14(7) sets an order of fallback: the authorized representative appointed under Article 18, then the importer, then the distributor, then the Member State where most users are located. Confirm whether an authorized representative has been appointed by written mandate, and note that the design, risk assessment and vulnerability handling obligations in Article 13(1) to (11) cannot be delegated through that mandate. Choosing the wrong CSIRT can invalidate the notification, so record the reasoning behind the choice and check it against the current guidance and ENISA's platform FAQ before submission.

Why the place where cybersecurity decisions are taken decides the CSIRT

The test for choosing a CSIRT is where your product cybersecurity decisions are predominantly taken, not where your registered seat sits or where most of your staff work. A manufacturer can have a legal headquarters in one Member State and a large engineering office in another, and the notification still goes to the CSIRT of the Member State where the decisions that govern the product are actually made. Under Article 14, the coordinating CSIRT is identified by that decision-making location, and ENISA's platform FAQ states the fallback in the same terms: if no main EU establishment can be identified on that basis, the test moves to the EU establishment with the most employees.

Decide this from your governance records, not from an org chart. Look for the people who approve vulnerability fixes and their release sign-off, the owner of the product risk assessment under Annex I, and the person or committee that signs off support period commitments and end-of-support decisions. If those approvals happen in one country, that is a strong indicator, but you must confirm it against your own minutes, delegation-of-authority documents and approval workflows. Where decisions are split across establishments, record the reasoning for your choice, because the coordinating CSIRT and market surveillance authorities may ask how you reached it.

The choice matters because a notification sent to the wrong CSIRT can be invalidated, and an invalid notification may count as a missed deadline. Within the 24-hour early warning window, you will not have time to rediscover where your decisions sit. Confirm the designated CSIRT before you need it, write the answer into your vulnerability handling procedure, and check it again when the product governance changes, for example after a reorganization, a change of product owner or a move of the security team. The ENISA Single Reporting Platform FAQ is the natural next read for how the platform treats the coordinating CSIRT.

Which fallback applies to your structure

This table maps common manufacturer structures to the CSIRT rule that applies and the records you should keep to support the choice. Work down the rows in order: the first row that matches your facts determines the coordinating CSIRT, and the documentation column shows what an assessor or CSIRT is likely to ask you to show.

Manufacturer structure	CSIRT rule that applies	What to document
EU main establishment where cybersecurity decisions on the product are predominantly taken	Notify the CSIRT of that Member State, designated as coordinator	Board or management minutes, product security decision logs, and org charts showing where product security sign-off happens
No clear decision location, but several EU establishments	Notify the CSIRT of the Member State where the EU establishment with the most employees sits	Headcount by establishment and a written analysis explaining why no single location takes predominant decisions
No EU establishment, with an authorized representative appointed by written mandate	Notify through the CSIRT of the Member State where the authorized representative is established	The signed mandate under Article 18 and confirmation of the representative's EU address
No EU establishment and no authorized representative, with an EU importer	Notify through the CSIRT of the Member State where the importer is established	Importer contract or declaration and records of which importer placed the product on the market
No EU establishment, authorized representative and importer, with an EU distributor	Notify through the CSIRT of the Member State where the distributor is established	Distribution agreements and records showing which distributor made the product available
No EU establishment or intermediary, but users in the EU	Notify through the CSIRT of the Member State where most users of the product are located	Usage or deployment data by Member State, with the method used to estimate user location and its date
Mixed structure, such as a non-EU parent with EU subsidiaries	Apply the main establishment test first, then the fallbacks in order, and notify once per event	Internal coordination records showing one notification was filed and who approved the chosen CSIRT
Facts change after a choice was made, such as a relocated decision team	Re-check the rule before the next notification and record the change	Dated decision memo describing the change and the new coordinating CSIRT, confirmed with the authority

Structures that make the CSIRT choice harder

The Article 14 rule points to one coordinating CSIRT, but several corporate structures make that point hard to find. In each case, ENISA's FAQ places the work of agreeing one notification route on the manufacturer, so the settlement happens before an incident, not during one.

Several EU subsidiaries selling the product

When each national subsidiary sells the same product, each may look like a natural reporting entity. The manufacturer must decide internally which establishment makes the cybersecurity decisions for the product, then notify only that CSIRT. Record that decision in writing and make sure every subsidiary knows to route reports through it. Check whether the decision-making location is documented, not just assumed from the head office address.

Parent company outside the EU

A non-EU parent may set security policy and approve fixes while an EU subsidiary handles sales. The question is where cybersecurity decisions on the product are predominantly taken, which may sit with the parent's staff physically located in another country. Confirm who signs off on vulnerability handling and corrective releases, and whether an EU establishment exists that makes those calls. If there is none, the fallback rules apply.

Decisions split across countries

Security responsibilities are often divided, with product engineering in one Member State, release approval in another and the incident response lead in a third. The manufacturer must determine where cybersecurity decisions on the product are predominantly taken, which is a factual question about the organization's actual governance. Map who decides on disclosure, patching and customer communication, then document the country where most of that weight sits.

Platform distribution without an EU importer

Products sold through app stores, marketplaces or online platforms may reach EU users with no EU-established importer. Article 14(7) then moves down an order: an authorized representative first, then an importer, then a distributor, then the Member State where most users are. Confirm early whether an authorized representative has been appointed by written mandate, because that appointment determines which fallback applies.

Open-source project with contributors across countries

A project maintained by volunteers or a foundation can have contributors in many countries and no legal entity in the EU. Who decides on vulnerability handling, and where, often has no clear answer. Name the body or people that accept reports and approve fixes, decide where that group is located, and confirm which steward or commercial entity carries the reporting duty for the product as placed on the market.

One event, several notifications risk

Where several entities in a group each believe they must report, the same actively exploited vulnerability can generate duplicate notifications to different CSIRTs. ENISA's guidance is that one notification is enough, and internal coordination is the manufacturer's job. Set a single incident owner for each group, so one submission goes to the designated coordinator and the others are informed internally rather than filing their own.

What happens if the wrong CSIRT is chosen

ENISA's platform FAQ warns that choosing the wrong CSIRT can invalidate the notification. That makes the routing decision part of the reporting duty itself, not an administrative detail to settle later. Once a notification is submitted through the Single Reporting Platform, it is made available to ENISA at the same time, and the coordinating CSIRT passes it on to CSIRTs in other Member States where the product is available. It also shares information with market surveillance authorities as needed. A misrouted report therefore does not simply disappear. It may be treated as not validly made, and the manufacturer may have to resubmit to the correct coordinator while the clock keeps running.

Plan on the Article 14 deadlines running while the routing question is being resolved. The early warning is due within 24 hours of becoming aware of the actively exploited vulnerability, and the vulnerability notification within 72 hours. Do not hold a submission while you debate which CSIRT is correct. Document the reasoning for your choice at the time you make it, including where cybersecurity decisions on the product are predominantly taken, and record any change of coordinator. Ask the national CSIRT you select how it handles a notification it considers misrouted, whether it will forward it, and what it expects you to do next. Confirm these points before an incident, because the answer will not be easy to obtain under pressure.

Ask counsel how a misrouted report would be treated under the regulation and your national law, and whether a late or invalid early warning could expose the organization to the fine ceilings in Article 64. Those ceilings are EUR 15 million or 2.5% of total worldwide annual turnover for breaches of Article 14, whichever is higher. Counsel can also advise on how to describe a routing error to authorities and on the records that show a good-faith decision. A legal review of your routing rules before you need them is a reasonable use of time, and the answer may depend on facts specific to your establishment and product portfolio.

Routing mistakes that cost time during an incident

Most delays in CRA notifications come from routing decisions made before any incident, not from the reporting itself. The mistakes below share one root cause: the manufacturer never wrote down which Member State it treats as its coordinating CSIRT, or who makes product security decisions there. Each card names one check that closes the gap.

Choosing the registered seat by default

Many manufacturers pick the CSIRT of the country where the company is registered without checking where cybersecurity decisions on the product are actually taken. The rule turns on the main EU establishment where those decisions are predominantly made, so a registration address alone may point to the wrong authority. Confirm who approves vulnerability fixes, risk acceptance and release decisions, and record the country where those people sit.

Notifying several CSIRTs in parallel

Some teams send the same notification to every CSIRT where they have a subsidiary or a customer base, hoping one of them is correct. ENISA's platform guidance requires one notification per actively exploited vulnerability or severe incident, submitted to the designated coordinator. Duplicate submissions create conflicting records and internal confusion. Agree on a single submitter role and handle subsidiary coordination internally before the clock starts.

No written record of the routing decision

When an incident starts, the team often has to reconstruct why a particular CSIRT was chosen, which slows the first submission. Keep a dated memo that names the main establishment, the reasoning under the decision-making test, and the fallback considered. Store it with your CRA technical documentation so an assessor or market surveillance authority can see how the decision was made.

Appointing a representative without checking decisions

An authorized representative under Article 18 can be appointed by written mandate, but it does not take over product security decisions. A representative in a country where no product decisions are made may send the notification to a CSIRT that is not the right coordinator. Before signing the mandate, confirm who decides on vulnerability handling and where those people work, and write that into the routing record.

Leaving the rule unchanged after reorganization

A routing rule set at product launch can become wrong after a merger, a move of the security team, or a change in the product's engineering leadership. The main establishment is a factual test, so a reorganization can shift the answer without anyone noticing. Review the routing record after any acquisition, restructuring or change of product security owner, and reissue the contact list to the people who would submit the notification.

Who owns the CSIRT decision and who prepares the record

The manufacturer owns the CSIRT decision. Under Article 14, the duty to notify sits with the manufacturer, so the manufacturer must determine the Member State where its cybersecurity decisions on the product are predominantly taken, or the fallback establishment if no main EU establishment exists. The manufacturer also carries the internal coordination when several EU subsidiaries or a non-EU parent are involved, because ENISA's platform guidance expects one notification per actively exploited vulnerability or severe incident.

Decision ownership: Management records where product security decisions are actually made, not where a legal address sits.
Single notification: Internal teams agree which entity files, so the group does not send duplicate or conflicting reports.
Authorized representative limits: Under Article 18, a written mandate can cover tasks, but the Article 13(1) to (11) obligations cannot be delegated through it.
Counsel review: Confirm with counsel in writing what any mandate covers and which decisions remain with the manufacturer.
Named contacts: Keep a current register of people who can file and receive on the manufacturer's behalf.

Before relying on any appointment, check with counsel what the mandate actually transfers.

How to prepare the routing decision before the first notification

This sequence turns the question of which CSIRT receives your CRA notifications into a documented decision with evidence behind it, so the routing holds when an actively exploited vulnerability or severe incident needs reporting. Work through it before any notification is due, not during one.

Map where product security decisions are taken
List every product with digital elements you place on the EU market, then identify who decides on its cybersecurity: vulnerability triage, patch release, risk acceptance, end-of-support and incident response. Record the physical location or legal entity where those decisions are predominantly taken, not only where the code is written or where the product is sold. The output is a decision map per product, with the named role and location for each decision. Ask the product security lead and the legal team to confirm it, because the map is only useful if both agree with it.
Identify EU establishments and their headcount
List each EU establishment of the manufacturer, including subsidiaries and branches, and the number of employees at each. Use the figures from HR records as of the date you prepare the map, and keep the source. This list is needed for the fallback rule, which looks at the EU establishment with the most employees when cybersecurity decisions cannot be placed in a single Member State. The output is a dated establishment register with headcounts and the source for each figure.
Check for a main establishment in the EU
Compare the decision map from step one with the establishment register. If the decisions on the product are predominantly taken in an EU Member State, that Member State's CSIRT is the candidate coordinator. If they are taken outside the EU, or no EU establishment exists, move to the Article 14(7) order: the authorized representative appointed under Article 18, then the importer, then the distributor, then the Member State where most users are. Confirm with counsel which path applies, because an authorized representative cannot take over the design, risk assessment or vulnerability handling duties in Article 13. The output is a written route with the legal basis for each choice.
Record the decision and the evidence behind it
Write a short routing memo for each product or product family. It should state the chosen Member State, the decision-makers and locations relied on, the headcount figures where the fallback applied, and the documents that support each fact, such as org charts, board minutes, product governance records or contracts. Date the memo and name the approver. ENISA's platform guidance warns that choosing the wrong CSIRT can invalidate a notification, so the memo is what lets you show the choice was reasoned. The output is a signed, dated routing record stored with your technical documentation.
Confirm the designated coordinating CSIRT
Look up which national CSIRT is designated as coordinator for CRA notifications in the chosen Member State, and check that the entity is still the designated body. Confirm how the CSIRT expects to receive notifications and any national contact points, and record the source and check date. Notifications are made through the Single Reporting Platform, and ENISA receives them at the same time, so the CSIRT is not a separate filing route. The output is a verified contact entry for each product's coordinating CSIRT, with the date it was confirmed. Repeat the check before the notification duties are relied on in practice.
Set a review trigger for organizational change
Define the events that require the routing record to be reviewed: reorganizations, mergers, acquisitions, relocation of product security teams, changes in product ownership, and new EU establishments. Assign an owner and a path to update the decision map, the headcount register and the routing memo. Also check whether a change in product ownership affects who is the manufacturer under the regulation. The output is a documented trigger list with a named owner and a record of each review, so a change does not leave notifications routed to a CSIRT that no longer fits. Coordinate the routing with the sibling reporting playbook, which sets out the 24-hour early warning, the 72-hour notification and the final report that depend on this decision.

Questions buyers ask about choosing the CSIRT

Can a non-EU manufacturer choose any CSIRT it likes?

No. The choice follows fixed rules, not preference. The notification goes to the CSIRT designated as coordinator in the Member State where the manufacturer's cybersecurity decisions on the product are predominantly taken. If there is no EU main establishment, the order in Article 14(7) applies: the authorized representative's Member State, then the importer's, then the distributor's, then the Member State where most users are. The main drivers are where your product decisions really happen and which EU entities exist on paper. Confirm the facts with counsel before you submit, because ENISA's platform FAQ warns that choosing the wrong CSIRT can invalidate the notification.

Does one notification cover every EU subsidiary?

Usually yes, for a given vulnerability or incident. ENISA's platform FAQ states that only one notification is required per actively exploited vulnerability or severe incident, even when a manufacturer has several EU subsidiaries or a parent outside the EU. The manufacturer is responsible for coordinating internally so that a single notification goes to the correct coordinating CSIRT. The practical work is agreeing in advance who owns the notification, who signs it off, and how subsidiaries pass on information quickly enough to meet the 24-hour early warning deadline under Article 14.

Does an authorized representative decide which CSIRT receives the notification?

No. An authorized representative is appointed by written mandate under Article 18, but the design, risk assessment and vulnerability handling obligations in Article 13(1) to (11) cannot form part of that mandate. The manufacturer keeps the duty to notify and the decisions behind it. Where the representative's Member State matters, it matters only as a step in the Article 14(7) order for manufacturers without a main EU establishment. Check the mandate wording so it does not imply that the representative takes cybersecurity decisions the manufacturer should own.

What should we do when cybersecurity decisions are shared across several countries?

Start by documenting where each decision is actually taken, not where the org chart says it should be. Decisions on a product are often split between a product team in one country, a security team in another and a board or parent company elsewhere. Record who approves risk acceptance, patch release and public disclosure for each product line, and where those people work. The decisive location is the one where cybersecurity decisions are predominantly taken, so a clear, evidenced picture of that split drives the answer. Where the picture is still unclear, escalate to counsel before a live incident, since the early warning clock starts on awareness.

Must we document the CSIRT decision, and for how long should we keep it?

Keep a written record of the decision, the facts behind it and the date it was made. The CRA does not give a retention period in the sources supplied for this page, so confirm the retention requirement and the appropriate length with counsel and against your own record-keeping policy. A good record names the product, the EU entities considered, the decision-making evidence, the coordinating CSIRT chosen and the reviewer. Update it when product governance, ownership or EU establishments change, because a decision that was correct last year may no longer apply.

How much outside help does choosing the CSIRT need, and what drives that effort?

The effort depends on how many entities, products and decision-makers are involved, and on how clean your records are. A single EU company with one product line and one decision-making team needs a short review. A group with several EU subsidiaries, a non-EU parent, multiple product lines and shared governance needs a documented analysis per product. Outside help is usually scoped as a fixed piece of work: mapping decision points, reviewing the Article 14(7) order, and writing the record. Ask any provider to state the scope, deliverables and assumptions in writing before work begins, since DeployOpen works to written scopes and does not publish a price list.

What information must we give an implementation partner to scope this work?

Prepare a short evidence pack before the first conversation. Include the legal entities in the EU and outside it, their ownership structure, the products and product lines in scope, and an org chart showing who approves security, release and disclosure decisions. Add the authorized representative and importer or distributor arrangements, if any, and where users of each product are located. Any existing incident response or PSIRT procedure helps too. DeployOpen prepares systems, controls and evidence for this kind of analysis, but the organization owns the decision and the notification, and only counsel or the competent authorities can confirm the legal conclusion.

How DeployOpen prepares the CSIRT routing record

DeployOpen helps organizations build a written record that shows which CSIRT they would notify under the Cyber Resilience Act and why. We prepare the systems, documents and evidence that support that routing decision, while the organization keeps ownership of its cybersecurity decisions and the final determination.

How we scope

Engagements are fixed-scope, with the routing questions, systems and entities agreed in writing before work starts.
We map where cybersecurity decisions for each product are actually taken, including the roles and committees involved.
Scope records which EU establishments, subsidiaries and non-EU parents must be covered by the routing analysis.

How we build

We document a decision record that traces the main establishment test and the fallback order to named evidence.
We set up the internal workflow so the designated contact can be reached and the same routing answer is applied consistently.
We test the routing procedure with a tabletop exercise based on a hypothetical vulnerability (illustrative) to confirm owners know the steps.

How we hand over

You receive the routing record, decision log, organization chart mapping and runbook in formats your legal and security teams can maintain.
We walk your compliance, legal and PSIRT owners through how the record should be updated when structure or decision-making changes.
Review points are listed so your counsel can confirm the routing conclusion against the Regulation and current Commission guidance.

How we support

Ongoing support, updates and exercises can be added as a retainer if your structure or product portfolio changes.
We help you prepare questions for your authorized representative, importer or distributor where the non-EU path applies.
Final routing conclusions, legal interpretation and any notification to a CSIRT remain with your organization and its advisers.

Which CSIRT to notify under the Cyber Resilience Act