Skip to content

Article 13(5) Due diligence in the scope of the CRA#

The European supranational or community law of product liability does not offer a clear and simple definition of "due diligence", though the requirement is often found, and the concept is well defined in a general sense. Legal usage of the phrase dates back to at least the early modern period and has been part of the language of legal duty ever since. Perhaps it's this long and varied usage that means there's no easy definition of due diligence under the Cyber Resilience Act (CRA), as the term can have very different meanings in very different contexts. Additionally, legal due diligence is almost always fact and circumstance based, creating a duty of care for the party performing it.

For the purpose of CRA compliance due diligence can only be understood within the context and from the language of the Act itself. Due Diligence is first mentioned in Recital 21 of the CRA and codified as a duty of manufacturers in Article 13(5) as follows:

"For the purpose of complying with paragraph 1 [the duty of secure design and development], manufacturers shall 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 when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity"

Note: this current version of the whitepaper focuses on due diligence as it is required by article 13(5) of the CRA. The ORC WG is in the process of clarifying the continuity and scope of due diligence in issue #5 and #14.

Article 13(5) due diligence is the process by which manufacturers can demonstrate that the integration of a new component does not compromise the security posture of the final product, a demonstration that is becoming increasingly critical under the CRA. The details of exactly how to accomplish this are less clear, though ultimately they come down to the manufacturer knowing the details of the components their product contains, making sure they are fit for the product's security requirements, and allowing the manufacturer to take action to mitigate any known exploitable vulnerabilities.

The implementation of an article 13(5) due diligence process necessitates the consideration of three key elements, which align with the CRA's focus on security throughout the product lifecycle:

  • Visibility: The ability to analyse the component. The availability of a A Software Bill of Material (SBOM) of the product is typically instrumental in achieving this objective, as the CRA emphasises the need for transparency and documented evidence regarding the security properties of product components.
  • Vigilance: The CRA mandates continuous compliance, so a manufacturer must ensure they have the ability to monitor for existing vulnerabilities essential to understand the level of exposure they assume upon integration of a component. This ongoing vigilance is a core requirement for maintaining a secure product over its expected lifetime, so a manufacturer must ensure via article 13(5) due diligence that they can have sufficient vigilance.
  • Maintenance: The level of community activity is an important factor for determining the risk profile that a particular component introduces to a product. A poorly maintained component represents a higher risk of unpatched vulnerabilities, which directly conflicts with the CRA's requirement for manufacturers to ensure the timely and effective handling of security updates.

The CRA requires the article 13(5) due diligence to be done at the integration time of 3rd party components, including open source components to the products, and throughout the product's lifecycle. Due diligence should be done for all releases of a product in the product lifecycle. The application of the principle of article 13(5) due diligence with respect to open source should be understood as an obligation to manage the risk of using any third-party component plus the responsibility to assess the open source component's risks yourself. Open source constitutes a vast and diverse ecosystem, ranging from massive, professionally supported projects to small, volunteer-maintained repositories. This inherent diversity, in terms of community activity, maintenance practices, and documentation quality, presents a fundamental challenge to consistently and accurately assessing the three key article 13(5) due diligence elements (Visibility, Vigilance, and Maintenance) required under the CRA.

Even if the specific requirements of article 13(5) due diligence under the CRA have yet to be offered by the European Commission or courts, it is possible to make several educated guesses about how it will work.

  1. CRA article 13(5) due diligence applies to 3rd party components of a product, including components that are also part of a Remote Data Processing Solution.
  2. The primary purpose and test of successful due diligence is that the completed product meets Annex I's essential cybersecurity requirements and that the manufacturer performs elements of vulnerability handling impacted by components and the product supply chain, such as the creation of an SBOM.

Note: This 2nd point depends on the interpretation of the scope of due diligence discussed in issue #14 and will be updated once the issue is resolved.

In the future, the European Commission may establish specific requirements on article 13(5) due diligence, including or as part of a voluntary security attestation program established via a delegated act as provided for in Article 25. Currently, however, specifics remain elusive.

Beyond these basic duties, the CRA and related Commission publications have offered additional clarifications regarding article 13(5) due diligence. The most significant of these is found in Recital 34 of the CRA where the Act notes several potential methods of performing the non-attestation parts of article 13(5) due diligence on 3rd party components:

  1. Verifying that the component demonstrates conformity with the CRA, such as by using CE marked components.
  2. Verifying that the component regularly receives security updates.
  3. Verifying that the component is free from vulnerabilities registered in the European shared vulnerability database created by the NIS2 Directive (EU Directive 2022/2555) or other publicly available vulnerability databases.
  4. Performing security tests on the component.