The EU's 24-hour vulnerability reporting duty took effect on 11 September, and the single platform that receives it went live the same day
This runs the other way from most of what this publication records, which is why it is worth setting down rather than filing as a compliance date. A duty that sat with each vendor and each national CERT now passes through one platform, so from 11 September a single European body holds a structured, time-bounded feed of every actively exploited vulnerability in every connected product sold into the largest regulated market in the world, within a day of the manufacturer learning of it. Everything that makes that feed valuable for defence makes it valuable to anyone who obtains it, and the regulation's answer to that is confidentiality measures and a narrow exception on dissemination, which is a procedural answer to a structural question. The open-source half is unresolved rather than solved: the software supply chain rests on people who do not sell the finished product and cannot staff a 24-hour clock, and the Act's response is to invent the steward as an intermediate category and defer its obligations by fifteen months. Whether accountability can be attached to a volunteer ecosystem without converting it into a vendor is the question that the December 2027 date postpones.
The European Union's Cyber Resilience Act reached its first operative deadline on 11 September 2026, and the reporting platform it depends on went live the same day.
From that date, manufacturers of products with digital elements placed on the EU market must report actively exploited vulnerabilities and severe security incidents. The clock runs in three stages: an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure becomes available for a vulnerability, or within one month of the 72-hour notification for a severe incident. Notifications go to the CSIRT designated as coordinator in the member state of the manufacturer's main establishment, and are made available to ENISA at the same time unless particular exceptional circumstances apply. The receiving CSIRT passes the notification without delay to other CSIRTs across the Union, and shares it with market surveillance authorities for enforcement.
All of it runs through one channel. The CRA Single Reporting Platform, built and operated by ENISA, became operational on 11 September 2026, the day the obligation it serves took effect. A community guide published the same day by the Open Source Security Foundation notes that voluntary reporting under Article 15 is not available in the platform at launch and will be added at a later stage.
The architecture is the story. Reporting duties on vendors are not new, and neither are national CERTs. What is new is that one European body now holds a structured, time-bounded feed of every actively exploited vulnerability in every connected product sold into the largest regulated market in the world, within a day of the manufacturer learning of it. That is a real defensive gain, and in the same breath it is the most concentrated inventory of live exploits anyone has assembled. The Act's answer to the obvious risk is confidentiality measures on the platform and a narrow exception permitting dissemination to be delayed or withheld, which is a procedural answer to a structural question. [UNVERIFIED] That reading of the risk is this publication's analysis and is not a finding by the Commission, ENISA or OpenSSF.
This publication usually records functions moving outward to the edge. This one moves in the other direction, deliberately, and the honest thing is to say so rather than to file it as a compliance date. The case for it is not weak: a vulnerability being exploited against consumers in one member state is being exploited in the others, and twenty-seven separate reporting paths served nobody. The question worth holding open is whether the concentration is bounded by the purpose, or whether a database built for coordination becomes, over time, a database used for other things because it exists.
The open-source half is deferred rather than settled. Nothing changed on 11 September for open-source projects or their maintainers; no reporting obligation attaches to them. The Act's intermediate category, the open-source software steward, picks up reporting duties only on 11 December 2027, and stewards may not affix the CE marking, which keeps them formally distinct from manufacturers. The reasoning is sound as far as it goes: the supply chain rests on entities that do not sell the finished product and cannot staff a 24-hour clock, and treating them as vendors would end the arrangement rather than secure it. Whether accountability can be attached to a volunteer ecosystem without converting it into a vendor is what the 2027 date postpones. In the meantime OpenSSF's advice to maintainers is preparatory rather than legal: keep a security contact current, publish a security policy, and expect manufacturers to come asking.
[UNVERIFIED] The enacting text of Articles 14 and 71 of Regulation (EU) 2024/2847 was not read for this piece. The article numbering, the application dates and the deadlines above come from the European Commission's own CRA reporting page, ENISA's platform FAQ and the OpenSSF guide, which agree with each other. [UNVERIFIED] That grid-edge hardware such as inverters, smart meters and EV chargers falls within products with digital elements is this sweep's reading of the scope, and was not confirmed against the Act's annexes or Commission guidance. [NEEDS DATA: how many notifications the platform has received since 11 September]
Public comments
Loading…