Due diligence for third-party components
Hardly any product consists only of its maker's own code. For everything built in, the manufacturer has a duty of due diligence: check, monitor, and report any flaws found back to the source.
Due diligence for third-party components is the manufacturer's obligation to check bought-in and open-source components so that they do not compromise the cybersecurity of its own product. It expressly also applies to non-commercial open-source software.
Definition in the Regulation
Article 13(5) of Regulation (EU) 2024/2847 requires manufacturers to "exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements", including free and open-source software. Recital 34 lists possible measures, scaled to the risk: checking for the CE marking, looking at the security update history, checking against the European vulnerability database or other publicly accessible databases, and additional security tests. Article 13(6) adds the obligation to report back: if the manufacturer finds a vulnerability in a component, it reports it to the component's manufacturer or maintainer, remediates it itself and shares its own fixes, where appropriate in a machine-readable format. Under Article 7(1), an integrated component does not by itself make the overall product an important product; it does, however, have to be taken into account as part of due diligence.
What it means for manufacturers
In practice, due diligence starts with an inventory: the software bill of materials (SBOM) lists what the product contains and is continuously checked against vulnerability databases. Firmware from suppliers should not be accepted without its own bill of materials. If you use open-source components, check whether the project is maintained, and contribute your own fixes back rather than keeping them in-house. According to specialist commentary on the Commission guidance, the integrating manufacturer does not become responsible for the conformity of the component itself, but it bears full responsibility for the end product. A match in a database does not yet trigger a reporting obligation; that only arises when the vulnerability is actively exploited in your own product.
Free templatesCRA Reporting KitReporting playbook, awareness record, notification templates for the ENISA platform, call chain and deadline calculator. Six Word templates, two Excel workbooks and a handbook, free by e-mail.Request the kitRelated terms
- Software bill of materials (SBOM)
- Free and open-source software
- Cybersecurity risk assessment
- Vulnerability