Adding the seed of Chapter 1

[CsatariGergely]

Chapter 2 in the Google Docs
https://docs.google.com/document/d/1_IpLqgWogDNGzN4J51L1pXQv0GsCYR4xPdn-BwXVBrk/edit?pli=1&tab=t.em8fjxfncrmt

The original text contains the "Responsivenes" element also, what I did not add to the pr.

I think Responsiveness is not a due diligence requirement, but a vulnerability management one. Even though it is an important requirement for vulnerability management I would leave it out from this whitepaper.

Let's discuss how others see it.

[jrico-eclipse]

LGTM

[markt-asf]

I think we should keep responsiveness. Due diligence is broader than vulnerability management. There are things that could happen outside of the scope of vulnerability management (e.g. a product becomes unsupported) that should be detected by due diligence and need a response.

[CsatariGergely]

I think we should keep responsiveness. Due diligence is broader than vulnerability management. There are things that could happen outside of the scope of vulnerability management (e.g. a product becomes unsupported) that should be detected by due diligence and need a response.

By the definition of the CRA due diligence is happening when the component is integrated to the product "manufacturers shall exercise due diligence when integrating components sourced from third parties" (Article 13.5). It is not continuous in a sense that it happens "all the time", but it is happening at distinct times when the integration happens. To facilitate some kind of continuity it is possible to have the interpretation that all the components are "re-integrated" in every release of a product, what would mean that the due diligence is re-checked for every product version. Also naturally if a new version of the same open source component is integrated that also triggers the due diligence. This is what we agreed on the meeting on 2026.06.04.

I will propose a text to cover this in the chapter.

[markt-asf]

I strongly disagree with that interpretation of Article 13.5. That is the "...when..." means "...at the point in time...". I think that is the wrong interpretation since it means a manufacturer can integrate a 3rd party component and then ignore any issues with that component until the manufacturer decides to make a new release. That is the wrong way round. Manufacturers should be monitoring (as part of due diligence) the components they use for things like the component being declared end of support. I expect due diligence of 3rd party components to trigger releases. I think the correct interpretation of "...when..." in Article 13.5 is "...if...".

[CsatariGergely]

I strongly disagree with that interpretation of Article 13.5. That is the "...when..." means "...at the point in time...". I think that is the wrong interpretation since it means a manufacturer can integrate a 3rd party component and then ignore any issues with that component until the manufacturer decides to make a new release. That is the wrong way round. Manufacturers should be monitoring (as part of due diligence) the components they use for things like the component being declared end of support. I expect due diligence of 3rd party components to trigger releases. I think the correct interpretation of "...when..." in Article 13.5 is "...if...".

Good discussion. BTW we planned to have a chapter only about this but I forgot to add it to the original skeleton. Here is a pr to fix that: #10

My interpretation is different. I think CRA uses "when" consistently to refer to points in time. Maybe this requires some wider discussion to determine.
I do not think that manufacturers can ignore any issues even if the due diligence is done only at integration time.
I think this is when the vulnerability process kicks in. Manufacturers need to update the open source components if problems are found as part of the vulnerability management process.

[markt-asf]

Vulnerabilities are only one of the things that could trigger manufacturer action. If there isn't ongoing due diligence, what triggers manufacturer action for things like a component being declared end of support (assuming there was no EOS information published at the time of integration)?

[CsatariGergely]

Vulnerabilities are only one of the things that could trigger manufacturer action. If there isn't ongoing due diligence, what triggers manufacturer action for things like a component being declared end of support (assuming there was no EOS information published at the time of integration)?

According to the CRA it is only the vulnerabilities which are triggering manufacturer action.
Article 13(1) clearly defines that the actions should be carried out when the product is designed, developed and produced. Article 13(5), which defines the due diligence requirement is an extension to Article 13(1), and does not add any requirements for doing due diligence at any other time than design, develop and produce.

I agree that it would be a good practice to continuously checking the due diligence, but I do not think that this is required by the CRA. I'm okay to add a note about a best practice for continuous or regular check or due diligence.

[August-Bournique]

A) Do we want to refer to any specific CRA sections here? E.g. 13(5)
B) I might rephrase this to focus on the ubiquity of integrated components. I would also mention that RDPS are a component and due diligence is required for them as well.

[CsatariGergely]

Please indicate to which lines are these comments valid.

[CsatariGergely]

I've merged #11 to here in f949e6f

