The EU Cyber Resilience Act's Reporting Clock Has Started, and It Reaches Well Beyond Europe

A regulatory deadline that has been on compliance calendars for two years has now arrived. From 11 September 2026, manufacturers of products with digital elements sold into the EU must report actively exploited vulnerabilities and severe security incidents under the Cyber Resilience Act, with the first notification due within 24 hours of becoming aware (European Commission, Shaping Europe’s Digital Future). For any large organisation that builds, embeds or resells software, firmware or connected devices, and sells into the EU market in any capacity, this is not a European problem to watch from a distance. It is a live obligation.

What actually changed today

The Cyber Resilience Act itself has been in force since December 2024, but its reporting duties are what took effect this week. The requirement is specific and tightly timed. A manufacturer that becomes aware of an actively exploited vulnerability, or a severe incident affecting a product with digital elements, must submit an early warning within 24 hours, a fuller notification within 72 hours, and a final report once a fix is available, generally within 14 days (Hogan Lovells). These reports go through ENISA’s new Single Reporting Platform, which launched the same day the obligation became mandatory (Tech Times).

The scope is broader than the name suggests. This is not a rule aimed narrowly at critical infrastructure or defence contractors. It covers essentially any product with digital elements placed on the EU market, from enterprise software and industrial control systems through to connected consumer devices. Non-EU companies are squarely in scope if their products reach EU customers, and the obligation applies regardless of where the manufacturer is headquartered (Crowell & Moring).

Why a 24 hour clock changes the calculus

Most large organisations already have vulnerability disclosure and incident response processes. What the CRA changes is the tolerance for delay. A 24 hour early warning window assumes an organisation already knows, at all times, which of its products contain which components, and has a clear internal path from detection to a regulatory filing.

That assumption breaks down quickly in practice for two reasons:

• Component visibility is often incomplete. Many enterprises cannot say with confidence which third party and open source components sit inside a given product without a proper software bill of materials, which is exactly why the regulation leans so heavily on SBOMs as a foundational control.
• Detection and legal or regulatory reporting still sit in different parts of the organisation. A security team spotting active exploitation and a compliance function filing a regulatory notice are frequently not connected by a process that can move in hours rather than days.

A 24 hour reporting obligation is really a test of how fast information moves inside your organisation, not how fast you can write a report once you have the facts.

The cost of getting this wrong is not trivial

Regulators have given this obligation real weight. Breaches of the CRA’s reporting duties can attract administrative fines of up to €15 million or 2.5 percent of an undertaking’s total worldwide annual turnover for the preceding financial year, whichever is higher (Venvera). That figure puts CRA non-compliance in the same bracket as the penalties enterprises have grown used to under GDPR, and boards should treat it with the same seriousness. Microenterprises and small enterprises are shielded from fines specifically for missing the 24 hour window, but that carve out does not extend to the large organisations and government suppliers this obligation is really aimed at.

What large organisations should do now

For technology and risk leaders, the practical work falls into a small number of concrete actions rather than a sweeping compliance programme.

Start with an honest inventory. Identify every product with digital elements your organisation places on the EU market, directly or through a subsidiary, reseller or integrator, and confirm who inside the business owns CRA compliance for each one. Ambiguity about ownership is the most common reason reporting deadlines are missed.

Build or mature your SBOM discipline. You cannot report a vulnerability in a component you did not know you were using. A current, accurate software bill of materials for each in scope product is the single most useful control an organisation can have in place before, not after, an incident.

Wire detection directly to the reporting decision. The gap between a security operations team confirming active exploitation and a compliance or legal function deciding to file should be measured in hours. If it currently is not, that gap is the highest priority fix.

Rehearse the 24 hour path, not just the policy. A tabletop exercise that walks a real component through detection, internal escalation, and a mock submission to the reporting platform will expose gaps no document review will find.

Where Jaykan fits

Jaykan works with enterprises, corporations and government suppliers to build the practical mechanics behind regulatory obligations like this one, from software bill of materials programmes and vulnerability management through to the incident response pathways that turn a security finding into a compliant, timely disclosure. We help organisations get this right before a real incident forces the question under pressure.

If you are not confident your organisation could meet a 24 hour reporting obligation today, a complimentary, senior led assessment is the fastest way to find out where the gaps sit and what to fix first.