The Cyber Resilience Act Is Filed Under 2027. Its 24 Hour Clock Starts on 11 September.

Most compliance calendars have the Cyber Resilience Act filed under December 2027. That is the date CE marking bites, the date the harmonised standards work is aimed at, and the date every vendor roadmap points to. It is also the wrong date to be working from, by fifteen months. The CRA has four application dates rather than one, and the third of them lands on 11 September 2026 with a 24 hour clock attached.

Four dates, not one

Regulation (EU) 2024/2847 applies in stages, and the stages do not escalate in the order most teams assume. The heaviest engineering obligation comes last. The fastest operational obligation comes next week.

• 10 December 2024. Entry into force. Nothing was owed yet and the transition period started running, which is precisely why the CRA slid down most 2025 roadmaps.
• 11 June 2026. The framework for notifying conformity assessment bodies became applicable, so Member States could begin designating the notified bodies that will later certify important and critical product classes. This one mattered to the certification market more than to manufacturers, which is part of why it passed without much noise.
• 11 September 2026. Reporting obligations apply. Manufacturers must notify actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform, on a clock measured in hours.
• 11 December 2027. Full application. Products with digital elements placed on the EU market from that date must meet the essential cybersecurity requirements and carry CE marking on that basis.

There was a fifth, quieter step. On 11 December 2025 the Commission adopted a delegated act, Regulation (EU) 2026/881, specifying the grounds on which a national CSIRT may delay passing a notification on to other CSIRTs. That the Commission spent a delegated act on the onward circulation of these reports is a reasonable signal of how much traffic it expects the platform to carry.

What is actually owed from 11 September

The obligation covers two triggers: a vulnerability in a product with digital elements that a malicious actor is actively exploiting, and a severe incident affecting the security of that product. Both run on the same staged clock. An early warning goes in within 24 hours of the manufacturer becoming aware. A full notification follows within 72 hours. A final report is due no later than 14 days after a corrective measure becomes available for an actively exploited vulnerability, or within one month for a severe incident.

Mechanically, the process is better designed than the NIS2 experience would lead you to expect. A manufacturer submits once, through the CRA Single Reporting Platform. The notification is addressed to the CSIRT of the Member State where the manufacturer has its main establishment, and unless exceptional circumstances apply the same information reaches ENISA simultaneously. That receiving CSIRT then shares the notification without delay with the CSIRTs of every other Member State where the product has been made available. One submission, not twenty seven. The Commission confirmed in its 31 July update that the platform will be operational by 11 September and that functional and security testing was under way.

The scope clause that catches people out

Reporting applies to products with digital elements already placed on the EU market, not only to products placed on it after full application in December 2027. Read that alongside the timeline and the consequence is uncomfortable: a manufacturer with a decade of shipped product carries reporting duties for that entire installed base fifteen months before it has to CE mark a single new product against the CRA.

This is the right way round from a security standpoint, since the installed base is where exploited vulnerabilities actually live, and it is the wrong way round from a programme planning standpoint. Teams that scoped their CRA work around what they will ship in 2028 have scoped the wrong estate. The relevant question on 11 September is not what your next release contains. It is what is running in customer environments right now, and whether you could name its components inside a working day.

Two definitions carry all of the judgement

"Actively exploited" and "severe incident" are where this obligation is won or lost. The 24 hour clock starts on awareness, not on confirmation, not on triage completion, and not on the point at which legal has formed a view. So the expensive question is procedural rather than legal: when a report lands in a product security queue at 23:00 on a Sunday suggesting a malicious actor is using a flaw in your firmware against real customers, who has the authority to file an early warning, and against what pre-agreed threshold?

My read is that this is the single control most manufacturers are missing, and it is not a control that a policy document creates. If the answer to that question is "we would convene a call", the deadline is already gone. If the answer is a named role with delegated authority and a written threshold they apply without escalation, the deadline is survivable. There is no third option that works at 23:00.

September is a harder date than December 2027, for a reason nobody planned for

