3 Securing the Intangibles: The CRA and Software Products

Yes. Chapter I, Article 3(4) of the CRA defines software as: “the part of an electronic information system which consists of computer code”. Computer code can mean either machine code, which is the set of instructions directly executed by the processor, or source code, which is the set of instructions written in a programming language and compiled by the computer. As such, all the CRA requirements apply to both standalone software products as well as to software provided as part of the product along with associated hardware.

Yes. Unfinished code shared during the development phase for testing or review is not considered to be placed on the market. Similarly, sample or demonstration code provided as part of any training or tutorials are also out of scope.

The July 2026 Commission Guidance on CRA application distinguishes between software that is free of charge and software that is open source. Recall the definition of “placing” a product on the market from Chapter 1. The operative term here is “in the course of commercial activity”. Commercial activity is understood as providing goods, whether for payment or free of charge, in a business-related context. If there is a business-related reason why a product is being given free of charge (i.e., promotional purposes, to operate hardware), then it falls within the scope of the CRA.

The CRA defines a new category called an “open-source software steward“. These are organizations that do the work of developing, publishing, maintaining, and sustaining an open-source software project that is used in business contexts. Notable examples that fall into this category are the Linux Foundation, Eclipse Foundation, and the Apache Foundation. These open-source stewards are subject to a lighter touch than manufacturers. While they might not be compelled to provide full technical documentation, they may need to submit other policy or process documentation.

Using software that is provided as ‘open source’ and is generally seen as ‘free’ to use is placed on the market with no obligations to the creator (as discussed above). In the context of the CRA, this would be commercializing that software, and therefore the manufacturer inherits responsibility for any vulnerabilities in the product.

A Software Bill of Materials (SBOM) is a list of all components, libraries, and modules that are included in a software product. Having an SBOM enables teams to track software elements that go into their product, identify vulnerabilities, and prepare contingency plans. Annex I, Part II (1) of the CRA specifically mentions the SBOM as a requirement:

“Identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product.”

Annex VII of the CRA also explicitly requires an SBOM to be included in the mandatory technical documentation to be accomplished by the manufacturer:

“Where applicable, the software bill of materials, further to a reasoned request from a market surveillance authority provided that it is necessary in order for that authority to be able to check compliance with the essential cybersecurity requirements set out in Annex I.”

The CRA does not explicitly require specific tests to be performed, only that manufacturers “apply effective and regular tests and reviews of the security of the product with digital elements”. However, other requirements, such as only placing products with no known exploitable vulnerabilities, implicitly requires a certain standard in testing products for the requirement to be met. Nevertheless, regular penetration testing, security reviews, and audits are essential in keeping up with the CRA’s technical and vulnerability handling requirements.

• Ensure that the development process of software products follow secure by design principles or methodologies, such as Secure SDLC.
• Make a list of all the components, libraries, and tools that are being used in the development of a software product. The SBOM starts here.
• Look into automated tools to identify components and generate SBOMs for software products.
• Understand the testing and assessment system in place for software products:
  • Is security adequately tested for software products?
  • Are test results documented and compiled?
  • How often are security reviews and audits carried out by a qualified quality assurance team?