The CRA Now Requires Reporting Exploited Vulnerabilities. What That Changes for You
On 11 September 2026, ENISA brought the Single Reporting Platform (SRP) online, the one-stop reporting gateway set up by the Cyber Resilience Act (CRA). The same day, the duty to report became binding on software vendors and manufacturers.
For the first time, a vendor selling a digital product in the European Union has a legal obligation to report, within 24 hours, that one of its vulnerabilities is being exploited. What remains to be seen is what that changes when you run an information system and have to decide what to patch first.
Who reports, what, and how fast
Who. Vendors and manufacturers of products with digital elements sold in the EU, since 11 September 2026. Open-source stewards, meaning the organisations that maintain free software used in commercial products, follow on 11 December 2027.
What. Two things:
- Actively exploited vulnerabilities. The official definition is worth remembering, because it is stricter than everyday usage: there must be "reliable evidence that it has been exploited by a malicious actor in a system without permission of the system owner". Not a proof of concept on GitHub. Not an EPSS score climbing. Exploitation actually observed.
- Severe incidents. An incident is "severe" when it compromises the protection of sensitive or important data or functions, or when it leads to the introduction or execution of malicious code in the product or in a user's information system.
How fast. The clock starts when the manufacturer becomes aware:
- 24 hours: early warning
- 72 hours: notification with general information and an initial assessment
- 14 days after a corrective or mitigating measure is made available: final report for an exploited vulnerability
- 1 month after the 72-hour notification: final report for a severe incident
The report goes to the CSIRT designated as coordinator in the member state where the manufacturer has its main establishment, and to ENISA at the same time. The other CSIRTs concerned and the market surveillance authorities are served afterwards. Reports are filed on the SRP portal. The detail of the fields to fill in and the edge cases is covered in ENISA's FAQ.
These reports are not public
The SRP is not an open catalogue, it is a pipe between manufacturers and authorities. The regulation even allows dissemination to be delayed in exceptional circumstances (Article 16(2)). And the platform currently covers mandatory reporting only: a voluntary reporting phase is announced for later.
In other words, no, you will not wake up tomorrow to a European feed listing exploited vulnerabilities in real time. The signal exists, it is dated, it is regulated, but it reaches the CERTs first.
Some of it does resurface eventually: once a fix is available, ENISA adds the vulnerability to the European Vulnerability Database (EUVD), in agreement with the manufacturer. That is a different channel from the exploitation catalogue discussed below.
What actually changes for vulnerability management
Four effects deserve attention.
Confirmed exploitation becomes an even more official act. Until now, knowing that a vulnerability was genuinely exploited depended on who was willing to say so: a vendor acknowledging it in an advisory, a honeypot whose operator publishes their observations, sometimes just a post on social media. Valuable signals, but all optional. From now on, in Europe, it is a legal obligation, with a date and an identified recipient. That does not make the information public, but it does make it traceable.
Silent patching becomes risky. Quietly fixing an already exploited flaw without saying anything was common practice. The CRA places failure to report in its highest penalty tier, on a par with breaching the essential cybersecurity requirements: up to 15 million euros or 2.5% of total worldwide annual turnover, whichever is higher. It is reasonable to expect vendor advisories to become more explicit about observed exploitation.
The volume will grow further. It was growing already without the CRA: after 50,000 CVEs in 2025, we are already past 65,000 in 2026. The regulation pushes the same way: from late 2027, every manufacturer will have to publish a description of each fixed vulnerability at the moment it ships the patch (Annex I, Part II). More advisories published means more CVEs to triage.
A geographic rebalancing is starting. This is probably the most useful effect for a European information system. The reference sources on exploitation are mostly American and mainly observe what is visible on the open internet. We illustrated this with Stormshield: across the 45 CVEs recorded against this French vendor's own code, not one ever exceeded 4% EPSS. Not because the risk was nil, but because those sources were looking elsewhere. A European manufacturer exploited at European customers will now be documented in Europe, by obligation, and not because some North American telemetry happened to notice.
In the meantime, what stays visible
None of this removes the need to do the work with the public signals that already exist: CERT advisories, CISA's KEV catalog, the European catalogue of exploited vulnerabilities maintained by ENISA, vendor bulletins, availability of proofs of concept and exploits, EPSS, observed sightings.
That European catalogue, precisely, is still anecdotal with its 39 entries against 1,710 on the CISA side. This may be what the CRA changes, provided ENISA feeds into that catalogue the exploitation cases it is finally going to be told about.
This is exactly the layer SYRN consolidates. And it is going to fill out on the European side: European products, long poorly covered for want of an observer, finally will be. SYRN already ingests ENISA's catalogue alongside CISA's.
The CRA will not make prioritization simpler. It adds one more source of truth: reliable, late, and partly closed. The cross-referencing work itself does not change.