Skip to content
folhas.io
secure by design for connected products· Articles

Articles

The CRA for software makers: the regulation is not only for people who solder boards

The most common misconception about the CRA is that it addresses device manufacturers. Software sold as a product is in. Pure SaaS is out, with one exception that catches a lot of people. And 'free of charge' does not mean 'non-commercial'.

Published
Updated

Update note (23 Oct 2026). We added the scope exclusions that were missing, the date from which the obligations of open-source software stewards apply and the Article 13 duties on third-party components, clarified when donations start to indicate a commercial activity, and corrected where the CE marking goes on software.

In the conversations we have with software teams, the pattern repeats: “the CRA is for hardware, it is not about us.” It is the regulation’s most expensive misconception. The scope of the CRA is products with digital elements made available on the market, and a product with digital elements is any software or hardware product, including its remote data processing solutions. An application sold under licence is as much in scope as a router.

What is in

  • Software marketed as a product: desktop, mobile and web applications sold or licensed, operating systems, libraries and components sold commercially, games, tools.
  • Firmware and embedded software, along with the physical product they go into.
  • Remote data processing integral to the product: if the product needs your cloud to perform its functions (the sensor’s app does not work without your backend), that remote processing falls within the product’s scope. It is the exception that catches those who assumed “the cloud part” stayed out.
  • Importers and distributors of any of the above, with their own verification obligations.

What is out

  • Pure SaaS, a service provided without a product placed on the market, stays outside the CRA; depending on the case, it falls under NIS2 as a service. The boundary is functional: the question is whether the remote processing is an integral part of a product’s functions, or whether the service is the offering.
  • Sectors with their own regime: medical and in vitro diagnostic devices, motor vehicles and trailers (Regulation (EU) 2019/2144) and, by delegated act, L-category vehicles except L1e vehicles designed to pedal (Delegated Regulation (EU) 2025/1535), aviation products certified under Regulation (EU) 2018/1139, and marine equipment (Directive 2014/90/EU). The Commission can add further exclusions by delegated act (Article 2(5)).
  • Defence, national security and classified information: products developed or modified exclusively for national security or defence purposes, and products specifically designed to process classified information (Article 2(7)).
  • Spare parts that replace identical components.
Two panels side by side: inside the scope are software sold or licensed, firmware, remote processing integral to the product, and importers and distributors; outside are pure SaaS, open source outside a commercial activity, and sectors with their own regime.
The test is in Article 3(2): remote processing is in when its software is designed and developed by the manufacturer, or under its responsibility, and its absence would prevent the product from performing one of its functions.

Open source: the boundary is commercialisation

The CRA does not apply to free and open-source software developed or supplied outside a commercial activity. But commercialisation is read in substance:

  • Publishing a project on GitHub, accepting contributions and not-for-profit donations: out of scope. Donations exceeding the costs of design, development and provision of the product can already indicate a commercial activity (recital 15).
  • Selling support at a price that goes beyond cost recovery, an “enterprise” edition, or monetising through data: commercial activity, therefore manufacturer, with full obligations.
  • Foundations and entities that systematically support the development of OSS intended for commercial activities have their own, lighter regime: the open-source software stewards, with limited obligations (a cybersecurity policy, cooperation with authorities, and reporting to the extent of their involvement), which apply only from 11 December 2027 (Article 71(2)), unlike manufacturers’ reporting, which applies from 11 September 2026. Stewards are, in fact, among the intended users of ENISA’s single reporting platform.
  • And a frequently ignored point: integrating open-source components into a commercial product makes the integrator responsible for them. The due diligence that Article 13(5) requires when integrating third-party components expressly covers free and open-source software not made available in the course of a commercial activity. And Article 13(6) requires a manufacturer that finds a vulnerability in one of those components to report it to whoever maintains it and, if it develops a fix, to share the code or documentation with that person or entity. Both duties apply to products placed on the market from 11 December 2027. Article 09 looks at a concrete case: the PHP and Node.js flaws fixed on 21 October 2026.

Note also that “free of charge” is not the criterion: an app at no cost to the user but monetised through advertising or personal data is making available in the course of a commercial activity.

The obligations are the same, and some bite harder in software

Those in scope get the full package: the essential cybersecurity requirements of Annex I (including delivery without known exploitable vulnerabilities and secure default configuration), an SBOM, vulnerability handling throughout the support period, a coordinated vulnerability disclosure policy, security updates separate from functional ones wherever technically feasible, reporting of actively exploited vulnerabilities and severe incidents within 24h/72h from 11 September 2026, CE marking and the EU declaration of conformity.

For pure software teams, three of these have a particular bite:

  1. Security updates separate from feature updates. The habit of packing the security patch into the quarterly release along with new features conflicts with the requirement, and with the user who wants the patch without the rest.
  2. Supporting old versions. If customers stay on earlier major versions, the support period forces a formal decision on which versions receive security fixes and for how long, with a written end-of-life policy.
  3. CE marking on software. Yes, it applies: for software, the CE marking is affixed either to the EU declaration of conformity or on the website accompanying the software product, in a section that is easily and directly accessible to consumers (Article 30(1)).

What this means for manufacturers

The right framing question is not “do we have hardware?”, it is “do we place a product on the EU market?”. If yes, the next step is the same one we recommend to device manufacturers: classify the product (the overwhelming majority of software falls under “default”, with self-assessment; but note that browsers, password managers, VPNs and operating systems are in Annex III), inventory components, and set up the vulnerability process before the paperwork process. For software, with CI/CD pipelines already in place, the marginal cost of doing this well is among the lowest in the whole CRA universe.

Sources