The EU Cyber Resilience Act's September 11 Deadline: What Software Teams Need Ready

If any product your company ships touches the EU market and has a network connection of any kind, you have a new 24-hour clock starting September 11, 2026. That’s when Article 14 of the EU Cyber Resilience Act goes live: the obligation to report an actively exploited vulnerability to European regulators within a day of finding out about it.

This isn’t a distant compliance horizon. It’s five weeks away as of this writing, and the scope is wider than “we sell hardware in Germany, this must be about IoT devices.”

Who counts as a manufacturer here

The CRA’s term is “manufacturer,” but read it as “anyone who places a product with digital elements on the EU market.” That covers hardware with a network connection, obviously, but also software packages, firmware, operating systems, and developer libraries distributed commercially. If a component you build gets installed on a customer’s infrastructure in the EU, whether it’s a physical device or a library pulled in via a package manager, you’re likely in scope.

Where the line actually sits: pure SaaS, a cloud service with nothing installed on the customer’s side, generally falls outside this specific reporting obligation. The distinction the regulation draws is between a product placed on the market and a service delivered remotely. That said, plenty of “SaaS” products ship an agent, an SDK, or an on-prem connector alongside the hosted piece, and that installed component can pull the whole offering back into scope. If your architecture includes anything a customer runs on their own infrastructure, don’t assume the SaaS label exempts you without checking.

The reporting clock

Once you know a vulnerability in your product is being actively exploited, or you’ve had a severe security incident affecting it, three deadlines start running, all filed through ENISA’s Single Reporting Platform, simultaneously to ENISA and to your designated coordinating CSIRT:

Stage	Deadline	What’s required
Early warning	24 hours	Confirm the issue exists and is being exploited; minimal detail is acceptable at this stage
Detailed notification	72 hours	Fuller technical detail: what’s affected, how it’s being exploited, initial mitigation guidance
Final report	14 days after a fix is available	Full writeup once remediation exists

The 24-hour window is the one that actually changes how a team operates. Most incident response processes are built around getting a fix out fast; this adds a parallel obligation to tell a regulator you’re aware of the problem before you’ve necessarily finished understanding it. That means the report-drafting step needs to be something your team can start same-day, not something that waits for the postmortem.

What “severe incident” means beyond active exploitation

Active exploitation is the clearer trigger, something is happening in the wild, right now, against your product. “Severe incident” is broader and covers security incidents affecting your product that have a significant impact, even without confirmed active exploitation of a specific CVE. If your team already runs a severity classification for incident response, a P1 outage or breach with a defined response clock, that’s the natural place to also flag “does this trigger a CRA reporting obligation,” rather than building a second, separate decision tree nobody remembers exists until it’s needed.

The cost of getting this wrong

Fines for breaching the CRA’s core obligations, including the reporting requirement, run up to 15 million euros or 2.5% of a company’s total worldwide annual turnover, whichever figure is higher. That ceiling puts this well past the territory of a compliance checkbox a five-person engineering team can defer. It’s also worth noting that September 11 is a reporting deadline, not the finish line for the regulation as a whole; broader requirements around SBOMs and technical documentation phase in on a longer timeline running through December 11, 2027. Getting the reporting process working now buys you a real trial run before the rest of the CRA’s obligations land.

What to actually do before September 11

Three things, in order. First, get a straight answer on whether anything you sell into the EU counts as a product with digital elements, hardware, software, firmware, or a commercially distributed library all qualify, and don’t let “we’re mostly SaaS” be the whole answer if any component gets installed on a customer’s side. Second, name an owner for the 24-hour clock: a specific person or on-call rotation who gets paged the moment a report of active exploitation comes in, with authority to file the early warning without waiting for a full committee sign-off. Third, and most overlooked, make sure you’d actually detect active exploitation of your product in the first place. A reporting deadline is meaningless against a vulnerability nobody noticed was being used.

Five weeks is enough time to get the first two of those genuinely solid. The third one is an ongoing security posture question, not a September 11 checkbox, and it’s the one worth starting on today regardless of the regulatory deadline attached to it.