Explain if due diligence is a continous activity or happens only at specific times

[CsatariGergely]

Copied from the Google Doc

[CsatariGergely]

CRA requires due diligence when the component is integrated suggesting a one time check

[CsatariGergely]

CRA requires due diligence when the component is integrated suggesting a one time check

Example: Manufacturer integrates a component from a “lively community”. Over the lifetime of the product the community turns dormant. Should manufacturers care, and if so how? Is this a requirement on due diligence?

[CsatariGergely]

CRA requires due diligence when the component is integrated suggesting a one time check

Example: Manufacturer integrates a component from a “lively community”. Over the lifetime of the product the community turns dormant. Should manufacturers care, and if so how? Is this a requirement on due diligence?

One time check per release of a product ensures that every release of a product contains open source components in "good health"

[jrico-eclipse]

CRA requires due diligence when the component is integrated suggesting a one time check

Example: Manufacturer integrates a component from a “lively community”. Over the lifetime of the product the community turns dormant. Should manufacturers care, and if so how? Is this a requirement on due diligence?

One time check per release of a product ensures that every release of a product contains open source components in "good health"

Yes, the manufacturer is responsible of monitoring the security posture of the product during the whole lifecycle. The risk analysis should consider this kind of scenarios, and the impact this situation may create on the product. Indeed I'd like to propose as one of the outcomes of our work, a suggestion manufacturer posture based on the criticality of the open source component they are integrating, and its support to demonstrate CRA obligations alingment.

[CsatariGergely]

Based on our discussion on the ORC WG meeting on 2026.06.04 my view is that yes due diligence should be carried out during the whole product lifecycle, but should be triggered when the component is integrated to the product or when there is a new release of the product is released.

[markt-asf]

There are two readings of Article 13, para 5. "... manufacturers shall exercise due diligence when integrating
components sourced from third parties ...".

The first reading is that the "when" means "at the instance in time of". That leads to the conclusion that due diligence only happens at the point of integration.

The second reading is that "when" means "if". That leads to a broader requirement for due diligence.

Given that overall intention of the CRA, it seems likely that the intention is that after integration of a 3rd party component, manufactures should monitor that component to ensure that it is is not compromising the cybersecurity of the product (e.g. because a vulnerability has been found that affects the product or that the component has become unsupported) and take appropriate action.

I do not think it is sufficient for a release to be the trigger for due diligence. Due diligence should be an ongoing process and it should be possible for due diligence to trigger a release.

[timop62]

While dicussing PR #9, arguments have been made supporting 3rd party component due diligence being continuous activity as well as for not continous/only at integration time activity manufacturer shall carry out. Both the law and the draft guidance seem to leave room for interpretation that leads to either conclusion.

We also have additional material to consider.
CEN/CENELEC JTC13/WG9 has developed a draft horizontal standard for CRA "Cybersecurity requirements for products with digital elements - Principles, product risk management, and lifecycle activities", a.k.a. JT013089 or prEN 40000-1-2.

In this document they have chapter 7 "Product cybersecurity lifecycle activities". 7.10 discusses "Third-party component cybersecurity management". In this section they define a requirement CLA-10-RQ-01:  "Due diligence shall be performed for third-party components during the selection and prior to the integration into products, and shall include, where applicable, the following activities: [goes on to list various activities that would lead to demonstarting due diligence]".

Further, chapter 7.5 "Secure implementation" explains that "Secure implementation activities ensure the development of secure product meets the previously defined cybersecurity requirements from [ref], as per the cybersecurity architecture and design from [ref], incorporating the cybersecurity controls."
As input to the secure implementation phase of the product development they provide prerequisite in 7.5.2 "Input". Among other things they go on and list "documentation relating to the due diligence activities of third-party components to be implemented and integrated into the product from 7.10". Which would strongly indicate due diligence happens prior to integrating 3rd party components.

Although the draft addresses "lifecycle activities" as the title suggests, it does not refer to due diligence anywhere else than in those sections. Leading the reader to conclude due diligence takes place at the selection phase of 3rd party component, before deciding to integrate the component to the product being implemented.

I think it is not good, if we in ORC conclude totally differently from the draft standard what the nature of due diligence is. Especially as the draft has undergone scrutiny by the Commission and the HAS consultant, leading one to assume what is written about due diligence is not incorrect.

[jrico-eclipse]

Hi @timop62 and all,

I agree that we should not diverge from the current approach, it is quite high-level and gives us room for entering into implementation details for the open source components. I see open areas like:

• Role of attestations
• How to map risk assessment results for a product, into specific parameters that can be checked in a FOSS project.

I can confirmed that I've asked the EC for feedback on whether due diligence is continuous or somehting to execute during the first integration of a component.

My final point, is that I propose to start focusing on phases:

• Product development - integration of components to put it on the market.
• Continuous compliance - how to handle the product when it is in the market to maintain it compliant with the law.
• Vulnerability management - evaluate whether the CEN/CENELEC current Standard for that works for the open source communities.

[timop62]

I like the proposal to take the work ahead of us in phases as outlined by Juan, focus on well defined tasks instead of trying to cover all necessary manufacturer obligations (or best practices) on one go. I believe in this way we will be able to tackle scope creep and ensure we will accomplish something that will be useful for manufacturers.

Then something off topic regarding Vulnerability Management. I would like to draw your attentions to the fact that the draft Juan refers to ("Cybersecurity requirements for products with digital elements - Part 1-3: Vulnerability Handling") in its current draft refers to "open source maintainers" as something manufacturers should have communication channel with when dealing with vulnerabilities found in open source manufacturer has integrated to their product.
To me it would be good if ORC participants who have access to the draft would take a look. I'd like us to discuss this and conclude if there's a need to propose changes to the draft in this regard, or if we conclude it is just fine as it is.