European Commission guidance on the CRA

01What this is

Art. 26 requires the Commission to publish guidance to help economic operators apply the CRA, with a particular focus on making compliance easier for small and medium-sized enterprises. On 27 July 2026 the Commission approved the content of that guidance (document reference C(2026) 5252). It runs to some 80 pages and works through the questions manufacturers ask most often.

Guidance is not binding and does not change the law: an authoritative interpretation of the CRA can only come from the Court of Justice of the EU. But market surveillance authorities and notified bodies look to it for a consistent, harmonised reading, so it is the natural companion to the Regulation.

02What counts as a product

The largest part of the guidance is about scope, the most asked-about area. A product with digital elements is a software or hardware product (and its remote data processing) whose use includes a direct or indirect data connection. Art. 3(1)

• Where software runs decides it; software that executes on the user's device (a downloaded app, a browser extension, a locally installed client) is a product with digital elements. Software merely accessed remotely through a browser is not, on that basis alone.
• Web apps and websites; a web application used only through a browser, and a website that merely presents information, are generally not products with digital elements. They fall in scope only where they qualify as remote data processing that supports a product's function.
• Source code; the CRA's definition of software covers both machine and source code, but simply sharing open-source code on a public repository is generally not "placing on the market". Art. 3(4)

If you are unsure where your product sits, the Fast Check and the plain-language explainer walk through scope in practice.

03Open-source software

The guidance sets out the tailored, lighter regime for open source in detail. Non-commercial open-source software developed outside a commercial activity is largely outside scope; the trigger is commercial activity and whether the software is placed on the market.

• When FOSS is "placed on the market"; the guidance works through charging a price, monetising related services or requiring personal data, paid support, donations, financing arrangements, and not-for-profit structures, and integration of FOSS by other manufacturers.
• Open-source software stewards; a defined, proportionate set of duties focused on supporting the security and continued viability of the software.
• Important FOSS; important products (class I or II) that are placed on the market as free and open-source software may follow the lighter default-category conformity procedures. Art. 32(5)

04Substantial modifications

Whether a change is a substantial modification decides whether a new conformity assessment is needed. Recital 39 frames it: a product is substantially modified where a change alters its level of cybersecurity risk in a way the manufacturer had not already considered in its risk assessment. Art. 3(30)

• Security updates are generally not substantial modifications; their purpose is to reduce risk, so a security fix that does not change the product's intended purpose or introduce new risks does not, by itself, count.
• It is about risk, not size; the test is the change's impact on the cybersecurity risk profile (new threat vectors, new attack scenarios, or a changed likelihood or impact), not the scale of the change.
• The consequence; a substantially modified product is treated as newly placed on the market. Where someone other than the original manufacturer makes the change, they take on manufacturer obligations for the modified part. Art. 21 · 22

The CE-marking guide covers the conformity assessment that a new placing on the market triggers.

05Support period

The support period is the time during which vulnerabilities must be handled. It should reflect how long the product is reasonably expected to be in use. Art. 13(8)

• Five years is a floor, not a default; the period must be at least five years unless the product is expected to be used for less. Products reasonably expected to be in use longer should have longer support periods.
• Tell users; state the end date (at least the month and year) at the time of purchase, and notify users when it expires where technically feasible. Art. 13(19)
• Flexibility for software; manufacturers may, under conditions, remediate vulnerabilities only in the latest version, where users can upgrade free of charge and without additional cost. Art. 13(10)
• After a substantial modification; reassess the period against the same criteria; it does not automatically reset or extend.

Plan yours with the support-period & EOL planner.

06Important & critical products

Classification decides the conformity route. A product is important if its core functionality matches an Annex III category (class I or II), and critical if it matches Annex IV; everything else is a default product that may self-assess. Art. 7 · 8 · 32

• Core functionality is the test; the product's main features, without which it would not meet its intended purpose. Ancillary functions do not change the class, and merely integrating an important or critical component does not make the whole product important or critical: a smartphone that embeds an operating system is not itself an "operating system".
• One core functionality; for the purpose of choosing the conformity route, a product is taken to have a single core functionality, identified in its technical documentation.
• The category definitions; the technical descriptions of the important and critical categories are set out in Commission Implementing Regulation (EU) 2025/2392.

Match your product against the categories with the product-class finder.

07Remote data processing

Remote data processing solutions are part of a product with digital elements only where they are necessary for the product to perform its functions. Art. 3(2) The guidance offers a practical test: is the processing done "at a distance"; would its absence prevent the product from performing one of its functions; and was the software designed and developed by, or under the responsibility of, the manufacturer.

It illustrates the test with worked use cases (a mobile banking application, a smart thermostat, an e-reader, an industrial robot and a cellular network) that show where the boundary between a product and a mere service sits.

08Reporting & vulnerabilities

The guidance also clarifies the ongoing duties: the Article 14 reporting of actively exploited vulnerabilities and severe incidents, and the Annex I vulnerability-handling requirements: reporting upstream and sharing security fixes, addressing known exploitable vulnerabilities, and running effective, regular security tests and reviews. Art. 14 · Annex I

09Other official sources

The guidance sits alongside two other official reference points that are worth reading together.

Harmonised standards. The essential requirements in Annex I are written in outcome terms; once a relevant harmonised standard is cited in the Official Journal, following it gives a presumption of conformity. The Commission's standardisation request M/606 was accepted by CEN, CENELEC and ETSI in 2025 and covers around 41 standards. The two core horizontal standards (secure development and vulnerability handling) are expected by 30 August 2026, the vertical product standards by 30 October 2026, and the remaining horizontal standards by 30 October 2027, about a year before full application.