The 24 Hour Clock Starts on 11 September, and Most of the CRA Does Not

On 11 September 2026, nine days from the date on this article, Article 14 of Regulation (EU) 2024/2847 starts applying. That is the Cyber Resilience Act, and Article 14 is the reporting duty. From that morning, manufacturers of products with digital elements placed on the EU market must report actively exploited vulnerabilities and severe incidents affecting the security of those products. The rest of the CRA, the essential cybersecurity requirements, the conformity assessment, the CE marking, does not apply until 11 December 2027. That gap is the whole problem. Almost every roadmap we have seen treats the CRA as a 2027 item sitting behind a certification project, and the one obligation with a stopwatch attached arrives fifteen months ahead of it.

The mechanics are tight and worth stating exactly. Two things trigger the duty: a vulnerability in your product that is being actively exploited, and a severe incident having an impact on the security of your product. On either trigger you file an early warning within 24 hours of becoming aware, a full notification within 72 hours, and then a final report, no later than 14 days after a corrective measure becomes available in the vulnerability case, or within one month in the severe incident case. Filing happens once, through the CRA Single Reporting Platform, which the Commission has said will be operational by 11 September. The report goes to the CSIRT in the country of your main establishment and, absent exceptional circumstances, to ENISA at the same time, and onward without delay to the CSIRTs of every territory where the product is available. Note where the clock starts. It starts at awareness, not at the end of triage, not when engineering confirms the finding, and not when legal has formed a view.

Scope is where most teams will get this wrong, in both directions. The CRA covers products with digital elements, and it explicitly does not cover cloud services that are simply SaaS, PaaS or IaaS. A lot of founders stop reading at that line and conclude they are outside. The carve back in is the definition of remote data processing: processing at a distance, using software designed and developed by the manufacturer or under the responsibility of the manufacturer, whose absence would stop the product from performing one of its functions. If you ship something that runs on the customer machine and calls your backend to work, the backend is not a separate SaaS product, it is part of the product. Desktop apps, IDE extensions, command line tools, browser extensions, agent runtimes, self hosted and on premises builds, firmware and anything embedded all sit squarely inside. So does software you shipped years ago and stopped thinking about, because the obligation attaches to products on the market, not to your current release train.

This lands hard on the category of tooling we write about most. The AI development stack has spent two years distributing software that runs on developer machines and inside customer networks: coding agents and IDE extensions in the Cursor and GitHub Copilot mould, local agent runtimes, browser agents, and the fast growing population of MCP servers that are published as packages, executed on the client, and wired to a vendor backend. Very little of that is SaaS in the CRA sense. We have argued before that MCP servers are vendors and that agent frameworks are ordinary software, a point the run of CVEs in that ecosystem made for us. The CRA now says the same thing in law, and it puts a 24 hour deadline behind it. If you maintain free and open source software commercially and support it on a sustained basis, look separately at the open source software steward regime, which is deliberately lighter but is not nothing.

There is a genuine dividend for anyone already working through the EU AI Act. CRA Article 12 creates a presumption of conformity in the direction you would want: a product with digital elements that is also a high risk AI system, and that meets the CRA essential cybersecurity requirements, is deemed to satisfy the cybersecurity requirements of Article 15 of the AI Act for the requirements covered. In plain terms, the CRA security work is not a second tax on top of the AI Act, it discharges part of it. The catch is timing. That presumption attaches to the essential requirements that land in December 2027. The duty arriving this month is the reporting one, and it carries no such offset. Nothing you have built for ISO 42001 or for AI Act readiness files a report for you on a Friday night.

What actually breaks in practice is not policy, it is the definition of awareness. In most companies under a few hundred people, a vulnerability report arrives somewhere unmanaged. A researcher emails an address nobody owns, a customer raises it in a shared Slack Connect channel, a maintainer opens a GitHub issue, a dependency scanner flags a transitive package at three in the morning, or someone spots exploitation in a log and mentions it in passing. There is no recorded instant at which the organisation became aware, which means there is no defensible start time for a 24 hour clock, which means you cannot show you met it and cannot show you missed it either. Fixing that is a week of work, not a project: one intake channel that is monitored, a named duty holder with a named backup, a written triage rule that separates a vulnerability that exists from a vulnerability that is being exploited, and a pre agreed authority to file without waiting for outside counsel.

The compliance platforms will help here but they will not do it by default. Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof already hold your incident response policy and your SOC 2 and ISO 27001 evidence, and the temptation is to point at that control and call the CRA covered. It is not the same control. SOC 2 incident response is about your service and your customers, the CRA duty is about your product and a national CSIRT, and the two use different triggers, different recipients and different clocks. Map it as its own control with its own evidence, because you may now be running three timers on one event: 24 hours to a CSIRT under the CRA, 72 hours to a supervisory authority under the GDPR if personal data is involved, and whatever your customer contracts promise, which is frequently shorter than either. Teams handling card data will recognise the shape of this from PCI DSS, where the obligation that bites is rarely the one in the framework document and usually the one in the acquirer agreement.

So here is the nine day version, and it is deliberately small. Answer one question in writing and get it signed off: are we a manufacturer of a product with digital elements placed on the EU market, and if we think the SaaS exclusion saves us, does the remote data processing definition pull our backend back in. If the answer is yes, or is honestly unclear, identify the CSIRT for your main establishment, find and bookmark the Single Reporting Platform when it goes live, name the duty holder and the backup, define in one paragraph what counts as becoming aware, and write the 24 hour early warning template now rather than at the moment you need it. Then run an inventory of everything you have shipped into the EU that is still out there, including the products nobody maintains, because those are the ones where an exploited vulnerability will be reported to you by a stranger rather than found by your own scanning.

None of this is an argument that the CRA is unreasonable. Requiring that a company which sells software tell someone when that software is being actively exploited is close to the minimum a functioning market should ask, and the staged timeline was generous. The failure mode is the familiar one. A regulation with a headline date in 2027 gets filed under future work, the one clause that starts early gets missed, and the first time anyone reads Article 14 carefully is during the incident it applies to. The teams that come out of the next twelve months well will not be the ones with the thickest CRA readiness deck. They will be the ones who can point to a named person, an intake channel with timestamps, and a draft they wrote in September while nothing was on fire.