The Cyber Resilience Act, Regulation (EU) 2024/2847, is moving from paper to practice. Since 11 September 2026, manufacturers of products with digital elements have had to report actively exploited vulnerabilities and severe incidents. Most of the Regulation's other obligations will apply from 11 December 2027, when products placed on the EU market will have to meet its essential cybersecurity requirements.

To help companies prepare, the European Commission approved its guidance on the application of the CRA on 27 July 2026 (C(2026) 5252). The guidance follows the FAQs published in December 2025 and a public consultation held in spring 2026. It is not binding, but it sets out the Commission's interpretation of some of the most difficult questions under the Regulation, with more than fifty practical examples. It pays particular attention to microenterprises and SMEs.
For hardware manufacturers, software companies, integrators and companies using open-source software commercially, the guidance answers several questions that have been open since the CRA was adopted. This article looks at the most practical ones.

‍
Reporting obligations already apply, even to older products
The first point is the most urgent. Since 11 September 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents to the CSIRT designated as coordinator and to ENISA. Notifications go through ENISA's single reporting platform. The obligation covers all products with digital elements within the scope of the CRA, including those placed on the market before December 2027. Unlike vulnerability handling, which lasts only for the support period, reporting continues after a product is no longer supported.
The deadlines under Article 14 are tight. For both actively exploited vulnerabilities and severe incidents, manufacturers must send an early warning within 24 hours of becoming aware and a full notification within 72 hours. A final report follows: for vulnerabilities, within 14 days after a corrective or mitigating measure is available; for severe incidents, within one month of the notification.
The guidance also clarifies when the clock starts. A manufacturer becomes "aware" once, after an initial assessment of a suspicious event or of information received from a customer, researcher, authority or the media, it has a reasonable degree of certainty that a vulnerability is being actively exploited or that a severe incident has compromised the security of its product. The initial assessment must be carried out promptly. This approach is aligned with the concept of awareness used for NIS2 and for personal data breaches under the GDPR, which helps companies that must report under several regimes.
In practice, companies need an internal process that routes signals from support, security, sales and external researchers to a team able to assess them quickly and to notify within the deadlines.

‍
The Italian framework
In Italy, the Government has given preliminary approval to the national decree implementing the CRA. The draft assigns to the National Cybersecurity Agency (ACN) the roles of notifying authority and market surveillance authority, and sets out the national rules on supervision and penalties. The European reporting obligations do not depend on the decree: they have applied directly since 11 September 2026.
The penalty regime will apply from 11 December 2027. For breaches of the essential requirements and of the manufacturers' obligations, including reporting, fines can reach EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher.
Companies supplying customers subject to NIS2 or DORA should also expect questions on CRA readiness as part of supplier due diligence (see our article on what these customers will ask).
When is software placed on the market?
For physical products, "placing on the market" is a familiar concept. For software, it is less obvious. The guidance clarifies that a standalone software product is placed on the market when its manufacturing phase is complete and it is first supplied for distribution or use on the EU market in the course of a commercial activity. Each later download of the same version is simply another copy of a product already placed on the market.
Variants are different. Builds for different operating systems, or bundles with different feature sets, are distinct products for CRA purposes. Software companies should therefore map their versions, builds and editions carefully, because each may carry its own compliance obligations.

‍
Products designed before the CRA
Many products that will be sold after December 2027 were designed years earlier. The guidance confirms that they may be placed on the market without redesign. The condition is that the manufacturer can show, through the risk assessment and technical documentation, that they achieve an appropriate level of cybersecurity and meet the essential requirements.
Manufacturers are not expected to produce test results covering the original design phase where these would not improve security, and tests can be grouped across product families. Vulnerability handling, updated risk assessments and user information remain fully required.

Open-source software: when does it become commercial?
The CRA does not apply to free and open-source software that is not placed on the market in the course of a commercial activity. The guidance explains where the line lies. The following count as placing on the market:
• charging a price for the software itself, including for pre-compiled binaries;
• using free software to monetise other products or services, for example a free marketplace app that generates commissions or advertising revenue;
• requiring the processing of personal data for purposes other than improving security, compatibility or interoperability.
Where a company offers both a free "community" edition and a paid edition, the two are treated as different products: the paid version is placed on the market, the free version is not. The guidance also addresses support services, donations, financing and integration by other manufacturers, and explains the role of open-source software stewards.
For companies with open-core or freemium models, this is one of the most important sections of the guidance.

