From 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents under the EU Cyber Resilience Act. The first early warning is due within 24 hours of becoming aware of the issue, followed by a more detailed notification within 72 hours.

The wider CRA requirements will apply from 11 December 2027, but reporting starts fifteen months earlier. Companies that treated the regulation as a 2027 project therefore have a much closer operational deadline, as outlined in our overview of regulatory deadlines software teams should plan for in 2026 and 2027.

The immediate challenge is operational because a company must establish which product versions are affected, what evidence exists, which users may need to act, what mitigation is available and who can submit the report. If those answers must be assembled across several teams and suppliers after an incident begins, 24 hours is a short deadline.

Who is expected to report?

The CRA places the reporting obligation on the manufacturer of a product with digital elements. In this context, a manufacturer is the company that develops a product, has it developed and markets it under its own name or trademark. A software company can therefore hold that role even when an external partner wrote part or all of the code. The partner may be essential to the investigation, while the client remains responsible as the manufacturer.

The definition of a product with digital elements covers software and hardware products, separately marketed components and certain remote data processing services.

A remote API, database or cloud component may fall within the product boundary when the product cannot perform one of its functions without it. This does not place every website or cloud service inside the CRA automatically, so companies should document the product boundary and responsible entity in advance. The European Commission’s CRA summary explains the definitions, while its July 2026 guidance adds clarification on remote data processing, open-source software and reporting.

Companies with several products, white-label deployments or partner distribution need to know which entity places each product on the EU market, which services are necessary to its operation and which teams hold the evidence required for a report.

Which security events must be reported?

The mandatory reporting process covers two specific categories rather than every security defect discovered in a product.

An actively exploited vulnerability is a vulnerability for which there is reliable evidence that a malicious actor has exploited it without the system owner’s permission. Finding a vulnerability during a code review does not by itself establish active exploitation, although it can still require urgent remediation and may be reported voluntarily.

A severe incident affects, or is capable of affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of important data or functions, or leads or could lead to malicious code being introduced or executed in the product or a user’s systems.

The team therefore needs a documented route from a technical signal to a reporting decision. A support ticket, dependency advisory, monitoring alert or researcher report may be the first indication, but a named person must assess whether there is reliable evidence of exploitation or whether the incident meets the severity threshold. Leaving that judgement to whichever engineer receives the information creates delay and inconsistent decisions.

What the 24-hour and 72-hour deadlines require

The reporting clock begins when the manufacturer becomes aware of the actively exploited vulnerability or severe incident. It does not wait until the investigation is complete or a patch is ready.

Within 24 hours, the manufacturer must submit an early warning through the CRA Single Reporting Platform. It identifies the affected product and, where applicable, the EU countries in which it was made available. For a severe incident, it must also state whether unlawful or malicious activity is suspected.

Within 72 hours, the manufacturer must provide the fuller notification, including the general nature of the vulnerability, exploit or incident, an initial assessment, measures already taken, actions available to users and the sensitivity of the submitted information.

The final report follows later. For an actively exploited vulnerability, it is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, it is due within one month after the 72-hour incident notification. The final submission adds the detailed impact, likely threat or root cause, ongoing mitigation and information about the security update or other corrective measure.

These stages are defined in Article 14 of the Cyber Resilience Act. The Commission’s reporting overview confirms that reports will be submitted once through ENISA’s Single Reporting Platform and routed to the relevant national CSIRT and ENISA.

The 24-hour period is a reporting deadline, not a deadline for completing the technical investigation. The early warning can precede a confirmed root cause, but the manufacturer still needs enough reliable information to identify the event, the product and the known geographic reach without creating a misleading report.

What happens when product records are incomplete

Consider a B2B platform that learns on Monday morning that a vulnerability in an authentication component is being exploited.

The company needs to know which product versions contain it, whether the vulnerable configuration is enabled, which deployments are exposed, what the logs show and what users can do while a permanent fix is prepared.

