Due diligence for third-party components

Due diligence for third-party components is set out in Article 13(5) of the Cyber Resilience Act (CRA). Manufacturers must 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. Free and open-source software that has not been made available on the market in the course of a commercial activity is expressly covered.

The paragraph opens with the words “For the purpose of complying with paragraph 1”. Diligence is therefore not an end in itself but the means by which a manufacturer meets the essential cybersecurity requirements for the parts it did not write. The kind of component makes no difference. The wording draws no line between software and hardware, and Article 13(6) speaks explicitly of a software or hardware modification.

Four checks recital 34 names

The enacting terms say that diligence is owed, not what it consists of. Recital 34 fills that gap. It names four actions, one or more of which should be taken into account depending on the situation. None of them is mandated as such, because a recital is not an enacting provision:

• verifying, as applicable, whether the manufacturer of a component has demonstrated conformity with the CRA, including by checking whether the component already bears the CE marking
• verifying that the component receives regular security updates, for instance from the ones released so far
• verifying that the component is free from vulnerabilities registered in the European vulnerability database or in other publicly accessible databases
• carrying out additional security tests

The yardstick comes from the same recital. The appropriate level of due diligence depends on the nature and the level of cybersecurity risk associated with a given component. A library that formats dates and a TLS stack therefore do not warrant the same depth of scrutiny.

No inventory, no diligence

Only what is known can be checked. Annex I, Part II, point 1 accordingly requires manufacturers to identify and document the vulnerabilities and components contained in the product, including by drawing up a Software Bill of Materials (SBOM) in a commonly used, machine-readable format. The scope it names is “at the very least the top-level dependencies”.

Those words are meant literally. The top level is the floor for the bill of materials, not the ceiling of the diligence obligation. For diligence itself the CRA states no depth at all. Depth follows risk, and risk frequently sits in a library that reaches the product only two hops down.

What a finding sets in motion

Article 13(6) governs the case where a manufacturer identifies a vulnerability in an integrated component. Three steps then belong together:

• report the vulnerability to the person or entity manufacturing or maintaining the component
• address and remediate it in line with the vulnerability handling requirements in Annex I, Part II
• share the relevant code or documentation with that person or entity where a software or hardware modification was developed, in a machine-readable format where appropriate

The third step is the notable one. It obliges a manufacturer to hand a self-developed fix back upstream instead of keeping it inside its own product. Diligence accordingly does not stop at the design phase. Under recital 34 the vulnerability handling obligations apply to the product in its entirety, including every integrated component, both when it is placed on the market and across the whole support period.

The open-source special case

With free and open-source software, the usual supply chain logic breaks down. Anyone integrating a library that was never supplied commercially has no counterparty to pass a requirement to, and as a rule no declaration of conformity to inspect. Article 13(5) nevertheless pulls that case squarely into the obligation.

Article 25 is the answer to it. It empowers the Commission to establish voluntary security attestation programmes by delegated act, allowing developers, users and other third parties to assess the conformity of open-source products. The Article does not create those programmes, it only permits them. Until one exists, the assessment stays with the integrating manufacturer.

The CE gap of the early years

The first of the four checks will rarely help at the outset. The CRA applies from 11 December 2027, and under Article 69(2) products placed on the market before that date become subject to its requirements only once they undergo a substantial modification afterwards. Article 69(3) carves out only the reporting obligations in Article 14, which apply to every product within scope. Many integrated components will carry no CE marking under this Regulation for years.

Recital 35 says so openly: in such a case a manufacturer should exercise due diligence through other means. What those means are, the Regulation leaves open. In practice the other three actions remain, namely the security update history, the comparison against vulnerability databases and testing of your own.

Evidencing diligence

The CRA prescribes no dedicated documentation format for due diligence. Article 13(7) does require all relevant cybersecurity aspects of the product to be documented systematically and in a manner proportionate to the nature and the cybersecurity risks, including vulnerabilities the manufacturer becomes aware of and any relevant information provided by third parties. Recording the checks component by component satisfies both at once.

There is a hard reason for the effort. Breaches of Article 13 fall into the upper penalty band under Article 64(2), which provides for fines of up to 15 000 000 EUR or, for undertakings, up to 2.5 % of total worldwide annual turnover for the preceding financial year, whichever is higher. Article 13(25) adds a second reason. It lets the Administrative cooperation group (ADCO) decide on a Union-wide assessment of dependency on software components for certain categories of products, and market surveillance authorities may then ask manufacturers in those categories to provide their software bill of materials.