Where Do You Report a Vulnerability Under the CRA? SRP and CSIRT Explained
From September 11, 2026, if you become aware of an actively exploited vulnerability in your product, you have 24 hours to notify the European authorities.
The obligation covers products already on the EU market, so a device you shipped in 2023 counts just as much as one you launch next year.
This is the first piece of the Cyber Resilience Act to become mandatory, fifteen months before the regulation makes cybersecurity part of CE marking for products with digital elements. For most manufacturers, the immediate questions are simple: where does the report go, who reads it, and what happens if you are late.
Where do you report a vulnerability under the CRA?
You report it through the Single Reporting Platform (SRP), a single EU-wide electronic platform that ENISA, the EU’s cybersecurity agency, is building and will operate from September 11, 2026, with a testing phase before that date.
You file one notification. The platform delivers it simultaneously to two recipients:
the national CSIRT designated as coordinator for your member state,
and ENISA.
A CSIRT (Computer Security Incident Response Team) is the national authority that handles cybersecurity incidents in each EU country.
There is no reporting country by country, and emailing a national agency directly does not fulfill the obligation. The single filing through the SRP is the legal channel, whether your product is sold in one member state or in all twenty-seven.
The obligation comes from Article 14 of the Cyber Resilience Act, and it applies to any product with digital elements sold in the EU, including those placed on the market before the rest of the regulation applies in December 2027.
What happens after you submit a report?
Your coordinator CSIRT takes over the case. If your product is available in other member states, that CSIRT disseminates your report to the CSIRTs of the affected countries through the platform, which is why the first notification asks you to list the member states where the product has been made available. You never repeat the filing for each country.
In exceptional cases, the receiving CSIRT can delay that dissemination when spreading the information immediately would create a bigger security risk than holding it.
The relationship does not end with the filing. Your coordinator CSIRT can request intermediate reports on how you are handling the vulnerability. And if you fail to inform your affected users in a timely manner, the CSIRT can inform them on your behalf.
Two more features of the platform are worth knowing.
It accepts voluntary reports from anyone, so a security researcher can flag a vulnerability in your product even if you stay silent.
And once a vulnerability is fixed, ENISA discloses it to the European Vulnerability Database, where it becomes part of your product’s public security record.
Which member state is “yours” if you are not established in the EU?
The SRP is organized in electronic end-points, one per coordinator CSIRT. You submit through the end-point of your member state, which means
you need to know your reference country before you ever file a report. The platform does not determine it for you.
Article 14(7) of the CRA sets the rule. For companies established in the EU, the reference country is the member state where the cybersecurity decisions about the product are predominantly taken, and if that cannot be pinned down, the member state where the company has the most employees in the EU.
For a manufacturer with no establishment in the EU, the article sets a cascade. Your reference country is, in this order: the member state of the EU Authorised Representative acting for the largest number of your products, then the member state of the importer placing the most of your products on the market, then the distributor’s, and as a last resort the member state where most of your users are located.
In practice, the cascade collapses into a short answer for most exporters: if you have an Authorised Representative, your reference country is where your representative is established, and the analysis ends there.
Make this determination now, once, in calm conditions. Working out whether your reference country is Ireland or Germany while the 24-hour clock is running is the worst possible moment to do it. ENISA will publish the official list of national CSIRTs designated as coordinators before the platform goes live, so you can confirm your assignment against it.
Which vulnerabilities and incidents must be reported?
The CRA defines two triggers, and both are narrower than manufacturers tend to fear.
The first is an actively exploited vulnerability: a weakness in your product that someone is actually using against it. The mere existence of a vulnerability does not trigger the notification. A flaw your own team discovers during testing, with no evidence of exploitation, needs a patch, and it needs to go through your vulnerability handling process, and none of that involves the SRP.
The second is a severe incident having an impact on the security of the product: an event that compromises, or is capable of compromising, the availability, authenticity, integrity, or confidentiality of the product’s data or functions.
Awareness is what starts the obligation. The moment your company becomes aware of active exploitation or a severe incident, the deadlines below begin to run.
Vulnerability Reporting Under the CRA: Common Questions Answered
FAQ
What the July 2026 Commission Guidance Says
When do you legally "find out" about a vulnerability?
The clock starts once you have reasonable certainty of active exploitation or a serious incident. An unconfirmed report or rumor does not start it.
Do you have to report vulnerabilities you already knew about before September 11, 2026?
Only vulnerabilities actively exploited after that date trigger the obligation, even if you were already aware of the underlying flaw. Past knowledge alone does not require a retroactive report.
Do you have to report every vulnerability in a third-party library you use?
Only if that part of the code is genuinely used in your product and has actually been exploited there. Telling the maintainer remains good practice even when a report to the authorities isn't required.
How much technical detail do you have to share with users?
Enough for affected users to protect themselves, with the option to hold back detail that could help an attacker until the fix is ready. You can expand the information once the issue is resolved.
Do you need to notify the maintainer of a library your product depends on?
Only if they aren't already aware, so the report doesn't get duplicated. An unmaintained component removes this step entirely.
If you fix a third-party component's bug yourself, do you have to share the fix?
Sharing the fix with the maintainer is recommended, though they are not obligated to accept it.
What if a new vulnerability surfaces right before launch?
The decision is yours, based on risk: fix it before shipping, or launch on schedule and patch it afterward.
What are the deadlines once you become aware?
The reporting sequence has three fixed steps.
An early warning goes in within 24 hours of becoming aware. At this stage the platform asks for basic information, including the member states where the product is available, and nothing close to a full analysis.
A fuller notification follows within 72 hours, with general information about the event, an initial assessment, and any corrective or mitigating measures taken or available to users.
A final report closes the case: within 14 days after a corrective measure is available for an actively exploited vulnerability, or within one month of the 72-hour notification for a severe incident. In between, your coordinator CSIRT can ask for intermediate updates.
What are the penalties if you miss a deadline?
Failing to comply with Article 14 sits in the highest penalty tier of the CRA. Article 64 sets administrative fines of up to 15 million euros or 2.5% of total worldwide annual turnover, whichever is higher, the same ceiling that applies to breaching the regulation’s essential cybersecurity requirements.
There is one carve-out: manufacturers that qualify as microenterprises or small enterprises cannot be fined for missing the 24-hour early warning deadline. The exemption covers only that fine. The obligation to report, the 72-hour notification, and the final report still apply to them in full.
The fine is only half of the exposure. Every report you file documents a vulnerability in your product, with dates, and the fixed vulnerability ends up in a public database. Under the EU’s new product liability rules, that record is exactly the kind of evidence a claimant can use when arguing that a cybersecurity defect made your product defective. Silence is not a way out of that exposure either, since voluntary reporting means someone else can put your vulnerability on the record for you.
How Long Are You on the Hook for Security Fixes?
The 24-hour and 72-hour deadlines above apply during a security event. A separate question sits underneath all of them: for how many years after you sell a product do you have to keep fixing vulnerabilities in it at all?
The Cyber Resilience Act sets a minimum support period of five years under Article 13. If your product is reasonably expected to remain in use longer than that, the support period extends to match that expected lifetime. A hardware controller designed to run for fifteen years on a factory floor carries a longer obligation than a mobile app that gets replaced every two years.
Manufacturers who release new versions frequently, and let users update for free without buying new hardware, can concentrate their security support on the latest version rather than maintaining every past release in parallel.
Updating the product does not reset this clock on its own. The support period only shifts if the change affects how long the product is reasonably expected to stay in use, separate from a routine patch or feature release.
The date your security support ends has to reach the customer, and it needs to be visible at the point of purchase.
Four steps cover most of the groundwork, and none of them requires waiting for the platform to go live.
Determine your coordinator CSIRT now, using the Article 14(7) rules above. It is a one-time decision, and it defines which authority you will deal with during a crisis.
If you sell into the EU through an Authorised Representative, check that the mandate covers reporting tasks and that your representative knows it may become your reference point for the SRP.
Set up continuous vulnerability monitoring of your product. Meeting a 24-hour deadline is only realistic if you know what is inside your software, which is what an SBOM under the CRA exists for.
And rehearse the workflow internally: who detects, who decides that the company is “aware,” and who files within 24 hours. The companies that miss the deadline will mostly be the ones deciding these roles during their first real incident.
