Inside Europe’s new vulnerability-reporting system

In its FAQ updated on 3 October 2026, ENISA describes an oddity in its new reporting platform: a notification can appear overdue before the legal deadline has expired. The current counter adds forty-eight hours to the submission of the early warning. The regulation counts seventy-two hours from the manufacturer becoming aware of the event. The agency says the counter will be changed in a later release. ^[2]

There is more here than an opportunity to mock administrative software. The discrepancy opens up a central question about the Cyber Resilience Act, the EU’s product cybersecurity regulation: how can security information reach the right people while a fix is still being prepared? A report can be submitted and malicious exploitation confirmed while the fix still needs to be designed, tested and delivered to the affected products.

Since 11 September 2026, manufacturers within the regulation’s scope have had to report actively exploited vulnerabilities in their products and severe incidents affecting product security. ENISA, the EU cybersecurity agency, launched the common reporting platform that day. The main product-security requirements apply from 11 December 2027. The specific obligations for organisations classed as open-source software stewards also begin on that later date. ^{[1] [5] [10]}

This phased introduction brings public authorities into a sensitive part of the software lifecycle. A weakness may be understood by a small group, already used by an attacker, and discussed confidentially among the people preparing a response. The objective is to turn that knowledge into protection while controlling its distribution. The rules governing this passage are considerably more nuanced than the familiar shorthand about a twenty-four-hour deadline.

The trigger belongs to a particular product

Consider a software library: a reusable component incorporated into applications or devices. Several manufacturers can use identical code while shipping different versions, enabling different features or exposing the software to different operating conditions. The following example is illustrative. It makes no allegation about an actual company.

A researcher discovers a weakness in the library. In one manufacturer’s product, the vulnerable function cannot be reached. In a second, it can be used, but malicious exploitation in that product has not been established. A third manufacturer receives reliable evidence of unauthorised exploitation in its own product. Each situation calls for a security assessment. They lead to different conclusions about mandatory reporting of an actively exploited vulnerability.

The regulation defines that term by reference to reliable evidence that a malicious actor has exploited a weakness in a system without its owner’s permission. In paragraph 218 of its guidance published on 27 July 2026, the Commission explains the product-specific test. It expressly distinguishes vulnerable code that cannot be exploited in a manufacturer’s product from a vulnerability that has not been exploited in that product. A shared vulnerable component does not automatically require every downstream manufacturer to submit a mandatory notification. ^{[1] [3]}

That distinction gives technical assessment a central role. A vulnerability entry in a public database helps identify a weakness. The team must still establish its relationship to the product being supplied. Which version includes the code? Is the relevant function reachable? Does the evidence show an attempt, an authorised demonstration or malicious exploitation? The conclusion needs an explanation that can be revisited as new information arrives.

The other reporting trigger is a severe incident affecting the security of a product. Article 14 includes events that negatively affect, or are capable of affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. It also includes events that lead, or are capable of leading, to the introduction or execution of malicious code. This test has its own criteria. It needs to be considered separately, including when an assessment does not establish an actively exploited vulnerability in the product. ^[1]

These obligations attach to the manufacturer as defined in the regulation: the person or entity developing, or having a product developed, and marketing it under its own name or trademark. Scope conditions and exclusions matter, including the treatment of some free and open-source software supplied outside a commercial activity. Software offered free of charge can form part of a commercial product. Contributing code to an open-source repository, on its own, does not make the author a manufacturer. The analysis follows the activity and the product rather than the open-source label. ^[1]

When the clock starts

The legal starting point is awareness. The Commission guidance describes an immediate initial assessment of a suspicious event, leading to a reasonable degree of certainty about the exploitation or incident. It stresses prompt action. Time spent establishing what an indication means is therefore distinct from the reporting period that begins once the relevant conditions are met. This guidance helps interpret the regulation; it offers no licence to leave a warning unexamined. ^[3]

An early warning must be submitted without undue delay and no later than twenty-four hours after awareness. It contains limited information. The fuller notification follows, using the information available, without undue delay and no later than seventy-two hours after awareness. Both periods start from the same event. The second submission describes, among other things, the product, the general nature of the exploitation and measures taken or available to users. Technical investigation can continue as further information is added to the report. ^[1]

