Cyber Resilience Act reporting from 11 September 2026: who must report and within what deadlines?

When does the CRA reporting regime begin?

The Cyber Resilience Act entered into force on 10 December 2024. Most of its obligations, including the essential cybersecurity requirements, conformity assessment, technical documentation and CE marking, apply from 11 December 2027. Article 14 follows an earlier timetable and applies from 11 September 2026.

This distinction is operationally important. A business cannot assume that every product sold before December 2027 remains outside the CRA. The European Commission has clarified that the reporting obligations extend to products with digital elements already made available on the Union market.

The reporting process should therefore cover the current product portfolio, not only new products designed for full CRA compliance.

Which products may fall within the CRA?

The CRA covers hardware and software whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. A product with digital elements may be a final device, an application, a computer program or a component placed on the market separately. It may also include a remote data processing solution designed by the manufacturer, or under its responsibility, where that solution is necessary for a product function.

Not every digital service is automatically a CRA product. The assessment should examine what is supplied on the market, how it is delivered and whether the remote element forms an integral part of the product. Open-source models and products governed by certain sector-specific EU regimes require a separate analysis.

A sensible starting point is a product map covering versions, components, remote functionality and the relevant legal entities. An inventory of IT systems used internally does not answer the CRA scope question.

Who is the manufacturer responsible for reporting?

The manufacturer is not limited to the entity whose employees write the code or assemble the device. It also includes a business that has a product designed, developed or manufactured and markets it under its own name or trade mark. Branding and the way in which the product is placed on the market may therefore matter as much as the technical division of work.

The supply chain commonly includes:

The primary reporting duty falls on the manufacturer. Other participants should nevertheless be contractually required to pass relevant information to the entity responsible for classification and notification. Outsourcing product maintenance or security monitoring does not automatically transfer the statutory role.

• a manufacturer placing the product on the market under its own brand;
• a software house or contract manufacturer performing development or production work;
• an importer placing a third-country manufacturer’s product on the EU market; and
• a distributor making the product available without affecting its properties.

Which events are reportable?

The CRA does not require every defect or IT incident to be notified. Article 14 focuses on two categories.

The first is an actively exploited vulnerability in a product with digital elements. This requires reliable evidence that a malicious actor has exploited the vulnerability in a system without the system owner’s permission. A theoretical weakness or the mere possibility of developing an exploit will not necessarily meet this threshold. It may still require remediation even if the specific reporting route is not triggered.

The second category is a severe incident having an impact on the security of the product. The analysis considers the effect on the product’s ability to protect the availability, authenticity, integrity or confidentiality of data or functions. An operational incident affecting the manufacturer’s infrastructure will not always qualify, although it may separately fall within NIS2, GDPR or contractual reporting duties.

The business should use a concise classification matrix connecting technical findings to the CRA definitions. Without it, security may treat the rule as a requirement to notify every event, while legal may only learn of a critical incident after the 24-hour deadline.

How do the 24- and 72-hour deadlines work?

The deadlines run from the point at which the manufacturer becomes aware of the actively exploited vulnerability or severe incident. The first stage is an early warning within 24 hours. It is not intended to replace the full report and should contain the basic information available at that time.

Within 72 hours, the manufacturer provides a fuller notification containing the available information about the product, the nature and impact of the vulnerability or incident and the measures taken. The legal structure recognises that a technical investigation may still be ongoing. The absence of every final detail does not automatically justify delaying the initial filing.

For an actively exploited vulnerability, the final report is generally due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is generally due within one month after the fuller notification. Its content should reflect the type of event and the findings of the investigation.

Notifications will be submitted through the CRA Single Reporting Platform established by ENISA. The Commission states that the platform is to be operational when the reporting duties begin.

How does the CRA interact with NIS2 and GDPR?

One event can trigger several regimes. A software manufacturer may also be an essential or important entity under the Polish KSC Act implementing NIS2, while the incident may constitute a personal data breach. The legal tests are not identical.

The CRA focuses on the security of a product with digital elements and the manufacturer’s duties. NIS2/KSC addresses the security of network and information systems of specified entities and continuity of their services. GDPR protects personal data and requires the controller to assess risks to individuals’ rights and freedoms.

The incident procedure should therefore contain separate tests, a shared factual record and coordinated deadlines. The guide to NIS2 registration in Poland addresses organisational scope, while the article on the first 72 hours after a personal data breach describes the separate GDPR route.

What should change in supplier and customer contracts?

The manufacturer depends on information from parties that develop, host, monitor or maintain its product. Agreements with software houses, cloud providers and component suppliers should address:

A generic obligation to “comply with applicable law” is not enough. The process must work outside normal business hours. It should be aligned with the vulnerability and service mechanisms in a SaaS agreement.

• rapid escalation of suspected vulnerabilities and incidents, on a timetable shorter than the statutory 24 hours;
• access to logs, evidence, repositories and technical personnel;
• classification responsibilities and authority to decide on a notification;
• cooperation on reports, updates and user communications;
• control over subcontractors and third-party components;
• confidentiality rules that do not obstruct mandatory reporting; and
• allocation of remediation costs and liability.