When releases are traceable to their dependencies and deployments, the investigation starts with a defined affected set. With incomplete records, senior developers may spend the first hours comparing repositories, manifests, container images, release notes and customer branches while also containing the incident and preparing a fix.

The reporting requirement exposes delivery weaknesses that may have persisted for years, including unclear version ownership, inconsistent dependency records, limited production logging and patch processes that depend on one person.

Five checks to complete before 11 September

1. Define the product boundary and responsible company. Record which products, separately supplied components and necessary remote services fall within the CRA assessment, together with the entity that places each product on the market and the people responsible for its operation.
   
2. Define how evidence reaches the decision-makers. Researchers, customers, developers, support staff and monitoring systems may identify the first signal. Each route needs a clear escalation path, an out-of-hours contact and a recorded point at which the manufacturer considers itself aware of a potentially reportable event.
   
3. Connect versions, dependencies and deployments. The incident team should be able to move from a vulnerable package, service or code change to affected releases and deployments without reconstructing the product history. A software bill of materials helps when it remains connected to actual builds and releases.
   
4. Prepare the information required at each stage. A structured internal record should capture the product, affected versions, discovery and awareness times, known exploitation, geographic availability, evidence, mitigation, user actions, owners and approval history.
   
5. Run a timed incident exercise. Use a plausible third-party vulnerability and measure how long it takes to identify affected releases, reach the responsible people, assess the reporting threshold, prepare the warning and define user mitigation. Continue through patch development, testing, release and customer communication.

ENISA has published Single Reporting Platform information and user guidance. Assigned representatives will use EU Login, and no reporting API will be provided at the initial stage, although companies may automate their internal evidence flows. A manufacturer should therefore know who can submit a report and how the required information reaches that person outside normal working hours.

What belongs in the technical backlog now

The size of the required work depends on the product and its current delivery process.

A company with reliable build provenance, current dependency data, centralised logging, established security ownership and a tested patch route may need only a focused reporting procedure and rehearsal.

A company with several inherited applications or customer-specific deployments may first need to repair the technical records on which the process depends.

The useful backlog items are concrete - builds should be traceable to source revisions and dependency versions, supported releases should be identifiable, security logs should contain reliable timestamps, and the team should know how to disable a vulnerable function or issue a corrective release without waiting for the next deployment window. Customer and deployment records must also show who may be affected and which mitigation applies.

These controls already matter beyond CRA reporting. As discussed in our article on custom software development trends in 2026, software supply-chain traceability is increasingly part of customer procurement and production assurance. The September deadline gives companies a reason to test whether those records work during an investigation rather than merely appearing in a questionnaire.

Reporting and customer communication use the same evidence

Manufacturers must also inform impacted users and, where appropriate, other users about the event and the corrective or mitigating measures they can take. This creates a second demand on the same product information.

A general security notice is of limited use when customers need to know whether their version is affected, which configuration changes reduce exposure, whether a patch fits their deployment and what evidence indicates compromise. Accurate communication depends on the same version mapping, deployment knowledge and technical ownership needed for the report.

For B2B software companies, the response also affects renewal and procurement discussions. Customers can distinguish between a supplier still locating the relevant systems and one that can state which versions are affected, what has been observed and what happens next.

How Blocshop can support the underlying engineering work

CRA reporting duties may expose engineering problems that extend beyond the reporting process, like inherited components, unclear dependencies, limited production visibility, customer-specific versions or release processes that make urgent fixes difficult.

Blocshop provides senior development capacity to software companies that need additional ownership within an existing product team.

This can include improving application architecture and observability, reducing technical debt, clarifying version and dependency relationships, modernising legacy components, or strengthening deployment and release processes.

If regulatory obligations or an actual product incident have revealed technical work your team lacks the capacity to address, book a consultation with Blocshop to discuss a defined development workstream and the senior expertise required to deliver it.