Take a purely arithmetic example. The early warning is sent six hours after awareness. Under the counter calculation described by ENISA, the displayed deadline falls at hour fifty-four: six plus forty-eight. The statutory maximum remains hour seventy-two, eighteen hours later. This discrepancy is neither an additional grace period nor evidence of a wrongly imposed penalty. It shows why an interface indicator needs to be checked against its underlying calculation. ^{[1] [2]}

The final report makes the distinction between these clocks even clearer. For an actively exploited vulnerability, it is due no later than fourteen days after a corrective or mitigating measure becomes available. That starting point can be a patch or a measure that reduces the risk. For a severe incident, the final report is due within one month of the fuller incident notification. The deadlines document different response paths. None of these numbers, by itself, tells us when every affected machine will be protected. ^[1]

This separation is useful when following a security crisis. The early warning establishes that the manufacturer possesses information requiring communication. An available mitigation identifies a protective action that can be taken. Installing or applying it in users’ products is a further step. Blurring these dates can make a crisis appear resolved when a practical response has only just become possible.

A wider circle of informed defenders

Under the normal process, the Single Reporting Platform makes a notification available simultaneously to the competent coordinating CSIRT and to ENISA. A CSIRT is a computer security incident response team. The initial coordinator then shares the report with the coordinating teams in Member States where the manufacturer says the product has been made available. Distribution follows the relevant markets and is subject to security exceptions. The law does not prescribe indiscriminate delivery of every file to every European public body. ^[1]

The platform is still being rolled out. In its FAQ updated on 3 October 2026, ENISA says the voluntary-notification function provided for in Article 15 is not yet available. The options established in law therefore need to be distinguished from the features actually offered by the service at that date. ^{[1] [2]}

This creates a capability that a bilateral relationship between manufacturer and customer cannot necessarily provide: combining signals from different products and countries. Imagine several manufacturers affected by a common component, each holding part of the evidence. Bringing those observations together may help response teams recognise a wider threat, select mitigations and reach the relevant organisations. This is the mechanism the system seeks to enable, and one of the benefits ENISA described at launch. Its practical effectiveness will depend on the responses it produces. ^[10]

Shared knowledge also requires restraint. Some information useful to a defender can help an attacker understand the weakness. Choosing recipients and deciding how much detail they need becomes part of the technical response. Article 16 requires strict protocols and need-to-know sharing where no corrective or mitigating measure is available. It also requires ENISA to protect the platform and the information passing through it. ^[1]

User communication has a distinct purpose. After becoming aware of the event, the manufacturer must inform affected users and, where appropriate, all users, including the measures needed to reduce the risk. The Commission guidance explains that detailed information may be limited to the relevant recipients, particularly in sensitive environments. Advising an operator to take a protective action and publishing the weakness’s technical details serve different needs. ^{[1] [3]}

The regulation also separates this confidential route from the public European vulnerability database. Article 17 provides for adding publicly known vulnerabilities, in agreement with the manufacturer, after an update or mitigating measure becomes available. Filing a confidential notification does not automatically create a public database entry. Decisions about content, recipients and timing remain between those two steps. ^[1]

When holding information back can protect users

Concern about expanding the circle too early predates the final legislation. In a letter dated 15 June 2023, EDRi, EFF, the Eclipse Foundation and other signatories warned about public bodies accumulating information on vulnerabilities for which remedies were not yet available. They called for limits on the detail disclosed and safeguards on its use. Their intervention concerned the draft regulation at that time. ^[7]

Assessing the EU’s response requires reading the adopted law alongside Delegated Regulation 2026/881, adopted on 11 December 2025 and published in the Official Journal on 20 April 2026. The latter specifies when an initial coordinator may delay onward dissemination to other CSIRTs. A manufacturer can raise the concern, but the decision belongs to the coordinator and the delay must be limited to the strictly necessary period. ^[4]

One case captures the trade-off. Information in a report could be sufficient to create an exploitation technique, particularly for less capable attackers. The coordinator may delay onward sharing where the cybersecurity risks exceed the security benefits and cannot be adequately reduced through handling and redistribution restrictions. Another route is to send other teams enough information to protect users immediately, then provide the remaining details when a mitigating measure becomes available. ^[4]

The delegated regulation also addresses a remedy expected within seventy-two hours. Subject to the preceding conditions, that prospect can justify a delay in dissemination. If the expected measure does not arrive within that window, the coordinator must share the notification with the relevant CSIRTs. These seventy-two hours belong to the process for sharing information between authorities. They do not extend the manufacturer’s reporting deadline after awareness. ^[4]

