EU Cyber Resilience Act reporting rules become enforceable September 11

The reporting clock starts September 11

Reporting obligations under the EU's Cyber Resilience Act become enforceable on September 11, 2026, and software teams need to know beforehand whether that clock applies to them. That is the core message of a post on dev.to by a practitioner at Faultline Security, a firm that runs penetration testing and AI red teaming engagements for SaaS companies.

From that date, according to the post, manufacturers of "products with digital elements" must report actively exploited vulnerabilities and severe security incidents through a single platform on a fixed schedule: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days for vulnerabilities or within a month for severe incidents. Penalties for mishandling the reporting duty can reach €15 million or 2.5% of global turnover.

The post is careful to distinguish this from the CRA's full deadline. CE marking and the remaining essential requirements arrive on December 11, 2027. September 11 covers one narrow slice: who has to report what, and how fast.

The scope question

Where teams stumble, the author writes, is deciding whether the law covers them at all. For SaaS the split is fairly clean. Purely browser-delivered software, with nothing installed on a customer's machine or infrastructure, generally falls under the EU's NIS2 directive rather than the CRA.

Shipping anything installable changes the picture. Desktop apps, mobile apps, browser extensions, SDKs embedded in customers' code, CLI tools and on-premises agents or connectors all count as products with digital elements, the post argues. And when a cloud back end is essential to how that installed component functions, the remote processing is swept in as well.

That leaves a grey area that many B2B vendors occupy without realising it: a web application as the flagship product, accompanied by a lightweight desktop client, a monitoring agent customers install, or an SDK for integrations. Any one of those add-ons can pull the company into CRA territory even though the core product is pure SaaS.

The author reports having the "does this apply to us" conversation with four founders in a single month. All four assumed the answer was yes; two were wrong. The mistake cuts both ways. Overestimating scope wastes compliance effort, while underestimating it means missing a legally binding reporting deadline.

Detection is the hard part

The procedural side of the rules is the easy half, the post argues. Any team can build a checklist around the 24-hour, 72-hour and final-report intervals. The genuinely difficult problem is noticing the thing that has to be reported. Most teams do not learn about vulnerabilities through their own monitoring first; they hear about them from a customer, an outside researcher, or an attacker who is already inside.

Under the new regime, that moment of discovery starts a legal countdown while the team is simultaneously triaging an unfamiliar corner of its own codebase and drafting a consequential report for the first time. The author's case, offered by someone who sells testing services and acknowledged the incentive, is that discovering your weak points on your own schedule is a fundamentally different experience from discovering them live, mid-incident, with a regulator watching the clock.

Why it matters

September 11 is a concrete, enforceable date rather than a distant compliance horizon, and it arrives years before the CRA's broader requirements in 2027. A 24-hour early warning obligation only works if a team can actually detect active exploitation in its own systems, which turns part of a regulatory duty into an engineering and observability problem, not just a legal one. The dev.to post also suggests that scope misjudgement is widespread among smaller companies, with founders guessing wrong in both directions. For any team shipping an SDK, agent, extension or desktop client alongside a web product, the first practical step is mapping which components are covered and who owns the reporting workflow before the deadline, not after an incident forces the question.