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

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, not a marketing one: 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 devices, vehicles, aviation, and products developed exclusively for defence or national security.
  • 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 boundary is functional, not a marketing one: the question is whether the remote processing is part of a product's functions, or whether the service is the offering.

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 donations: out of scope.
  • Selling support, 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. 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. Article 13’s due diligence on third-party components does not distinguish purchased code from cloned code.

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 active exploitation 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 an end-of-life policy in writing rather than by custom.
  3. CE marking on software. Yes, it applies: in practice, it goes on the documentation accompanying the product or on the download page. Seeing software with a CE marking will stop being strange.

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, which makes not doing it hard to justify.

Sources