The rules even anticipate problems at the receiving end. A coordinator may delay transmission to a particular CSIRT whose ability to preserve confidentiality is in doubt under the specified conditions. An incident affecting the platform can also justify delaying dissemination through it. This acknowledges that a reporting infrastructure itself needs protection. These are contingencies provided for in law, not incidents whose occurrence this investigation has established. ^[4]

ENISA’s access is subject to a narrower exception. In the particularly exceptional circumstances set out in Article 16(2), some details of the seventy-two-hour vulnerability notification can temporarily be withheld. The agency still receives the fact that a report has been made and general information. The conditions include known exploitation confined to the relevant Member State, that state’s essential interests, or an imminent high cybersecurity risk from further dissemination. The provision does not give manufacturers a general option to conceal every initial warning from the agency. ^{[1] [4]}

These safeguards address part of the concern raised in 2023. They leave response teams with a practical judgement: which information will improve defence now, and which could create additional exposure before a remedy is available? The quality of the system will be reflected in how such decisions are explained and reconsidered. A legal framework establishes the rules for those choices; it does not yet reveal every decision made within them.

Eleven days in the life of a patch

The curl project provides a documented example of the kind of timetable the CRA now intersects with. Its advisory for CVE-2023-38545 records a report to the project on 30 September 2023, contact with the distribution coordination list on 3 October, and the release of libcurl 8.4.0 on 11 October, together with the public advisory. There are eleven calendar days between the first and last dates. ^[8]

The value of this chronology lies in the work between its dates. Curl’s current public policy describes confidential intake, assessment, work on a fix and coordinated announcement. It explains why limited disclosure can be useful: it gives people preparing the response room to work before publication. The current policy cannot reconstruct every exchange that took place in 2023. ^[9]

The European deadline cannot simply be applied retrospectively to those eleven days. A case falling under the CRA would require establishing active exploitation as defined in the regulation, identifying the manufacturer concerned and determining when it became aware. Discovery by an authorised researcher alone is insufficient. That distinction prevents confidential preparation of a fix from being treated automatically as a period of wrongful silence. The guidance also clarifies that active exploitation already known before 11 September 2026 does not require retrospective reporting. Exploitation that the manufacturer becomes aware of after that date falls under the new regime. ^{[1] [3]}

The comparison nevertheless shows what the regulation changes. Once its trigger is met, confidential reporting to authorities must fit into the work already underway. A project’s publication schedule and a manufacturer’s regulatory reporting timetable can coexist. Making them work together requires clarity about who assesses the product, who prepares its correction and who is authorised to share which details. Coordination is technical work: it orders the steps that make information protective rather than dangerous.

Open source has more than one role

The people writing an open-source project, the organisation supporting it and the company shipping it in a product may be different actors. The CRA gives certain supporting organisations a specific status: open-source software steward. The definition covers a legal entity other than a manufacturer that systematically and sustainably supports the development of specified free and open-source products intended for commercial activities and ensures their viability. ^[1]

Their regime starts on 11 December 2027. Article 24 requires, among other things, a documented cybersecurity policy and cooperation with market-surveillance authorities. It applies actively exploited vulnerability reporting to the extent that stewards participate in development. For severe incidents, the link is to the networks and information systems they provide for that development. This condition matters because it ties the obligation to the organisation’s particular role in the software chain. ^{[1] [5]}

The clarification of the timetable had a visible organisational consequence. In a public message on 11 September 2026, the Eclipse Foundation, identifying itself as steward of its projects, said it had been ready to report but would use the remaining time to refine its processes after the Commission’s 4 September clarification. Existing contributor security procedures would continue. This is the foundation’s own account; its readiness was not independently audited for this article. ^[6]

The Commission document confirms the date. Version 1.4 of its FAQ, dated 4 September 2026, adds a specific answer on stewards: Article 24(3) applies in December 2027. The clarification explains the timetable. It does not amount to postponing legislation through an FAQ. ^[5]

A project can nevertheless receive requests now from a manufacturer already subject to Article 14. In the example above, a product-security team needs to understand the library before assessing the event. The maintainer knows the code. The integrator knows the configuration it shipped and may hold evidence from affected customers. Those sources of knowledge complement one another. Waiting until every category of actor reaches its regulatory application date would leave that coordination need unanswered in the meantime.

