Two dates matter here, and they're the same date. 11 September 2026 is when the CRA's vulnerability and incident reporting obligations under Article 14 become mandatory. It's also, according to the European Commission's own page on CRA reporting, when "the Single Reporting Platform will be operational" — notice that it won't be running before. If you're a manufacturer whose product falls under active-exploitation reporting, the tool you're supposed to report through and the obligation to report through it start on the same morning.
What Article 14 actually requires
If a product with digital elements has a vulnerability that's being actively exploited, or the manufacturer experiences a severe incident affecting it, three clocks start running:
24 hours — early warning to ENISA and your national CSIRT, from the moment you become aware.
72 hours — a fuller notification: what's known, its severity, and your assessment so far.
14 days — a final report once a corrective measure is available (vulnerabilities), or 1 month for severe incidents.
These aren't new. They've been public since the regulation was adopted. What's newer, and worth planning around specifically, is how you report: through ENISA's Single Reporting Platform (SRP), a single submission point meant to route your notification to the right national CSIRT (and any others where the product is sold) without you filing separately in every member state.
What was still unsettled when we wrote this
Update, 14 September: ENISA confirmed the SRP launched on schedule on 11 September — the uncertainty below is exactly what we didn't know a week before.
As of this writing, ENISA's own FAQ describes the SRP process — registration via EU Login, who needs access, what each report contains — without stating that the platform is live for submissions today. The Commission's page is explicit that it's scheduled for 11 September, and secondary reporting from late August describes functional and security testing as still underway, with no confirmed date earlier than the deadline itself. In other words: the infrastructure you're required to use is expected to open on exactly the day you're required to start using it, with no public buffer and — as far as we could find — no documented fallback procedure if it slips.
We're not the first to notice this, and we don't have any special insight the Commission and ENISA don't have. But if you're a small manufacturer without a compliance team tracking this daily, it's easy to miss: "the reporting platform" and "the reporting deadline" sound like two separate things you can prepare for independently. They aren't. If you're planning to deal with SRP registration when you first need to file a report, you're planning to do it under a 24-hour clock, possibly on infrastructure that just opened.
*What to do regardless of whether the platform is ready on day one
*
None of this depends on the SRP launching exactly on schedule. It depends on you not being the one holding things up when it does:
- Register before you need to, not when you need to. ENISA's guidance points to EU Login as the entry point, with at least two named people holding access — not one, so a single absence doesn't stall a 24-hour clock. Do this now; don't wait to see if the launch slips.
- Decide internally, today, who does what in the first 24 hours. Who assesses whether a vulnerability is "actively exploited" versus merely disclosed? Who has the authority to file without waiting for a committee? If the answer is "we'd figure it out," that's the gap to close before September, not during an actual incident.
- Make sure you'd actually know in time. Article 14's clock starts when you become aware, not when a customer emails you. That only works if you're actually watching for it — matching your shipped SBOM against CVE feeds and exploitation signals (CISA KEV, EPSS) on an ongoing basis, not re-discovering your own dependency tree during a scramble.
- Keep a written record of your own readiness. If the SRP genuinely isn't operational on 11 September, being able to show you registered early, had a process, and attempted to comply is a materially different position than not having looked at any of this until the deadline hit.
Where this connects to your SBOM
Point 3 above is the one most manufacturers underinvest in, because it looks like a monitoring problem and gets treated as one — a dashboard nobody checks — rather than the input to a legal clock. The SBOM you already have (or should have) from your build system is what answers if you are affected in a matter of minutes instead of days.
Want to see where your own SBOM stands against open CVEs and exploitation flags right now — before you're doing it under a 24-hour clock? Upload it (or try the built-in ESP32 sample — we never store it) and get prioritized CVEs plus a checklist of what's still missing for the CRA / EN 18031 technical file: run the free check.
This article is an engineering-oriented overview, not legal advice. Primary sources: Regulation (EU) 2024/2847 (CRA), Article 14; European Commission, "Cyber Resilience Act – Reporting obligations" (digital-strategy.ec.europa.eu); ENISA Single Reporting Platform FAQ.
I'm an embedded engineer who's been tracking the EU Cyber Resilience Act rollout while building SBOMReady, a free SBOM checker for embedded/IoT firmware. Cross-posting this one because the platform/deadline timing gap it describes surprised me when I looked into it — curious if anyone else preparing for Article 14 has found an official contingency plan I missed. Questions welcome below.
