On 11 September 2026, the Cyber Resilience Act's reporting obligations began to bind manufacturers, and ENISA launched the Single Reporting Platform (SRP) the same day. Anyone placing a product with digital elements on the EU market must now report actively exploited vulnerabilities and severe incidents. Regulation (EU) 2024/2847 has been on the books since 2024. This is the first part of it with legal effect, and it arrives 15 months before the main security requirements.
What changed on 11 September
Per the Commission's reporting page, a manufacturer must submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, and a full notification within 72 hours. The final report is due no later than 14 days after a corrective measure is available for a vulnerability. For a severe incident it is due within a month of the 72-hour notification.
Manufacturers report once, through the platform, to ENISA and to the CSIRT of the member state where they have their main establishment, which acts as coordinator. Unless exceptional circumstances apply, that CSIRT shares the notification without delay with the CSIRTs of every state where the product is available. ENISA's launch announcement says ENISA receives the notification at the same time. Open-source software stewards join in on 11 December 2027, the same date the main requirements apply.
The strongest case for the rule
The case for this design is serious. Attackers exploit flaws within hours, while defenders in 27 member states have historically learned of them through vendor blogs, security researchers or leaks, each on a different timeline. A common clock and a common intake mean a flaw abused against one customer in Lyon is visible to authorities in Lisbon and Warsaw before it is abused there. A single platform also spares manufacturers from filing separate reports with 27 national authorities. If the alternative were a patchwork of national portals, the SRP is clearly the better design, and the Commission deserves credit for building it.
Where proportionality gets tested
The difficulty is the 24-hour trigger. It runs from awareness of active exploitation, which is often before a fix exists. The information at issue is then the most sensitive kind: a working exploit path in a product with no patch. Every additional recipient is an additional place it can leak. The Commission's page acknowledges the risk by letting CSIRTs delay onward dissemination on justified cybersecurity grounds, and it points to a delegated act adopted on 11 December 2025 that specifies those grounds. That exception is well designed on paper. But the default is dissemination, and the strength of the safeguard will depend on how consistently 27 national CSIRTs apply it under time pressure. Nobody has yet published evidence on that.
A second issue is overlap. As Hogan Lovells' analysis notes, CRA reporting runs alongside GDPR, NIS2, DORA and sector rules. The "single" platform covers only CRA notifications. A company that ships connected devices and also operates as an essential entity can still face several clocks for one event. A serious effort to lower compliance cost would let one submission satisfy parallel duties where the facts are identical.
Third is enforcement. The same analysis says Article 14 breaches sit in the highest penalty tier, with fines of up to €15 million or 2.5% of worldwide annual turnover. The Commission's CRA summary adds that penalties are set nationally and that micro and small enterprises may not be fined for missing the 24-hour deadline. That carve-out is sensible. A five-person hardware startup that misses an early warning while scrambling to fix a flaw is not the target of the law. It also shows the drafters knew the clock is hard to meet, which is the point.
What a proportionate rollout looks like
The objective is faster defence, not more filings. Three tests will show whether the rollout is working:
- Early warnings should stay lean. The 24-hour report should be a brief flag, with technical detail deferred to the 72-hour notification. CSIRTs should not treat a thin early warning as non-compliance.
- Delay grounds should be used, and their use should be reported. ENISA should publish aggregate figures on how often onward sharing is held back. Without that, nobody can tell whether the safeguard works.
- Open-source stewards need a light path. Their obligations start in December 2027, and the guidance issued before then will decide whether volunteer-run projects can take on stewardship at all. The Open Source Security Foundation is already publishing steward guidance and community playbooks, which suggests the ecosystem is preparing seriously. Regulators should meet that effort with clear, workable expectations.
The reporting regime is a reasonable bet that faster shared visibility beats the risks of wider circulation. It is not free of cost, and its main risk is not paperwork. It is that sensitive pre-patch information passes through more hands than the security of the affected users can afford. The first year of data, especially on how often CSIRTs use their power to delay sharing, should decide whether the design needs adjusting before the full obligations arrive in December 2027.