CRA software supply chain compliance is broader than generating an SBOM. The manufacturer needs a controlled component inventory, dependency due diligence, vulnerability monitoring, supplier information, update planning and technical documentation. The SBOM is a required vulnerability-handling artifact, but the CRA does not generally require manufacturers to publish the SBOM to every user.
Software Supply Chain Security Is Part of CRA Product Security
The Cyber Resilience Act treats integrated software and hardware components as part of the security of the finished product. Article 13 requires manufacturers to exercise due diligence when integrating components sourced from third parties so that those components do not compromise product cybersecurity. That responsibility includes commercial components and free and open-source software components, including open-source components that were not made available on the market in the course of a commercial activity.
The CRA Requires Manufacturers to Know What Is in the Product
Annex I Part II requires manufacturers to identify and document vulnerabilities and components contained in products with digital elements. A manufacturer therefore needs enough component visibility to connect a released product version to the software libraries, packages, frameworks, firmware and other relevant elements on which it depends. A one-time procurement list is not enough where dependencies change between releases.
An SBOM Is an Explicit CRA Vulnerability-Handling Requirement
Annex I Part II point 1 expressly requires an SBOM as part of identifying and documenting components and vulnerabilities. The SBOM must use a commonly used and machine-readable format and cover at least the product's top-level dependencies. Article 3 defines a software bill of materials as a formal record containing details and supply-chain relationships of components included in the software elements of a product with digital elements.
Top-Level Dependencies Are the Legal Minimum, Not Necessarily the Operational Maximum
The CRA states that the SBOM must cover at least top-level dependencies. That is a legal floor for the SBOM requirement, not a statement that transitive dependencies can be ignored for security management. Where a transitive dependency can introduce exploitable risk, effective vulnerability handling may require deeper dependency visibility than the minimum SBOM wording alone suggests.
Third-Party Components Require Due Diligence Before Integration
Article 13(5) requires due diligence when integrating third-party components. Recital 34 explains that the level of due diligence should reflect component cybersecurity risk and can include checking CRA conformity where applicable, security-update history, known-vulnerability databases and additional security testing. The appropriate checks should therefore be risk based rather than identical for every dependency.
A Vulnerability in a Component Becomes a Finished-Product Issue
Article 13(6) requires a manufacturer that identifies a vulnerability in an integrated component, including an open-source component, to report the vulnerability to the person or entity manufacturing or maintaining the component and to address and remediate the vulnerability under Annex I Part II. Where the manufacturer develops a software or hardware modification for the component, it must share relevant code or documentation with the component maintainer where appropriate.
Component Vulnerability Handling Continues Through the Support Period
Article 13(8) requires vulnerabilities of the product, including its components, to be handled effectively during the support period. Manufacturers may also take the support periods of integrated third-party components that provide core functions into account when determining the product support period. Dependency selection therefore has long-term support consequences, not only release-time consequences.
The SBOM Belongs in the Technical Evidence Set
Annex VII places the SBOM within the information and specifications describing vulnerability-handling processes. The technical documentation must also describe system architecture and how software components build on, feed into and integrate with one another. A defensible CRA evidence set therefore connects the SBOM to architecture, risk assessment, testing, vulnerability handling and update records.
The CRA Does Not Generally Require Public SBOM Publication
Annex II states that if the manufacturer decides to make the SBOM available to the user, the user information must say where it can be accessed. This wording distinguishes drawing up the SBOM from publishing it to every user. Market surveillance authorities can request relevant SBOM information in specified circumstances, including where necessary to check Annex I compliance.
The Commission Can Further Specify SBOM Format and Elements
Article 13(24) allows the Commission to adopt implementing acts specifying the format and elements of the SBOM, taking account of European or international standards and best practices. Manufacturers should therefore avoid treating today's internal SBOM schema as permanently fixed and should maintain a process that can adapt if more detailed implementing rules are adopted.
Supply Chain Evidence Needs Version and Release Context
A useful CRA component record should link each dependency to the product version in which it appears, its source, version, supplier or maintainer, support status, known vulnerabilities, remediation decision and relevant security evidence. Without release context, an SBOM can show that a package exists but still fail to answer which customers or product versions are affected when a vulnerability emerges.
Open Source and Commercial Components Need Different Evidence Paths
Commercial components may provide supplier contracts, conformity information, security advisories and support commitments. Open-source components may instead rely on repository provenance, maintainer activity, release history, vulnerability databases and internal testing. The CRA due-diligence objective applies across both types, but the evidence used to demonstrate reasonable component selection and monitoring can differ.
Component Governance Should Connect Engineering and Procurement
Engineering often knows which dependencies are technically used, while procurement knows which suppliers provide commercial components and contractual support. Product security and compliance need both views. A CRA-ready supply chain process should therefore connect dependency discovery, supplier assessment, licensing and provenance information, vulnerability monitoring and release approval rather than maintaining them in isolated systems.
A Practical CRA Supply Chain Control Set
For each product, maintain a component and dependency inventory, generate and version an SBOM, define component acceptance criteria, monitor vulnerability sources, identify component owners, track supplier and maintainer support, record remediation decisions and preserve evidence for technical documentation. Review the inventory whenever product releases, dependencies, build systems or suppliers change.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.