[co-author: Justyn Brockmeyer]
With only months to go until the first set of obligations under the EU Cyber Resilience Act (“CRA”) become applicable, the Commission has published on 3 March 2026 its first draft guidance intended to assist economic operators and market surveillance authorities in applying the CRA. The CRA, as part of the broader EU product law framework, establishes mandatory cybersecurity requirements that will significantly affect most hardware and software products made available on the EU market. CRA implementation projects reveal some legal uncertainty on key questions on the CRA's scope and key obligations. The published draft guidance based on Art. 26 CRA provides important additional clarification for economic operators and will, once finalized, serve as an essential resource on the interpretation of the CRA. This article provides an overview of the draft guidance.
Background
The CRA (Regulation (EU) 2024/2847) establishes essential cybersecurity requirements for “products with digital elements” and includes several obligations for economic operators such as manufacturers, importers, and distributors when making available products with digital elements in the EU.
While the CRA will apply in full from 11 December 2027, the legal framework on the notification of conformity assessment bodies will already apply from 11 June 2026 and obligations for reporting vulnerabilities and incidents to authorities will apply from 11 September 2026. For a full overview of the CRA, see our previous blog posts on the CRA’s implications for companies and key 2026 milestones toward CRA compliance as well as our Digital Transformation Academy video.
Since late 2025, the Commission has started publishing practical implementation materials, including FAQs on the CRA, and has adopted the first CRA implementing and delegated acts (for an overview see our post here). However, there remains legal uncertainty on several issues that usually come up in CRA implementation projects, such as the determination of in-scope products, especially with regard to remote data processing solutions and free and open source software (“FOSS”), the determination of support periods, or issues relating to software products given their non-tangible nature.
Therefore, the publication of additional guidance from the European Commission under Art. 26 CRA to assist economic operators in applying the CRA was highly anticipated. Following a prior announcement of the draft’s release for early 2026, the Commission published its draft guidance on 3 March 2026 for public stakeholder consultation.
Overview on the draft guidance
The draft guidance provides additional valuable context, practical examples and further clarification on several central aspects of the CRA. These include:
- Scope and applicability of the CRA (Sec. 2 of the guidance): The guidance provides clarifications on key concepts like "placing on the market", including in cases involving products that were designed before the CRA becomes applicable. Software as a non-tangible product is regarded as placed on the market when it is first supplied for distribution or use on the EU market, such as through offering it for download or remote access. The guidance also clarifies the scope of software products (in particular by explaining that sample or demo code provided as part of tutorials is not treated as being placed on the market), as well as the “data connection” requirement in Art. 2(1) CRA to distinguish products that merely use electrical signals from those that exchange digitally encoded information (with CRA scope implications). It further clarifies how the “product” within the scope of the CRA can be determined in case of combined hardware and software products, and which aspects must be taken into account in case of complex systems composed of multiple hardware and software elements.
- FOSS and open-source software stewards (“OSS Stewards”) (Sec. 3 of the guidance): Under the guidance, “responsibility” for FOSS is linked to who publishes and controls a project, whereas mere technical permissions (e.g. commit access) are not sufficient. The guidance also sets out criteria on when software is monetized and thereby placed on the market as part of a commercial activity, including scenarios where the software is free but monetizes services around it, and where access is conditioned on personal data processing beyond security, compatibility, or interoperability purposes. Financial donations can amount to placing on the market where access to essential functionality or updates is effectively conditional on donating or donors receive contractual advantages beyond community perks. Where both “community” and monetized versions exist, a paid version may trigger manufacturer obligations, while a legal entity may still qualify as an OSS Steward for a non-monetized community version. The guidance further describes the OSS Steward concept in operational terms (including what “sustained support” can cover, such as hosting collaboration platforms, project governance, and steering development) and confirms that the same legal entity can be a manufacturer for one FOSS and an OSS Steward for another.
- Substantial modifications, repairs, and spare parts (Sec. 4 of the guidance): The guidance provides practical criteria for when repairs or replacement parts do, or do not, qualify as a “substantial modification”, emphasizing a case-by-case assessment tied to intended purpose, compliance, and risk level. It offers an analytical framework for assessing whether software updates may qualify as substantial modifications, focusing on whether new threat vectors or materially changed attack scenarios are introduced. If a change qualifies as a substantial modification, the modified product is treated as newly placed on the market and the party carrying out (or commissioning) the modification is treated as the manufacturer for CRA purposes. The guidance also addresses re-use of existing tests and documentation for unchanged aspects and the focus of conformity assessments on the modified parts. The guidance confirms that legacy products placed on the market before 11 December 2027 are subject to the CRA only if they undergo a substantial modification from that date, and discusses what manufacturers should be able to demonstrate in this context.
- Support period (Sec. 5 of the guidance): In a rather short section, the guidance emphasizes that the five-year support period is a minimum safeguard, not a default standard that can be applied to all products. Support periods should reflect realistic expected use, and products expected to be used longer than five years should have correspondingly longer support periods, based on the criteria in Art. 13(8) CRA. For iterative software, the guidance indicates that each version placed on the market should have a declared support period; it also provides practical clarification on when remediation may be focused on the latest version and on what constitutes “additional costs” for users.
- Important and critical products (Sec. 6 of the guidance): The guidance clarifies that classification is based on the “core functionality” of the product as a whole, not on the classification of integrated components in isolation (including where a product integrates components that could themselves be in a higher class). It also discusses practical implications for conformity assessment pathways, including how harmonized standards covering core functionality interact with internal control procedures and the need to address risks arising from additional functions not covered by a standard.
- Cybersecurity risk assessment and integration of components (Sec. 7 of the guidance): The guidance addresses how manufacturers are expected to structure and document the CRA cybersecurity risk assessment under Art. 13(2) CRA in practice, including how to identify intended use, reasonably foreseeable misuse, threat scenarios, and risk treatment measures across the product lifecycle. It also clarifies how to handle third-party and open-source components in the risk assessment.
- Remote data processing solutions (“RDPS”) (Sec. 8 of the guidance): The guidance provides a structured test for RDPS, including the “at a distance” element, a functional dependency assessment (whether absence would prevent the product from performing a function), and whether the relevant software is developed by, or under the responsibility of, the manufacturer. In line with the CRA text, the guidance clarifies that one must distinguish between remote processing under responsibility of the manufacturer (which can qualify as RDPS) and reliance on third-party services not developed under the manufacturer’s responsibility (which are treated more like an external component). With regard to cloud services, the guidance particularly addresses reliance on third-party IaaS, PaaS, or SaaS, but does not discuss the CRA’s applicability to cloud services more extensively.
- Reporting and vulnerability handling (Sec. 9.1, 9.2 of the guidance): The guidance addresses upstream reporting and sharing of security fixes, including that manufacturers are not required to ensure a proposed fix is accepted upstream. Furthermore, the guidance clarifies when an “exploitable vulnerability” should be treated as “known,” referencing factors such as public vulnerability databases, coordinated disclosure, internal testing, and prominent reporting in reliable media, alongside the need to validate applicability to the specific product.
- Interaction with other EU legislation (Sec. 9.3 of the guidance): Finally, the guidance provides clarifications on specific scope exclusions (including in the automotive context) and how to assess components designed exclusively for integration into exempt products.
What’s next?
The guidance is still in a draft status, and the Commission encourages stakeholders to submit feedback on the draft until 31 March 2026. More information on how to provide feedback is made available on the Commission’s website.
Companies affected by the CRA should in any case review the draft guidance as it may be a helpful resource during CRA implementation projects. When doing so, it is important to keep in mind that the final guidance may differ from the current draft. Also, even once finalized, the guidance remains non-binding for economic operators or other actors subject to the CRA, as an authoritative interpretation of the CRA may only be given by the Court of Justice of the European Union.
Apart from the guidance, companies should continue preparing for meeting key CRA compliance milestones in 2026, such as compliance with reporting obligations from 11 September 2026. See our previous blog post for details on how to prepare for CRA compliance.
[View source.]