I've left out some statements which had no consensus on the meeting, like that vulnerability management would be part of due diligence and that both Annex I and Annex II are relevant for due diligence.

These can be added later in case of a consensus reached.

[August-Bournique]

Just tried to add some edits to the recent revision (thanks Gergely!). Primarily these are cosmetic changes and typo corrections to my own writing, but I also included some clarifications regarding ongoing manufacturer duties regarding integrated components (and non components ... arrgh ... the guidance does complicate things a bit). These may not be Article 13(5) "due diligence", but likely are some form of due diligence ... as a general concept not a term of art here ... related to component integration.

As expressed in the last meeting by myself and others I think it's important to acknowledge and discuss ongoing manufacturer duties related to component integration. Article 13(6) can't be ignored, and in my opinion any pro-FOSS organization should be supporting it as much as possible because high quality security patches and ongoing manufacturer duties to component projects are I believe a benefit. Beyond this the risk of manufacturers ignoring ongoing duties towards integrated components is serious, as a component update can conceivably constitute a substantial modification of a product if it adds features or creates new security risks/functions. It would be benefit both manufacturers and integrated components to have awareness of this risk and even a duty to watch for it - which to me seems implied under 13(6).

Finally, I added a few bits regarding potential contractual forms of due diligence that are found in the RDPS section of the guidance and which seem helpful for commercial 3rd party component compliance where manufacturers lack access to direct testing and such. I also note that the vulnerability handling requirements for component integration don't seem to apply to non-RDPS services (which aren't components ... but still require due diligence)...

[CsatariGergely]

Thanks for the suggestions in #13 @August-Bournique .

It would be good if we could merge this pr first and then apply the changes on top of the main branch.
If you think the you are not okay to approve this pr without the changes proposed in #13 I can try to cherry-pick your commits from there on top of this, but it is a bit difficult process.

[gkunz]

Good conversation.

I believe it is useful in this conversation to recall that a risk assessment is at the core of CRA compliance. Thus, due diligence in the context of 13(5) means that the effect of a given third-party software component in the context of that risk assessment must be considered. This is a task that logically happens for the first time when a product team decides to use a component - because it is either suitable or not. It also needs to happen when a component is updated, for instance for a new release, since the risk profile may change (c.f. substantial modification). Note that a security update (of a component) is explicitly not considered a substantial modification.

The EC FAQ 4.4.2 supports this interpretation via the provided examples. They are all very much point-in-time assessments of the posture of a third-party component:

• checking if the component already bears the CE marking;
• verifying that a component receives regular security updates, such as by checking its security updates history;
• verifying in the European vulnerability database established pursuant to Article 12(2) of Directive (EU) 2022/2555 or other publicly accessible vulnerability databases the vulnerabilities applicable to a component and designing, developing and manufacturing the product with digital elements integrating the component in such a way that these vulnerabilities do not compromise the cybersecurity of the product with digital elements;
• carrying out additional security tests, such as fuzz testing, penetration testing, firmware analysis, side-channel analysis, red-team exercises, network traffic analysis, sensor spoofing.
  [...]
• checking the support period of the component;

This is supported by @CsatariGergely's observation that 13(5) explicitly refers to 13(1), which defines a scope of "design, develop, and produced". Note also that "designing, developing and manufacturing the product" is also repeated in the example above.

Taking into account that products have a release cadence, an end-of-life component should be noted and addressed after the EOL announcement during a future release, which is the result of "designing, developing and manufacturing the product". So, we are essentially saying the same thing: due diligence happens during design, development, and production when the product or the component changes.

This does of course not mean that the later lifecycle stages of a product are irrelevant, but these are covered by the vulnerability handling obligation as stated in 13(8) "[...] when placing a product with digital elements on the market, and for the support period, [...]".

Regarding the example of a component going end-of-life: the chances of not receiving security fixes for vulnerabilities is extremely high in this case, creating a risk of noncompliance to 13(8). So, a manufacturer is well advised to take action, for instance through finding a replacement - but also by finding other means of mitigating vulnerabilities in accordance with the risk profile of that product (e.g., firewalling, disabling the effected functionality, configuration hardening). But this is triggered by the obligation to meet the vulnerability management requirements - because it is vulnerabilities that have a dynamic impact on the cybersecurity of a product.

---

