The Cyber Resilience Act (CRA) introduces extensive new cybersecurity requirements for manufacturers of software, connected devices, and other products with digital elements. While most obligations will apply from 11 December 2027, manufacturers will already be required, from 11 September 2026, to report actively exploited vulnerabilities and severe security incidents.
As companies prepare for the CRA, numerous practical questions arise: When is a new software version considered a new product? What are the consequences of a substantial update? How long must security updates be provided? And do products that have already been developed need to be redesigned to comply with the CRA?
The European Commission has now published guidelines on the application of the CRA. Using practical examples, the Commission explains how it interprets key concepts and obligations under the Regulation. Although the guidelines are not legally binding, they provide important guidance for companies and, likely, for the competent authorities responsible for enforcing the CRA.
Below, we summarize the aspects of the guidelines that are particularly relevant in practice.
1. The 24-hour reporting deadline does not start with the first suspicion
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents. The guidelines explain when these short reporting deadlines begin to run.
An unconfirmed indication alone does not trigger the reporting deadline. However, the manufacturer must assess it without undue delay. The reporting period begins once this initial assessment establishes with sufficient certainty that:
- a vulnerability contained in the product is being actively exploited; or
- a severe security incident has occurred and has affected the security of the product.
From that point onward, an initial early warning report must generally be submitted within 24 hours. A follow-up notification must be submitted within 72 hours.
For an actively exploited vulnerability, the complete report must generally be submitted within 14 days after a corrective or mitigating measure becomes available. For a severe security incident, the deadline is one month after the 72-hour notification.
Companies therefore need not only a technical reporting mechanism but also clear responsibilities for the initial assessment and escalation of potential incidents. The process should cover both external reports and findings from internal security testing. The guidelines emphasize that the initial assessment must be carried out without undue delay, particularly where the potential vulnerability poses a significant risk. These procedures should be tested in practice before 11 September 2026.
2. A software version is generally placed on the market only once
According to the European Commission, software that is offered as a standalone product is placed on the market when the completed version is first made available on the EU market. This applies regardless of when individual customers purchase or download the software.
The guidelines illustrate this with an example: If software version 1.0.0 is first made available for download on 1 January 2028, it is considered to have been placed on the market on that date-even if some customers download it only at a later stage. A later version, such as 1.0.1, is not considered to have been newly placed on the market unless the changes are substantial. Consequently, the original placement-on-the-market date remains decisive.
The situation may differ for different variants of the same software, for example, builds for different operating systems or packages with different functionalities. Such variants may qualify as separate products. A new software version is also considered to be placed on the market again if it has undergone a substantial modification.
This distinction is particularly important for the CRA's transitional provisions. Manufacturers should document when individual versions were first made available, which variants they treat as separate products, and what changes were introduced subsequently.
3. Products that have already been developed do not automatically need to be redesigned
Many products that will only be placed on the market after 11 December 2027 are already under development today or have even been fully developed. According to the guidelines, the CRA does not automatically require these products to be redesigned.
However, manufacturers must assess the cybersecurity risks of the product. Based on the technical documentation, they must be able to demonstrate that the product achieves an appropriate level of cybersecurity and complies with the CRA requirements. The required conformity assessment, the EU Declaration of Conformity, and CE marking also remain mandatory.
However, the Commission does not require manufacturers to retrospectively recreate all evidence and testing from earlier development phases. If it is no longer possible to demonstrate how cybersecurity risks were addressed during the original development process, the manufacturer may instead carry out a current risk assessment and explain how the existing product design and security measures mitigate the identified risks.
This clarification is particularly relevant for industrial products with long development cycles. Companies should review which evidence is already available for ongoing product developments and identify any documentation gaps that still need to be closed.
4. For software updates, the decisive factor is the cybersecurity risk-not the scope of the update
Not every major update constitutes a "substantial modification" within the meaning of the CRA. Conversely, even a small change may qualify as substantial. The decisive factor is whether the intended use of the product changes or whether new or increased cybersecurity risks arise that were not previously considered.
The Commission provides the example of a system that initially only displays operational data from machines. If the system is later updated to allow it to control those machines, its intended use changes. The update must therefore be regarded as a substantial modification.
The guidelines also set out a non-exhaustive list of assessment criteria. In particular, it should be examined whether the update:
- introduces additional interfaces, communication channels, execution environments, or external dependencies;
- enables new attack scenarios; or
- significantly changes the likelihood or potential impact of attack scenarios that have already been considered.
By contrast, a significant functional enhancement does not necessarily constitute a substantial modification if it was already planned during the original development and taken into account in the risk assessment. Updates that merely remediate vulnerabilities or strengthen existing security measures generally do not constitute a substantial modification, provided that they neither change the intended purpose of the product nor introduce new or increased cybersecurity risks.
Companies should therefore align their product roadmaps with their cybersecurity risk assessments at an early stage. A technical classification as a major or minor release is not sufficient for the legal assessment. It is advisable to establish a documented process for evaluating security-relevant updates against the CRA criteria.
5. Five years is not a standard support period
As a general rule, the CRA requires a support period of at least five years. If a product is expected to be used for a shorter period, the support period may also be shorter. Conversely, where a product has a longer expected service life, five years will not automatically be sufficient.
This is particularly relevant for industrial installations, control systems, and other long-life products. For such products, the support period must reflect the realistically expected service life. The guidelines expressly clarify that five years should not be regarded as a universal standard for all products.
A substantial modification also does not automatically trigger a new five-year support period. The decisive question is whether the modification also affects the product's expected service life. For example, if a software update merely introduces new functionalities without extending the lifetime of the hardware or changing users' expectations, the remaining original support period generally continues to apply.
For continuously evolving software, manufacturers may, under certain conditions, limit vulnerability remediation to the most recently placed-on-the-market version. Users must be able to upgrade to that version free of charge and without additional costs. Normal efforts such as testing or configuration changes are generally not regarded as additional costs. However, if users are required to purchase new hardware or fundamentally rebuild their system environment, the manufacturer cannot rely on this simplification.
Practical Tip
The guidelines do not create any additional legal obligations. However, they provide important clarification on key issues that companies must address when implementing the CRA.
Manufacturers should, in particular, review whether software versions and updates are documented in a traceable manner, whether the cybersecurity risk assessment is integrated with product planning, whether support periods have been determined realistically, and whether the reporting process will be operational by September 2026.
The guidelines also address, among other topics, free and open-source software, cloud-based functionalities, spare parts, and the interaction of the CRA with vehicle regulation, the Radio Equipment Directive, and the Machinery Regulation.
Discover Our CRA Compliance Suite
Our CRA Compliance Suite provides modular, fixed-fee consulting services to help manufacturers, importers, and distributors of digital products implement the requirements of the Cyber Resilience Act (CRA). Contact us for more information.
'/%3e%3c/svg%3e){kind=small}
'/%3e%3c/svg%3e){kind=small}
