Does the CRA apply to software we give away free of charge?

Yes, where the supply happens in the course of a commercial activity. Article 3(13) covers the manufacturer expressly, whether for payment, monetisation or free of charge. Recital 15 lists indicators of a commercial activity, such as a charge for technical support that does more than recover actual costs, a software platform through which the manufacturer offers other services for profit, or donations exceeding the costs of development. Recital 20 makes the counterpoint: merely hosting software on open repositories, including through package managers or collaboration platforms, is not in itself making it available on the market.

Does every new version need its own conformity assessment?

No, only a substantial modification triggers a fresh assessment. Under Recital 39 a product should be considered substantially modified by a software change where the update changes the intended purpose and the manufacturer did not foresee that in the original risk assessment, or where the nature of the hazard has changed or the level of cybersecurity risk has increased because of the update and the updated version is made available on the market. A security update that leaves the intended purpose alone does not qualify. Versions still have to be documented, because point 1(b) of Annex VII requires the technical documentation to state the versions of software affecting compliance with the essential cybersecurity requirements.

Is our software an important product with digital elements?

Annex III decides that, and it is strikingly full of pure software categories. Class I names, among others, standalone and embedded browsers, password managers, software that searches for, removes or quarantines malicious software, network management systems, security information and event management (SIEM) systems, boot managers, operating systems, and public key infrastructure and digital certificate issuance software. Class II lists hypervisors and container runtime systems as well as firewalls, intrusion detection and intrusion prevention systems. Landing in one of those categories narrows the choice of conformity assessment procedure, and Important products with digital elements sets out what follows.

Cyber Resilience Act

Software

Legal definition Art. 3(4) CRA

“the part of an electronic information system which consists of computer code”

Regulation (EU) 2024/2847, Art. 3(4) CRA

Software is defined in Article 3(4) of the Cyber Resilience Act (CRA) as the part of an electronic information system which consists of computer code. The Regulation therefore treats software not as a thing in its own right but as a part of a system.

The definition on its own imposes nothing. What it settles is by which route a given item enters the scope of the CRA, how the CE marking has to be affixed, and which reliefs the Regulation grants to software alone.

What the term covers

The wording sets no lower limit and prescribes no form. It states two features: the item must be part of an Electronic information system, and it must consist of computer code. Firmware in a microcontroller qualifies just as much as an operating system, a device driver, a library, a mobile application or a script.

What counts as computer code is nowhere defined in the CRA. Neither a distinction between source and machine code nor one between compiled and interpreted execution can be read out of the term. The delivery form matters just as little, whether download, physical media, or preinstalled on a device.

The counterpart sits in point (5). Hardware is a physical electronic information system, or parts thereof capable of processing, storing or transmitting digital data. Both terms describe parts of the same system, one the physical part and the other the coded part.

Three roles in which the CRA catches software

Obligations never attach to software as such. They attach to the role in which it reaches the market:

As a product of its own. Article 3(1) describes the Product with digital elements as a software or hardware product and its remote data processing solutions. A software product therefore stands on an equal footing with a device.
As a component. Under Article 3(6) a Component is software or hardware intended for integration into an electronic information system. Where a software component is placed on the market separately, Article 3(1) makes it a product with digital elements in its own right.
As a remote data processing solution. Article 3(2) covers data processing at a distance for which the software is designed and developed by the manufacturer or under the manufacturer’s responsibility, and without which the product could not perform one of its functions.

The third role also draws the outer boundary. Recital 12 states that cloud services designed and developed outside the responsibility of a manufacturer fall outside the scope. Cloud computing services and cloud service models such as SaaS, PaaS and IaaS are covered instead by Directive (EU) 2022/2555, the NIS2 Directive. The same recital records that entities providing cloud computing services in the Union fall within its scope where they qualify as medium-sized enterprises under Recommendation 2003/361/EC or exceed the ceilings set out there.

CE marking without a housing

