CRA Reporting Starts 11 September 2026

The Cyber Resilience Act (Regulation (EU) 2023/2847) is often filed away as a 2027 problem. That is a mistake. Its reporting obligations apply from 11 September 2026, more than a year before the main obligations land on 11 December 2027.

If you manufacture anything that qualifies as a "product with digital elements", the clock on your notification process has already run down.

Who Is Bound

The obligation falls on manufacturers of products with digital elements. That category is broader than most organisations assume:

• Software, whether sold, licensed, or embedded
• Hardware with any connected or programmable component
• Remote data processing solutions integral to the product
• Software or hardware components placed separately on the market

That last point catches a lot of companies by surprise. If you ship a library, a module, or a firmware component that others integrate, you are a manufacturer for CRA purposes.

What Must Be Reported

Two distinct categories trigger notification:

1. Actively exploited vulnerabilities in your product
2. Severe incidents affecting the security of your product

Note the word actively. A vulnerability that is merely disclosed or theoretically exploitable does not trigger the reporting clock. Evidence of exploitation in the wild does.

The Three-Stage Clock

The CRA imposes a staged notification process, and each stage has its own deadline:

| Stage | Deadline | Trigger | |---|---|---| | Early warning | 24 hours | From becoming aware | | Full notification | 72 hours | From becoming aware | | Final report | 14 days | After a corrective measure is available (vulnerabilities) | | Final report | 1 month | For severe incidents |

The 24-hour and 72-hour clocks both run from awareness, not from each other. A team that spends two days investigating before deciding whether something counts has already missed the early warning.

Where Reports Go

Notifications are submitted through the CRA Single Reporting Platform (SRP), established under Article 16 of the Regulation and built by ENISA. Manufacturers report once: the notification is addressed to the CSIRT of the member state of their main establishment, and the information is made available to ENISA simultaneously.

The platform is due to be operational by the 11 September 2026 date.

What "Aware" Means in Practice

The hardest part of this obligation is not the reporting form. It is the internal machinery that turns a scattered signal into a timed, documented decision. Most manufacturers do not currently have:

• A single intake point for vulnerability reports covering support, sales, security researchers and automated scanners
• A documented triage step that records when awareness began
• A named individual with authority to declare a reportable event outside business hours
• A pre-drafted early-warning template that can be filed on incomplete information

Twenty-four hours is not long enough to invent any of this under pressure.

A Six-Week Readiness Plan

Weeks 1-2: Scope and Ownership

1. Determine whether each of your products falls in scope, including components shipped separately
2. Identify your member state of main establishment and its CSIRT
3. Name an accountable owner and a deputy, with out-of-hours contact paths
4. Register interest in the Single Reporting Platform

Weeks 3-4: Detection and Triage

1. Consolidate vulnerability intake into one monitored channel
2. Define what evidence constitutes "actively exploited" for your products
3. Write the triage decision tree, including the awareness timestamp rule
4. Set an internal escalation SLA well inside 24 hours — aim for 4

Weeks 5-6: Rehearse

1. Draft the early warning, full notification and final report templates
2. Run a tabletop against a realistic exploited-vulnerability scenario
3. Measure your actual time from signal to draft notification
4. Fix whatever the exercise breaks, and record the evidence

The Overlap You Can Exploit

If you already run NIS2 incident reporting, you have most of the machinery. The 24/72-hour rhythm is deliberately aligned. What differs is the subject: NIS2 reports incidents affecting your services, the CRA reports vulnerabilities and incidents affecting your products in your customers' hands.

Organisations subject to both should not build two processes. They should build one intake and triage capability with two output paths.

Common Misreadings

• "We are not a software company." If your product has firmware, you are in scope.
• "Our vulnerability disclosure policy covers this." A VDP governs how researchers reach you. It does not create a 24-hour regulatory notification duty.
• "We will handle it when the main obligations start in December 2027." Reporting starts fifteen months earlier.
• "Open source is exempt." The exemption is narrow and turns on commercial activity, not licence type.

Sources

• Cyber Resilience Act — Reporting obligations, European Commission
• Cyber Resilience Act, European Commission