Full application is a design and documentation deadline. It asks for secure development practices, a software bill of materials, vulnerability handling processes, technical documentation and conformity assessment. All of that is plannable, resourceable and, if it slips, it slips quietly inside an engineering roadmap.

The reporting obligation is an operations deadline. It asks for an awareness to notification path that functions on a weekend, at speed, under incomplete information, with a regulator at the other end. Design deadlines fail privately. Operational deadlines fail publicly, in front of a CSIRT, with a timestamp on the record.

August supplied a preview of what that failure would look like. The Shai-Hulud campaign compromised more than 1,300 package versions on npm, reaching packages with roughly two billion monthly downloads, after a single maintainer account was taken over. The malicious releases ran an obfuscated preinstall hook that harvested developer credentials and used them to compromise further packages. Any manufacturer whose product shipped one of those dependency versions was, on that day, distributing a product with an actively exploited vulnerability it did not write and had not been told about. Under the September regime, awareness starts when your team learns of it, however they learn of it, and the 24 hour clock does not pause while you work out whether the affected package is in your build.

Which means a software bill of materials stops being a compliance artefact for December 2027 and becomes the input to a reporting decision in September 2026. Dependency inventory, provenance and end of life status are now the difference between a lookup and an investigation, and the CRA has priced that difference in hours.

Where AI features make the awareness problem worse

A growing share of products with digital elements now call a third party model endpoint, embed an agent framework, or route a feature through an inference API. Two things follow. First, the manufacturer often cannot say with confidence which of its shipped products depend on which external AI service, because those integrations were added by feature teams rather than by procurement. Second, when the incident originates upstream at the model provider, the manufacturer learns about it the same way everyone else does, from a public post, and the awareness clock starts from that moment regardless.

Financial services has already been shown the same mechanism from the other side. When the European Supervisory Authorities issued their statement on frontier AI under DORA, they wrote no rule binding AI vendors directly and instead pushed the obligation through their supervised firms' contracts, as we set out in Brussels Did Not Write a Rule for AI Vendors. It Wrote Their Next Questionnaire. The CRA does the reverse for products: it puts the duty on the manufacturer and leaves the manufacturer to work out what its own suppliers owe it, and how quickly. Both routes end at the same requirement, which is a current and queryable picture of what you depend on.

That picture is what insAIght is for in this context. Not a policy library and not an annual attestation, but a maintained map of the AI components and services embedded in what an organisation builds and runs, with the ownership and evidence attached to each one, so that a 24 hour notification decision resolves into a query against something that already exists rather than a scramble across three teams and a procurement inbox.

Nine days is enough time to name one person

There is no realistic version of the next nine days in which a manufacturer rebuilds its vulnerability handling programme, completes a dependency inventory across a legacy portfolio, or negotiates faster disclosure terms into supplier contracts. Those are quarters of work and they should start, but they will not be finished by 11 September.

What can be finished is smaller and more useful. One named role with standing authority to file an early warning without convening anyone. A written threshold that role applies, agreed in advance by legal and product security so it is not being negotiated at midnight. A tested route into the Single Reporting Platform, used once before it is needed in anger. Manufacturers who get that far by 11 September will file late reports occasionally and defensible ones always. Manufacturers who arrive with a policy and no named person will discover the difference between the two on their first bad Sunday, and the timestamp of that discovery will be part of the record.

Learn more

• insAIght: a maintained map of the AI systems and services an organisation depends on, with owners and evidence attached, so a notification decision is a query rather than an investigation.
• ExplAIn: a quick first read on how an AI system you already rely on would be classified and what it would owe.
• Brussels Did Not Write a Rule for AI Vendors. It Wrote Their Next Questionnaire.: how the same dependency problem is being pushed through financial services contracts under DORA.
• European Commission: CRA reporting obligations and ENISA's FAQ on the Single Reporting Platform: the primary sources for the 11 September regime.

If you could not currently answer, within a working day, which of your shipped products contain which third party components and AI services, that is the gap the 24 hour clock will find first. Book a demo to see how insAIght keeps that answer available before you need it.