August mentions 13(6) - and I very much agree that a strong upstream capability is beneficial for CRA compliance (I gave some talks about this in the past). But I'd also claim that 13(6) is different from 13(5), i.e., they are two separate - but complementary - obligations and thus defined in two separate paragraphs. 13(6) mandates sharing vulnerability fixes whenever a manufacturer happens to develop one. Timewise, this is not tied to the due diligence checks listed above. A due diligence check can trigger 13(6), but similarly a fix of a reported and still unresolved vulnerability triggers 13(6), too. Yet this is different from 13(5).

---

So, now we are already covering three different paragraphs in this conversion. Recognizing my overly long comment, I am wondering if we should try to avoid scope creep.

[August-Bournique]

Georg,

I don't really disagree with anything you've said but I do think that we've more at risk of providing too narrow a scope to be useful.

I think it's best if we cover both 13(5) due diligence and the related requirements, some of which the EC has also labeled as "due diligence" in the guidance (specifically those related to supply chain). All of these relate to manufacturer duties towards components, or things that are treated very similarly to components and all relate to potential risks involving technology that the manufacturer does not have control over (i.e. doesn't own the IP or isn't performing the updates on). From my prospective where "due diligence" is a general legal term (e.g. I need to perform due diligence when checking for conflicts before signing clients), and one that has no clear meaning in EU product liability law more generally, it's entirely possible to describe almost all activities performed regarding integration as "due diligence" ... just not 13(5) due diligence. E.g. Reviewing integrated component updates (including those that don't risk triggering a substantial modification) to make sure that they don't introduce new security issues would be due diligence. Resulting upstreaming of fixes under 13(6) could be a result of this activity and so might be characterized as part of the CRA mandated due diligence necessary to FOSS component integration.

I note this sort of thing becomes more important for FOSS components where the ability to transfer liability and perhaps risk to component supplies via contract provisions (including perhaps the requirement that the supplier notify the integrator of specific risks created by updates). I also note that checking that the component has an update method is one of the suggested (not required, but an example) ways a manufacturer can perform 13(5) due diligence. To me it follows that keeping an eye on those updates is also a reasonable activity for a manufacturer. Perhaps those this is pulling towards the PLD a bit? Does it have any insight into the standard of care for component integration?

If instead we focus narrowly on 13(5) due diligence as a one time activity we risk giving potentially bad information by omission. Furthermore I don't think the requirements for vulnerability handling, 3rd party RDPS (if such a thing is possible), or non-RDPS services that perform product functions are especially complex. Indeed I suspect they are all either clearly provided for in the Act and guidance or require activities similar to those of 13(5) component integration.

[gkunz]

Hi August,

thanks for the feedback. To me, we are not very far apart in our respective interpretations - it probably comes down to deciding the scope and/or structuring the guidance we want to create.

We can try to align on the core question: I believe @CsatariGergely and I approached this from a perspective of "what kind of actions shall a manufacturer perform to validate that a component is suitable for use in a product?" This question is kind of close to the EC FAQ 4.4.2. The answer to this question would cover: What check to perform? When to perform them? What does the evidence of such a check look like? etc.

Your perspective is broader, including additional actions such as sharing fixes, vulnerability handling. The relevance of those for full CRA compliance is without doubt - those are articles and paragraphs in the CRA after all. They are just complementary to the questions I listed above.

In that light:

E.g. Reviewing integrated component updates (including those that don't risk triggering a substantial modification) to make sure that they don't introduce new security issues would be due diligence.

Agreed.

Resulting upstreaming of fixes under 13(6) could be a result of this activity and so might be characterized as part of the CRA mandated due diligence necessary to FOSS component integration.

This is one of the mandated complementary activities.

Perhaps those this is pulling towards the PLD a bit? Does it have any insight into the standard of care for component integration?

Yeah, let's cover one at time ... ;-)

Finally, going back to the EC draft guidance, point 156, states:

156: When assessing the risks to the product as a whole, elements outside of the product, such
as environmental elements, external infrastructure, other systems or networks, must be
considered in the cybersecurity risk assessment and, where relevant, addressed to ensure
that the essential requirements are implemented within the product itself. Components
that are physically or logically inside the product but supplied by a third party must also
be considered as part of the risk assessment. However, for compliance purposes these
are treated as external inputs whose external properties must be verified upon integration
through due diligence, as they cannot be re-designed or re-developed by the
manufacturer.

Note the last sentence, which implicitly scopes due diligence as a (re-)integration time verification activity.

[gkunz]

This looks good to me for merging and further updates as discussed (see #20).