Cyber Resilience Act: obligations and deadlines companies should check

The EU Cyber Resilience Act—known as the CRA—sets mandatory cybersecurity requirements for products with digital elements. Its scope covers hardware and software: the European Commission cites everyday examples such as smart watches, baby monitors, applications and computer programs. The aim is to ensure that security is taken into account during product design, development and maintenance, rather than only after a product reaches the market. [1]

For a company, the initial question is not simply whether it sells technology, but which product it makes available on the European market and what role it plays in the supply chain. Manufacturers, importers and distributors may have different responsibilities. The Commission also identifies application developers as manufacturers when they market those applications in the EU. A commercial label alone does not settle the classification: it is worth reviewing each entity’s actual role and the product’s characteristics. [2]

A useful review begins with an inventory of products and digital components, followed by an assessment of their relationship with connected services. Guidance published by the Commission in July 2026 addresses, among other matters, scope, substantial modifications, support periods, risk assessment and vulnerability reporting. It helps explain practical implementation, but it does not replace the regulation or automatically determine the status of every product. [3]

Companies should not assume that an entire category is included or excluded without examining the specific case. For example, a cloud service may have a technical relationship with a covered product; a secondary source describes possible cases involving remote processing connected to a product. That explanation may help frame questions, but it is not a sufficient basis for settling a legal interpretation. Where material uncertainties arise, the company should compare its architecture and role with the legal text and seek specialist advice. [4]

The Commission describes the CRA as a framework of cybersecurity requirements for manufacturers that affects the planning, design, development and maintenance of products with digital elements. It also says that manufacturers must manage vulnerabilities throughout the lifecycle. In operational terms, this means connecting security work with engineering, maintenance and support processes, rather than treating it as a standalone check before launch. [1]

The specific application depends on the product and the obligations that apply to it. The Commission’s 2026 guidance addresses matters such as risk analysis and how to understand support periods. Companies should therefore be able to explain which product they assessed, which risks they considered, and how they organise vulnerability handling and updates. Documentation should reflect actual practices, not be limited to a generic statement that a product is secure. The information available here does not establish one universal support period for all products. [3]

According to the Commission page on reporting obligations, from 11 September 2026 manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of their products with digital elements. The Commission describes an initial alert within 24 hours of becoming aware, a full notification within 72 hours, and a final report subject to deadlines that depend on the type of event. [5]

The official page says that the final report on an actively exploited vulnerability must be submitted no later than 14 days after a corrective measure becomes available. For severe incidents, it specifies a deadline of one month from the 72-hour notification. It also explains that manufacturers report through a single platform, with the notification going to the computer security incident response team (CSIRT) responsible for their main establishment. The short deadlines make it necessary to prepare responsible persons, escalation channels and activation criteria in advance, rather than improvising them during an incident. [5]

The same official timetable distinguishes open-source software stewards: according to the provision cited by the Commission, their reporting obligations begin on 11 December 2027. This distinction matters to organisations that maintain open-source software and to companies that depend on it; it should not be confused with the date applicable to product manufacturers. [5]

According to the Commission, the CRA has been in force since December 2024, but that does not mean all its obligations began at the same time. The September 2026 milestone activates the reporting obligations described above. The Commission states that the regulation will be fully applicable from 11 December 2027. For planning purposes, companies should distinguish between entry into force, milestones for specific obligations and the date of general application. [1][5]

An internal tracking table can help prevent a simplified timetable or a third-party publication from becoming the sole reference:

The table summarises dates and groups as presented in the official information consulted; it does not replace checking the article that applies to each organisation. [1][5]

A practical plan can start with five checks: identify products and markets; assign each entity’s role; document components and dependencies; establish a process to detect, assess and escalate vulnerabilities; and confirm who submits notifications and through which channel. These measures can then be compared with the regulation and official guidance, paying particular attention to product classification, modifications, support and risk assessment. [2][3][5]

The available research contains no direct statements from affected manufacturers, and it does not support attributing a position, level of preparedness or interpretation to any particular company. Nor does it provide enough information to resolve every borderline scope case. Therefore, there is no basis here to claim that a specific company is compliant or non-compliant, or to present a regulatory development beyond the documented milestones. The verifiable conclusion is narrower: reporting obligations have a confirmed start date, and organisations should incorporate the general application date into their analysis. [1][5]