The Cyber Resilience Act: 11 September 2026 Is a Real Deadline

Most EU regulations give you a compliance date and a grace period during which everyone quietly gets organised. The Cyber Resilience Act does something different. Its first hard obligation is a 24 hour reporting clock, and it starts on 11 September 2026.

You cannot phase in a 24 hour clock. Either the process exists on the day, or you miss it.

What the CRA Is

Regulation (EU) 2024/2847 sets cybersecurity requirements for products with digital elements placed on the EU market. That phrase covers far more than people initially assume: any software or hardware product, and its remote data processing solutions, whose intended or reasonably foreseeable use includes a direct or indirect data connection.

Connected devices are in scope. So is most commercial software, operating systems, browsers, mobile apps, firmware, and the components inside other products.

The Act was published in November 2024 and applies in stages:

11 June 2026: obligations for conformity assessment bodies.
11 September 2026: reporting obligations for actively exploited vulnerabilities and severe incidents.
11 December 2027: full application, including essential cybersecurity requirements, CE marking, technical documentation and the software bill of materials.

The middle date is the one to plan around, because it arrives first and because it depends on capability you may not have.

What Happens on 11 September 2026

From that date, manufacturers must report:

Actively exploited vulnerabilities in their products with digital elements, and

Severe incidents affecting the security of those products.

Reporting goes through the CRA Single Reporting Platform, operated by ENISA, to the CSIRT designated in the Member State of the manufacturer's main establishment, which then shares onwards to other affected CSIRTs and ENISA.

The timeline:

Within 24 hours of becoming aware: an early warning.
Within 72 hours: a full notification, including corrective or mitigating measures taken.
Within 14 days of a corrective measure becoming available: a final report for an actively exploited vulnerability.
Within one month: a final report for a severe incident.

Twenty-four hours from awareness, not from confirmation, not from remediation. If a vulnerability in a component of your product is being exploited in the wild on a Saturday, the clock is running on Saturday.

Why This Is Harder Than It Looks

The reporting obligation itself is a form submission. The difficulty is in everything you need in place before you can fill it in.

You have to know what is in your product

To report that a vulnerability in your product is being actively exploited, you have to know that the vulnerable component is in your product. For a modern application with hundreds of transitive dependencies, that is not something a human can answer from memory.

This is why teams are building software bill of materials pipelines now, more than a year ahead of the formal SBOM requirement in December 2027. The SBOM is not the goal. Being able to answer "are we affected?" within hours is the goal, and the SBOM is what makes that answerable.

The awkward part is that this applies to products you shipped years ago. If you have supported devices in the field running firmware built in 2022 from a dependency tree nobody recorded, reconstructing that is real work.

You have to be watching

Awareness starts the clock, and awareness is expected to be active rather than accidental. That means monitoring vulnerability feeds, subscribing to advisories for your components, tracking known exploited vulnerability catalogues, and having a channel where security researchers can reach you and get a response.

You have to have a decision path

Somebody has to be able to decide, at any hour, whether an incident meets the threshold and whether the clock has started. Without a named role and an escalation path, the first hours go into working out who is allowed to make the call.

End-of-life dependencies become a liability

If a component in your product no longer receives security updates, you still carry the reporting obligation when it is exploited, and you have no upstream fix to point at. Auditing for end-of-life dependencies is one of the more useful things to do in the run-up, because the answer sometimes forces a migration with its own lead time.

What Full Application Brings in December 2027

The December 2027 obligations are the larger programme, and they need to be started long before then.

Secure by design and by default. Products must be designed, developed and produced to ensure an appropriate level of cybersecurity based on risk. No default passwords. Secure configuration out of the box. Attack surface minimisation. Protection of data in transit and at rest.

Vulnerability handling. A documented process covering identification, remediation, testing, distribution and disclosure. Security updates must be provided without delay and free of charge, for a support period reflecting the expected product lifetime, with five years as a common reference point.

Software bill of materials. In a machine-readable format, covering at minimum the top-level dependencies, and kept current.

Technical documentation and conformity assessment. Most products self-assess. Important and critical categories, which include things like password managers, VPNs, operating systems and industrial control systems, require third-party involvement.

CE marking. The digital equivalent of the physical mark, declaring conformity.

Coordinated vulnerability disclosure policy. Published, with a contact point that works.

Who Is Actually in Scope

A few boundary cases come up constantly.

Free and open source software developed outside a commercial activity is largely out of scope. The Act introduces the notion of an open source software steward with lighter obligations. But if you commercialise open source, or ship it inside a product you sell, the product obligations are yours.

Software as a service is generally outside the CRA, sitting instead under NIS2, though remote data processing solutions that are integral to a product with digital elements are pulled in. If your device depends on your cloud backend to function, that backend travels with the product.

Importers and distributors carry obligations too. If you put a third-party product on the EU market under your own name or trademark, you are treated as a manufacturer.

Products already regulated elsewhere, such as medical devices, cars and aviation equipment, are handled under their own frameworks.

The scoping questions are genuinely non-trivial and this is a place where an hour with counsel saves months of misdirected engineering.

What We Would Do in the Time Remaining

If you are in scope and starting now, the order that works:

First, establish product inventory. What do you actually have on the EU market? Including old versions still in the field, white-labelled variants and products you distribute for someone else. This list is usually longer than anyone expects.

Second, build SBOM generation into CI. Generate an SBOM on every build, in CycloneDX or SPDX, store it against the release artefact, and keep it queryable. The point is being able to ask "which of our shipped releases contain this library?" and get an answer in minutes.

Third, wire up vulnerability monitoring. Feed your SBOM data into a scanner that watches advisories and known exploited vulnerability catalogues, and route alerts to a channel someone reads.

Fourth, write the incident runbook. Who declares, who assesses, who reports, who communicates. Named people, deputies, and out-of-hours contacts. Then rehearse it once with a fake advisory. The rehearsal is where you find that the person who has the reporting platform credentials is on holiday.

Fifth, publish a vulnerability disclosure policy. A security.txt file, a monitored address, and a stated response time. This is an afternoon of work and it is the difference between hearing about a problem from a researcher and hearing about it from a journalist.

Sixth, start the December 2027 work. Secure defaults, update mechanisms, support period decisions and documentation are architecture questions, not paperwork. Products you design in 2026 will still be on the market in 2028.

The Overlap Nobody Uses

There is significant duplication between the CRA and other regimes, and most companies handle each separately, which is wasteful.

An SBOM built for the CRA answers most of the supply chain questions in NIS2. The incident runbook overlaps with the NIS2 24 hour early warning and with the GDPR 72 hour breach notification. Vulnerability handling processes feed directly into customer security questionnaires and enterprise procurement.

Build these once as platform capability. The alternative is three teams building three versions of the same asset inventory.

Where to Get Help

We build and maintain software for companies selling into the EU, which increasingly means building the supply chain visibility and update infrastructure that the CRA assumes. If you are working out whether you are in scope, or you have the September date on the calendar and no monitoring in place, get in touch at office@c9group.dev.

Our legacy system maintenance service is often where this starts, because the products with the worst dependency visibility are usually the oldest ones. The wider regulatory picture is in our 2026 EU digital compliance guide.

We are engineers rather than lawyers. Scoping and classification decisions belong with your counsel, and we build to whatever answer they give.