Three months of "not yet live" updates end this week. ENISA has scheduled the Single Reporting Platform (SRP) the mandatory channel for Cyber Resilience Act incident and vulnerability notifications to go operational on 11 September 2026, the exact date Article 14 reporting duties enter into application. For European developers, product security teams, and manufacturers placing connected products on the EU market, this is no longer a compliance deadline on a roadmap slide. It is a live, 24-hour regulatory clock.
If your team builds IoT devices, embedded firmware, industrial controllers, or software with a network connection sold anywhere in the EU, this article breaks down exactly what the Cyber Resilience Act (Regulation (EU) 2024/2847) requires you to report, when, and through which channel without the guesswork.
What Is the ENISA Single Reporting Platform?
The Single Reporting Platform is the electronic entry point established under Article 16 of the CRA. Instead of notifying multiple national authorities separately, a manufacturer files one report through the SRP, which then routes it simultaneously to the national CSIRT designated as coordinator for the manufacturer's main EU establishment, and to ENISA itself.
Crucially, ENISA has confirmed that no reporting API will be offered at this stage. Submissions go through a browser-based interface, authenticated via EU Login, the European Commission's shared sign-in credential. Internal detection and triage workflows can be automated, but the final act of filing is manual. Teams that assumed system-to-system integration would carry them through launch week need to rebuild that assumption immediately.
What Developers Must Actually Report Under Article 14
Article 14 does not ask you to report every bug ticket. It creates two distinct reporting tracks, and understanding the difference is the single most important thing a developer or product security lead can do before touching the platform.
1. Actively exploited vulnerabilities. If a vulnerability in your product with digital elements is being exploited in the wild not theoretical, not internally discovered during a code review, but actually under active exploitation you are obligated to notify ENISA and your coordinating CSIRT.
2. Severe incidents having an impact on the security of the product. This covers incidents that materially affect the product's ability to protect the confidentiality, integrity, or availability of data or functions.
For both tracks, the CRA imposes a rigid three-stage timeline:
- 24 hours — an early warning, submitted as soon as the manufacturer becomes aware.
- 72 hours — a more detailed notification confirming severity, indicators of compromise, and corrective measures underway.
- 14 days — a final report once the vulnerability or incident is resolved, including a root-cause assessment.
There is no grace period for onboarding. If your organisation becomes aware of a qualifying event on 12 September, the 24-hour clock starts regardless of whether your EU Login credentials, delegate list, or internal escalation chain are ready.
This is precisely why compliance specialists have been urging manufacturers to treat the reporting obligation as a distinct, earlier milestone from the CRA's broader December 2027 conformity deadline. VISTA InfoSec's detailed Cyber Resilience Act compliance checklist walks through exactly how to sequence this preparation across scoping, documentation, and reporting readiness.
Who Is on the Hook — and Who Isn't
Manufacturers carry almost the entire reporting burden. Importers and distributors have separate, narrower duties around conformity verification and CE marking, but the 24/72-hour reporting clock sits squarely with the manufacturer of the product with digital elements. Open-source software stewards also fall within ENISA's guidance and should register and validate on the SRP only when they have an actual notification to file, to avoid overloading national CSIRT teams during the launch window.
For manufacturers not established in the EU, the coordinating CSIRT is determined by the country of the manufacturer's authorised representative not by where the company is headquartered. This detail catches non-EU vendors off guard more often than any other part of Article 14.
What Developers Should Prepare Before Filing a First Report
Even with the platform now operational, several practical gaps remain open. The official reporting data format is set by a separate European Commission implementing act, and full registration handbooks, dry-run environments, and the finalised list of national CSIRT coordinators have been rolling out only in the weeks immediately before launch.
What development and product security teams can control right now:
- Create EU Login accounts in advance for a primary and secondary organisational representative, using durable work email addresses.
- Maintain a live product inventory mapping every shipped SKU to a manufacturer identity, an SBOM, and a named PSIRT contact.
- Build (and rehearse) the internal detection-to-decision workflow that determines, within hours, whether an event meets the "actively exploited" or "severe incident" threshold.
- Name a reporting owner and a documented backup, since the 24-hour clock does not pause for someone being on leave.
- Run a full dry-run submission the moment ENISA's test environment is accessible, rather than waiting for a real incident to be your team's first encounter with the interface.
Because classification (Default, Important I, Important II, or Critical under Annex III/IV) determines both your conformity route and how deep your documentation needs to go, organisations still mapping their product portfolio against these categories should not wait. VISTA InfoSec's Cyber Resilience Act gap assessment guide is a useful reference for structuring that inventory and documentation work alongside reporting readiness, rather than treating them as separate projects.
Penalties Make This Non-Negotiable
Non-compliance with the CRA carries fines of up to €15 million or 2.5% of global annual turnover, whichever is higher figures that place it firmly alongside GDPR and NIS2 in terms of enforcement weight. For a regulation whose full conformity requirements do not bite until December 2027, it is notable that the reporting obligation arguably the operationally hardest part to get right under time pressure is the piece that started first.
The Bottom Line for European Developers
The SRP going live does not mean your compliance work is finished; it means the clock that actually matters has started. Article 14 rewards organisations that have already separated "actively exploited vulnerability" from routine bug triage, pre-built their EU Login access, and rehearsed their escalation path. Teams still treating CRA reporting as a 2027 problem are now operating under a live regulatory deadline with real financial exposure.
Need help getting audit-ready for Article 14?
VISTA InfoSec's compliance specialists work with manufacturers across the EU market on exactly this transition from product classification through to Single Reporting Platform readiness.
Top comments (0)