Software has no surface to which a mark could be affixed indelibly. Article 30(1) deals with that case expressly. For products with digital elements in the form of software, the CE marking is affixed either to the EU declaration of conformity under Article 28 or on the website accompanying the software product. Where the website is chosen, the relevant section must be easily and directly accessible to consumers.

Production, although nothing is manufactured

The conformity assessment modules of the CRA examine the design, development and production phases. For software the production phase in the usual sense largely falls away. Recital 92 resolves that. Compiling, building into versions, packaging, making available for download and copying onto physical media count as activities amounting to production. Your build and release pipeline is therefore part of what is assessed, not an afterthought.

The special rule for software versions

Software development proceeds in versions, and every substantially modified version is a fresh placing on the market. Without a special rule a manufacturer would have to keep supplying security updates for every version it ever shipped.

Article 13(10) limits that. Where a manufacturer has placed subsequent substantially modified versions of a software product on the market, it may ensure compliance with the requirement in Part II, point (2), of Annex I, namely addressing and remediating vulnerabilities without delay including by providing security updates, only for the version last placed on the market. Two conditions hang on this. Users of the earlier version must have access to the version last placed on the market free of charge, and they must not incur additional costs to adjust the hardware and software environment in which they use the original version.

Recital 40 gives the example of a desktop operating system upgrade that requires no new hardware, neither a faster central processing unit nor more memory. It also makes clear that the manufacturer should keep complying with the remaining vulnerability handling requirements for the support period. A coordinated vulnerability disclosure policy and measures for sharing information about potential vulnerabilities should cover all subsequent substantially modified versions of the software product placed on the market. Whether an update reaches that threshold at all is a question for Substantial modification.

Test builds and old archives

Two further provisions apply to software alone. Under Article 4(3) Member States must not prevent the making available of unfinished software that does not comply with the CRA, provided it is made available only for a limited period required for testing and carries a visible sign clearly indicating that it does not comply and that it will not be available on the market for purposes other than testing. Recital 37 names alpha versions, beta versions and release candidates, expects a risk assessment before release, and adds that users should not be forced to upgrade to versions released only for testing. Article 4(4) withholds that relief from safety components covered by Union harmonisation legislation other than the CRA.

Article 13(11) additionally permits public software archives that ease access to historical versions. The condition is that users are clearly informed, in an easily accessible manner, about the risks of using unsupported software.

Practical questions

: Yes, where the supply happens in the course of a commercial activity. Article 3(13) covers the manufacturer expressly, whether for payment, monetisation or free of charge. Recital 15 lists indicators of a commercial activity, such as a charge for technical support that does more than recover actual costs, a software platform through which the manufacturer offers other services for profit, or donations exceeding the costs of development. Recital 20 makes the counterpoint: merely hosting software on open repositories, including through package managers or collaboration platforms, is not in itself making it available on the market.
: No, only a substantial modification triggers a fresh assessment. Under Recital 39 a product should be considered substantially modified by a software change where the update changes the intended purpose and the manufacturer did not foresee that in the original risk assessment, or where the nature of the hazard has changed or the level of cybersecurity risk has increased because of the update and the updated version is made available on the market. A security update that leaves the intended purpose alone does not qualify. Versions still have to be documented, because point 1(b) of Annex VII requires the technical documentation to state the versions of software affecting compliance with the essential cybersecurity requirements.
: Annex III decides that, and it is strikingly full of pure software categories. Class I names, among others, standalone and embedded browsers, password managers, software that searches for, removes or quarantines malicious software, network management systems, security information and event management (SIEM) systems, boot managers, operating systems, and public key infrastructure and digital certificate issuance software. Class II lists hypervisors and container runtime systems as well as firewalls, intrusion detection and intrusion prevention systems. Landing in one of those categories narrows the choice of conformity assessment procedure, and Important products with digital elements sets out what follows.

This glossary is for orientation and does not constitute legal advice. The wording of Regulation (EU) 2024/2847 prevails.