12 minute read | September.08.2026
On July 27, 2026, the European Commission published guidance on the Cyber Resilience Act (CRA).
The CRA is the EU’s horizontal cybersecurity regulation for products with digital elements. Its objective is to strengthen the EU’s approach to cybersecurity, improve the functioning of the internal market and ensure that products are designed, developed and maintained with cybersecurity in mind throughout their lifecycle.
While most obligations take effect on December 11, 2027, manufacturers should note that reporting obligations begin as early as September 11, 2026.
Following an initial FAQ published in December 2025, the Commission released a comprehensive draft guidance document on March 3, 2026, which was adopted on July 27, 2026 after public consultation. As with all Commission guidance, this document is not legally binding but represents the Commission's interpretation of the CRA.
The guidance does not attempt to cover the entire regulation. Instead, it focuses on clarifying the rationale and the practical implementation of key provisions where interpretation questions have emerged.
The Commission has indicated that additional guidance may follow, including materials specifically targeted at manufacturers subject to both the CRA and other EU harmonization legislation.
Determining which products fall within the CRA's scope has proven challenging for many manufacturers. The guidance provides clarifications on several aspects.
Products with Digital Elements
The CRA defines products with digital elements as “a software or hardware product and its remote data processing solutions” (Article 3(1)). Importantly, a distinction must be made between software products covered by the CRA and the mere remote provision of services, which is not subject to the CRA.
In order to be in scope, the product must be provided to a user and consequently downloaded, installed or otherwise supplied to the user, so the user can operate the software on their side. Software executed remotely for user access regularly falls outside the scope of the CRA.
Placing Intangible Products on the Market
The guidance states that an intangible product, such as standalone software, is considered to be placed on the market once the manufacturing phase is complete and the software is supplied for the first time for distribution or use on the EU market in a commercial context.
Subsequent downloads or distribution of the same version constitute instances of making that product available, and not new placements. However, where software is available in different variants—which differ in their included components, configurations or enabled functionalities— these different variants should be deemed distinct products. Subsequent iterations of a software product constitute new placements on the market only when they qualify as "substantial modifications" of the original product.
Data Connection Requirements
Article 2(1) limits the CRA's scope to products whose intended purpose or reasonably foreseeable use includes a data connection to a device or network. However, the CRA does not define "data connection," creating uncertainty for manufacturers.
The guidance clarifies that a data connection requires more than mere transmission of binary information. The binary data must be deliberately encoded as information by a source and capable of being decoded as information at the destination. This excludes pure signal transmission, without conveying digitally encoded information.
Clarification on Remote Data Processing Solutions
Article 3(2) defines remote data processing solutions as logical or physical data processing solutions at a distance from the product, designed and developed by the manufacturer or under its responsibility, whose absence would prevent the product from performing one of its functions.
The guidance clarifies that "at a distance" typically means processing outside the product's user environment or an organization's operational environment, though this does not prevent edge processing. Cloud computing represents a typical example.
Internal systems relating to the manufacturer's own operations, such as HR systems, CRMs, CI/CD pipelines or security update distribution infrastructure, should not be considered as remote data processing solutions.
Complex Systems and the CRA
Complex systems (e.g. systems composed of multiple hardware and software elements) are often characterized by long development cycles, extended operational lifetimes and reliance on established infrastructure. This may lead to situations where certain technical characteristics of those systems may be difficult to modify.
The guidance confirms that these characteristics do not exclude complex systems from the CRA's scope. However, they illustrate the regulation's risk-based approach, which allows compliance to be demonstrated in different ways depending on product characteristics and constraints, as provided in Article 13(3):
Products Developed Before the CRA’s Application
The mere fact that a product was designed and developed before the CRA’s application date does not exclude it from the CRA’s scope.
Compliance does not necessarily require redesigning such products. Manufacturers must conduct a cybersecurity risk assessment under Article 13(2) to determine whether the product meets the essential cybersecurity requirements. Where the assessment demonstrates that existing security measures appropriately address identified risks, manufacturers may rely on those measures to demonstrate compliance without introducing new features or redesigning the product.
The treatment of FOSS under the CRA is of high practical importance, since a significant number of products with digital elements contain at least some open-source components.
Defining FOSS
Article 3(48) defines FOSS as “software the source code of which is openly shared and which is made available under a free and open-source licence which provides for all rights to make it freely accessible, usable, modifiable and redistributable”.
The guidance emphasizes that "openly shared" means publicly available (either “upstream” or “downstream”), not merely provided to paying customers or a limited group. Software distributed under a FOSS license, but whose source code is only shared on a restricted or conditional basis, shall not qualify as FOSS under the CRA.
Who is Responsible for FOSS Compliance Under the CRA?
FOSS often relies on decentralized collaboration models, complicating the identification of responsible persons under the CRA. The guidance clarifies that FOSS is "under the responsibility" of natural or legal persons who publish it and exercise primary control over development, releases, and distribution decisions (typically referred to as maintainers). Contributors who provide source code but do not control releases, roadmaps or governance are not considered responsible, even though they contributed to the codebase.
Integration of FOSS Components
According to the guidance, manufacturers integrating FOSS components into their own products do not become responsible for the individual compliance of those components with the CRA. Full compliance is required if their own product falls within the CRA's scope. This obligation extends to integrated components through the due diligence requirement under Article 13(5) and associated reporting requirements under Article 13(6).
When FOSS Is Placed on the Market
FOSS is placed on the market when a person supplies it while charging a price for the software itself, making that person the manufacturer under the CRA. If provided for free, it is not considered placed on the market. The same is true for “community versions” (i.e. free versions of a product provided by manufacturers of FOSS, whose codebase is almost identical to a paid version).
The guidance distinguishes between legal and natural persons when both free and paid versions exist:
FOSS can also be considered placed on the market without direct user payments if it monetizes other products or services; or requires processing personal data as a condition of use for reasons other than exclusively improving security, compatibility or interoperability. The mere option to purchase support or other professional services (such as consultancy, training or professional services) separately does not constitute market placement.
Are Donations for Free Products Considered Commercial Activity?
Recital 15 states that accepting donations without intention to make profit should not constitute commercial activity, a prerequisite for market placement. The guidance clarifies that merely including a donation link on a website should not be viewed as intent to profit, even where donations exceed product costs. However, commercial activity may be assumed where, based on overall circumstances, donations are de facto equivalent to charging a price to access the product or certain functionalities.
The concept of "substantial modification" under Article 3(30) is relevant in multiple CRA provisions, including Articles 21, 22 and 69(2). The most important consequence is that substantially modified products are treated as new products. Making them available constitutes a new placement on the market, triggering fresh conformity assessment obligations.
Main points about substantial modification:
Physical Repairs and Spare Parts
Physical repairs shall not necessarily constitute substantial modifications, particularly where the intended purpose and functionalities remain unchanged and the risk level is unaffected.
Upgrades may lead to substantial modifications depending on their impact:
Software Updates
The guidance addresses when software updates qualify as substantial modifications. The determination depends on whether the update changes the product's intended purpose, significantly alters its cybersecurity risk profile or affects compliance with essential requirements.
Manufacturers must keep risk assessments and technical documentation accurate and up-to-date under Articles 13(7) and 31(2), regardless of whether updates constitute substantial modifications.
Article 13(8) requires manufacturers to determine a support period for effectively handling vulnerabilities. The support period must be at least five years, unless the product is expected to be in use for less time.
The Commission may adopt delegated acts specifying minimum support periods for specific product categories where market surveillance data suggests inadequate support periods. The guidance emphasizes that support periods must reflect how long products are expected to be in use; considering user expectations, product nature, intended purpose and relevant EU law in determining product lifetime.
Importantly, a substantial modification requires a reassessment of the support period against the requirements under Article 13(8). As the guidance expressly clarifies, this does not automatically mean that the support period must be reset or even extended.
Products with core functionality matching categories in Annex III are "important products" subject to more stringent conformity assessment under Article 7(1).
The guidance addresses the undefined term "core functionality":
The risk assessment under Article 13(2) represents a core manufacturer responsibility. The guidance emphasizes that manufacturers must identify relevant risks and assess their potential impact on the product, not based on internal risk tolerance, commercial strategy, or cost considerations, but against a regulatory threshold: ensuring an appropriate level of cybersecurity based on identified risks.
While cybersecurity risk cannot be entirely eliminated, products may only be placed on the market where residual risks—after appropriate measures are taken—have been sufficiently addressed to meet essential cybersecurity requirements. Where identified risks cannot be adequately addressed through available measures, compliance may require changes to product design, functionality or intended purpose.
For similar products exposed to similar cybersecurity risks, manufacturers may reuse risk assessments and conformity documentation for product families, provided differences between products do not affect their cybersecurity properties.
Reporting obligations under Articles 14(1) and 14(3) require manufacturers to notify Computer Security Incident Response Teams (CSIRTs) designated as coordinators, and the European Union Agency for Cybersecurity (ENISA) of actively exploited vulnerabilities and severe incidents as they become aware.
These obligations overlap with reporting requirements under other EU regulations, including the GDPR and NIS 2 Directive. The guidance clarifies that the term "becoming aware" should be interpreted consistently with recital 31 of Commission Implementing Regulation (EU) 2024/2690 and Section II(A) of Guidelines 9/2022 on personal data breach notification under the GDPR.
Manufacturers are obliged to apply effective and regular tests of their products throughout the support period. It is not enough to implement mechanically repeated, unchanged tests at intervals but a regular review to identify whether new input (e.g. new threats or vulnerabilities) require an update of existing tests.
The frequency of the tests should be proportionate to the cybersecurity risk profile.
Validity of EU Type-Examination Certificates
Article 69(1) addresses the continued validity of EU type-examination certificates and approval decisions issued under other EU harmonization legislation. The guidance clarifies that this continued validity is limited to cybersecurity risks and corresponding requirements covered by the respective EU harmonization legislation under which certificates were issued.
Certificates issued under regulations addressing different aspects of product safety or performance do not automatically satisfy CRA requirements unless they specifically address cybersecurity requirements equivalent to those in the CRA.
Other Regulatory Overlaps
The guidance notes potential overlaps with Regulation (EU) 2024/1689 Artificial Intelligence Act (AI Act), Regulation (EU) 2022/2554 Digital Operational Resilience Act (DORA) and sector-specific legislation. The Commission has indicated that future guidance may specifically address the CRA's interplay with the AI Act and DORA.
For questions, please contact Dr. Christian Schröder.