The CRA Reporting Deadline Is Two Months Away

If your product has a chip that talks to a network, a new legal clock is running out under EU law, and it isn't the one most people expect. From 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents, starting with an early warning within 24 hours of finding out, according to the European Commission's own Cyber Resilience Act reporting page. That's a little over two months from today. It lands well ahead of the Regulation's better-known 2027 deadline, and it applies to products already on shelves, not just new launches.

When does Cyber Resilience Act reporting actually start?

The Cyber Resilience Act (Regulation (EU) 2024/2847, usually shortened to the CRA) entered into force back in December 2024, but almost none of its duties applied straight away. The Regulation was written with a staggered timeline, and that's caused genuine confusion, because most coverage of the CRA talks about "2027" as if it's the only date that matters. It isn't.

The next milestone is much closer. Article 14 of the Regulation, the vulnerability and incident reporting duty, applies from 11 September 2026. That's the date this article is about, and it's the first CRA obligation that lands directly on product teams rather than on the assessment industry around them.

The table below sets out the three dates that matter, in order.

If you want the full picture of what the CRA covers, what counts as an in-scope product, and how the essential requirements work, our full CRA guide for hardware startups goes through that in detail. This piece is narrower on purpose: it's about the reporting duty that starts in roughly nine weeks, not the whole Regulation.

What is the CRA's 24-hour reporting requirement, exactly?

Article 14 asks for three separate submissions, each with its own clock, and they only start once you know about the problem, not once the platform is switched on.

The first is an early warning, due within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident. It doesn't need to be a full write-up. It's meant to be a quick flag that something serious is happening, including whether you suspect the issue crosses borders. The second is a fuller notification, due within 72 hours, with more detail on the nature of the issue and, where known, any indicators of compromise. The third is a final report: no later than 14 days after a corrective measure becomes available, for an actively exploited vulnerability, or within one month for a severe incident.

"Actively exploited" and "severe" are doing a lot of work in that sentence. An actively exploited vulnerability is one where there's reliable evidence someone has already used it against real products, not just a theoretical weakness a researcher spotted in your code. A severe incident is one that meaningfully harms the availability, authenticity, integrity, or confidentiality of the product. A minor bug with no known exploitation isn't what Article 14 is asking about, but the moment you have credible evidence of active exploitation, or an incident serious enough to hit one of those four properties, the clock is running whether or not you feel ready.

Who has to report, and for which products?

The duty falls on manufacturers of "products with digital elements", the CRA's term for anything with software or hardware that connects, directly or indirectly, to another device or a network. That's a genuinely wide net, and it's covered properly in our full CRA guide and the CRA glossary entry, so it isn't repeated here in full.

What matters for this specific deadline is scope in time, not just scope in product type. The reporting obligation applies to products already made available on the EU market, including ones sold long before 11 September 2026 and long before the December 2027 full-application date. In other words, you don't get a grace period because your product shipped in 2023. If it's still on the market and it still has digital elements, the reporting duty attaches to it from September regardless of when you launched it.

Where do you actually send the report?

Reports go through a single channel: the CRA Single Reporting Platform (SRP), built and run by ENISA, the EU's cybersecurity agency. You submit once, to the Computer Security Incident Response Team (CSIRT) in the country where your business is mainly established, and the information is shared with ENISA and, where relevant, with other national CSIRTs, without you having to file the same report in multiple countries.

There's a timing wrinkle worth knowing about now, in July, rather than finding out about it in September. ENISA has said it will publish access instructions, training material, and dry-run exercises during June 2026, ahead of the platform going live alongside the reporting duty itself. The practical reading is that the SRP is being built and tested right up against its own start date, so the sensible move is to register and dry-run as soon as ENISA opens that window, rather than assuming there'll be slack once September arrives. Your legal reporting clock starts from when you become aware of a qualifying issue, not from when the platform happens to be running smoothly.

A hypothetical: a smart lock startup gets a bug report

Say you're a six-person startup selling a Wi-Fi-enabled smart lock into Germany and the Netherlands. Your firmware runs on an embedded Linux build and leans on a handful of open-source libraries, including an MQTT client for cloud messaging. On a Friday evening, a security researcher emails your support inbox: the MQTT library has a known flaw that lets an attacker on the same network intercept lock-state messages, and the researcher has found evidence it's already being probed by bots scanning for exposed devices.

That's an actively exploited vulnerability, not a theoretical one, so the 24-hour clock starts the moment someone on your team reads that email and understands what it means, not on Monday morning when the office reopens. Your early warning to your national CSIRT needs to go in by Saturday evening. The 72-hour full notification, due by Monday, would set out what you know about the library, the affected firmware versions, and any early indication of how widely it's been probed. Once you've shipped a patched firmware build, most likely a matter of days if the fix is a library version bump, your final report is due within 14 days of that patch becoming available. None of that requires a finished forensic investigation on day one. It requires a documented process that someone actually owns, so nobody is improvising the wording of an early warning at 11pm on a Friday.

Is anyone actually ready for September?

Not obviously, no. A Linux Foundation and OpenSSF readiness survey published in late June 2026 found that 66% of respondents said they were unfamiliar with the CRA, up from 62% a year earlier, which is the wrong direction for a Regulation whose first hard deadline is now weeks away. Only 34% of respondents correctly identified December 2027 as the date for full compliance, and just 41% expected to hit full compliance by that date at all, with 39% saying they were entirely uncertain whether they'd manage it.

Jan Wendenburg, CEO of the industrial cybersecurity firm ONEKEY, put the practical stakes plainly in a February 2026 press statement marking the start of what he called the CRA's operational phase: "The manufacturers concerned must have their internal processes, documentation, technical evidence, and safety requirements in place by then at the latest." September isn't a soft target. It's the date the clock starts counting in hours, not months.

What to do before 11 September 2026

The awareness gap in that survey is a warning, not an excuse. A few concrete steps make the difference between scrambling in September and having something workable in place already:

• Name one person, even in a small team, who owns vulnerability handling and knows they're responsible for starting the 24-hour clock.
• Write down, in plain language, what counts as an actively exploited vulnerability or a severe incident for your specific product, so nobody has to debate definitions mid-incident.
• Register for ENISA's Single Reporting Platform access and dry-run material as soon as it's published, rather than waiting for September.
• Check whether you already maintain a vulnerability disclosure channel; if you sell into the UK too, the UK PSTI regime already expects one, so you may be closer to ready than you think.
• Use our compliance check tool to confirm whether your product counts as one "with digital elements" under the CRA, and read the CRA regulation page for the underlying legal text.

None of this replaces reading Article 14 itself, or getting advice specific to your product and your market. But a documented process, owned by a named person, beats no process at all, and it's the difference between a calm early warning and a panicked one.

The reporting duty is the opening move in a longer CRA story that runs through to full application in December 2027, when essential requirements, conformity assessment, and CE marking under the CRA all land together. Get the reporting process sorted first, since it's due first, then use the eighteen months after that to work through the fuller requirements at a sane pace.