‍
Software updates and substantial modification
Software is updated constantly, and companies have been asking when an update turns a product into a new one. The guidance answers by reference to the risk assessment: an update is a substantial modification when it changes the cybersecurity risk level in a way that the manufacturer had not considered in its risk assessment.
The examples are helpful. A dashboard that only displayed machine data and is updated to control those machines has changed its intended purpose and is substantially modified. So is a personal information app that starts analysing user content to build behavioural profiles and make automated decisions. By contrast, a messaging app that adds group chat, a feature already foreseen and assessed in the original risk assessment, is not substantially modified.
The practical lesson is that a well-drafted risk assessment that anticipates planned features can avoid unnecessary new conformity assessments. Product roadmaps and risk assessments should be aligned.
The guidance also distinguishes between modification and integration. A third party that substantially modifies a product already on the market becomes its manufacturer. Where the modification does not affect the product's cybersecurity as a whole, this applies only to the modified part. A company that assembles components, even modified ones, into its own new product is not modifying anything: it is the manufacturer of a new product and responsible for it as a whole, although it can rely on its suppliers' compliance work.

‍
The support period is not simply five years
The CRA requires a support period of at least five years, unless the product is expected to be used for less time. The guidance stresses that five years is a minimum safeguard, not a default. The support period should reflect the time during which the product is expected to be in use, reasonable user expectations, the nature of the product and relevant EU law. Products expected to be used for longer should be supported for longer.
The end date of the support period, at least the month and year, must be indicated clearly at the time of purchase. Users should be notified when support ends where technically feasible. For software released iteratively, each substantially modified version placed on the market needs its own declared support period.
This connects the CRA with consumer law: the declared support period will influence what consumers can reasonably expect in terms of updates under the rules on the sale of goods with digital elements.

‍
Remote data processing: the cloud side of the product
The CRA covers not only software and hardware, but also their remote data processing solutions. The guidance proposes three questions to determine whether a cloud component is part of the product:
1. Does it involve data processing at a distance?
2. Would its absence prevent the product from performing one of its functions?
3. Was the software designed and developed by the manufacturer or under its responsibility?
Where the answer is yes, the cloud back end must be included in the risk assessment, the essential requirements and the reporting obligations. The guidance illustrates this with use cases including a mobile banking application, a smart thermostat, an e-reader, an industrial robot and a cellular network.
Third-party back-end systems that the manufacturer did not design, and that do not support a function of the product, fall outside its scope. The risks they create must still be addressed through the product's design and user information.

‍
Components and due diligence
The guidance distinguishes two complementary obligations. The first is the risk assessment of the product itself, which must also consider external risks such as networks and operating environments. The second is due diligence on integrated components, including third-party and open-source components.
Manufacturers do not have to control the external environment, but they must identify the risks arising from it and mitigate them through product design and instructions. Risk assessments and documentation can be reused across product families.

‍
Where to start
For most companies, the guidance suggests a clear sequence:
1. Reporting. Make sure the reporting process required since 11 September 2026 is in place for all products, including legacy ones, and that the team knows the 24-hour, 72-hour and final-report deadlines.
2. Product mapping. Map products, software versions, variants and cloud components to determine what is in scope and when each was placed on the market.
3. Open source. Review open-source distribution and monetisation models.
4. Roadmaps. Align product roadmaps with risk assessments, so that planned updates do not trigger unexpected substantial modifications.
5. Support periods. Determine realistic support periods and communicate them clearly.
6. Suppliers. Strengthen supplier due diligence and component documentation.

December 2027 may still seem distant, but the guidance makes clear how much work lies ahead. The practical question is no longer whether the CRA applies. It is whether a company can show, product by product and version by version, how it manages cybersecurity risks throughout the lifecycle, and whether it is already able to report when something goes wrong.

‍