This also shows the limits of analysing the issue through licensing alone. The same free component can exist in a non-commercial project, receive support from a foundation and become part of a commercial product. Its relationship to the CRA changes at each stage. Recognising those differences preserves the distinction between contributors and manufacturers while keeping the manufacturer’s obligations attached to its product. The security needs and the exchange of information between those stages remain. ^[1]

A fix needs a route back upstream

A less prominent provision than the reporting deadlines deserves attention from the open-source community. Article 13(6), applicable with the general obligations from 11 December 2027, requires a manufacturer identifying a vulnerability in an integrated component to inform the component’s manufacturer or maintainer. Where it develops a modification to address the vulnerability in that component, it must share the relevant code or documentation with that party. ^[1]

This adds a flow running in the opposite direction to software downloads. An integrator may discover a failure condition through its product and develop a solution. Sending that knowledge back can allow the original project to examine the problem, improve its own version and benefit other integrators. The mechanism addresses an information imbalance: shared code reaches the manufacturer, while some knowledge about its behaviour remains within the products using it.

The July guidance gives this return path a practical form. It advises following the project’s security channels, avoiding duplicate reports where the maintainer already knows about the weakness, and supplying a verifiable fix compatible with the component’s licence. It also explains that the CRA does not require the maintainer to accept the proposed change. Technical review retains its purpose: a solution suited to one product may need a different treatment in a shared component. ^[3]

The assessment must also locate the defect. An error introduced by the way a manufacturer assembles its own application is not necessarily a vulnerability in an integrated component. The guidance distinguishes these cases. It nevertheless encourages communicating useful observations when integration reveals a security-relevant behaviour that was previously less apparent. This avoids treating the upstream project as the automatic recipient of every problem in a downstream product. ^[3]

The potential benefit is tangible. A manufacturer fixing its local copy can give the maintainer a way to evaluate the same improvement for other users. But a sharing obligation cannot guarantee the modification’s quality, its acceptance or its eventual distribution. Those stages still require technical exchanges and explicit choices. The law establishes a relationship; cooperation must produce something that others can use.

Protection happens at the end of the chain

The application timetable creates one more asymmetry between seeing a risk and being able to fix it. Article 14 also applies to products placed on the market before December 2027. The Commission guidance explains that reporting can remain necessary after support has ended when a manufacturer becomes aware of a qualifying event. That information duty does not, by itself, reactivate the full general vulnerability-handling requirements for those products. ^{[1] [3]}

A warning about an older product may still let users reduce exposure, disable a feature or prepare a replacement, depending on the measures actually available. Its value depends on whether the recipient can act. Any evaluation of the CRA should therefore set report volumes alongside other observations: time to an available protective measure, distribution to the relevant versions and users’ ability to verify their own status. These are proposed evaluation criteria, not a reconstructed performance series.

Article 17 requires periodic technical analysis of trends by ENISA, with the first report within twenty-four months of the reporting obligations taking effect in September 2026. Article 70 also sets 11 September 2028 as the deadline for a Commission assessment of the platform’s effectiveness. Among the public documents examined for this investigation, we found no outcome assessment already allowing us to measure patching times or users protected through the new reporting system. That absence of public confirmation establishes neither success nor failure. ^[1]

What the documents do establish is an institutional choice. Europe wants to receive warnings while the technical response is still taking shape. It provides restrictions on onward sharing to protect that phase and, for 2027, prepares a more explicit return flow of defects and fixes through the software chain. The useful test will be to follow proposed mitigations through shipped versions to users able to apply them. The rules describe that path; evidence of its results remains to be assembled.

For further reading, our investigation into cyber access in wind and solar follows the allocation of responsibility around physical equipment. The investigation into invisible suppliers of European banking risk examines a separate regulation, DORA, governing the financial sector’s reliance on IT providers. These articles place product security within the wider chain of operations and outsourcing.

Sources and method

Documentary research closed on 10 October 2026. The regulation and delegated act provide the binding rules; guidance and FAQs explain their application. ENISA and Eclipse Foundation statements are attributed to their authors. The curl case predates the CRA. Hypothetical products and the counter calculation illustrate mechanisms. No original interviews, authenticated platform access, security audit, actual notification or confidential case-file review was conducted. The July guidance was checked directly in the Commission’s official PDF annex. The Commission FAQ was read in its official Markdown version. No effectiveness results missing from the examined evidence are reconstructed.