The CRA itself asks for this. Article 26 tells the Commission to publish guidance that helps companies apply the regulation, with special attention for small and medium-sized businesses (SMEs). On 27 July 2026, the Commission delivered on that promise. The document runs to about 80 pages and works through the questions manufacturers have been asking most often, backed by 67 practical examples, flowcharts, and use cases.

One thing to keep in mind: this guidance is not binding law. Only the Court of Justice of the EU can give a binding interpretation of the CRA. But market surveillance authorities and notified bodies will use this guidance to read the law consistently across all member states. In practice, that makes it the document you want next to the regulation text on your desk.

Here are some highlights:

Scope: is your product even covered?

The biggest part of the guidance deals with scope, and that makes sense. It is the question most companies struggle with first. A few clarifications stand out.

Where your software runs matters a lot. If it executes on the user's device, like a downloaded app or a browser extension, it counts as a product with digital elements. A web application that only runs through a browser generally does not, unless it counts as remote data processing that a physical product depends on.

For open-source code, simply publishing it on a public repository is normally not "placing it on the market". That distinction protects a lot of community projects from obligations they were never meant to carry.

Open-source software gets a lighter, clearer regime

The guidance spends real effort on open source, and this is good news for the community. Non-commercial open-source software, developed outside any commercial activity, mostly falls outside the CRA's scope. The trigger is commercial activity, not the license type.

The guidance also introduces the idea of open-source stewards, meaning organizations that maintain FOSS projects. They get a defined, proportionate set of duties focused on keeping the software secure and viable, rather than full manufacturer obligations.

Substantial modification: it is about risk, not size

A change to your product only triggers a new conformity assessment if it counts as a "substantial modification". The guidance is clear that this is about the change's effect on cybersecurity risk, not how big the change looks on paper.

Good news for anyone maintaining products: a security update that reduces risk, without changing the product's purpose or opening new risks, is generally not a substantial modification by itself.

Support periods: five years is a minimum, not a target

Your support period, the time during which you must handle vulnerabilities, must reflect how long people can reasonably expect to use the product. Five years is the legal minimum, not a number you can simply write down and forget. If your product is normally used longer, plan a longer support period.

You also need to tell users the support end date, at least the month and year, at the time of purchase.

Important and critical products: one core functionality decides the class

Classification decides which conformity route you follow. The guidance confirms that only the product's core functionality, meaning the main feature without which it would not do its job, decides whether it falls under Annex III (important) or Annex IV (critical). A smartphone that includes an operating system does not automatically become an operating system for classification purposes.

Remote data processing: the "would it still work without it" test

For products that rely on cloud or server components, the guidance offers a practical test. Ask yourself: is the processing happening at a distance, would the product stop performing one of its functions without it, and was that software built by or under the responsibility of the manufacturer. If yes to all three, it is part of your product.

Reporting and vulnerability handling

This is the part I get asked about most in training sessions, so let me be precise here. The guidance clarifies the Article 14 reporting duties for actively exploited vulnerabilities and severe incidents, and the Annex I vulnerability-handling requirements, such as sharing fixes and running regular security tests.

Remember the two dates, and do not mix them up. Reporting obligations under Article 14 start on 11 September 2026. The CRA's full application, meaning the broader set of obligations, starts on 11 December 2027. These are two different milestones, more than a year apart. If you only remember one date wrong, this is the mistake to avoid.