CRA Third-Party Component Due Diligence Guide

CRA third-party component due diligence means that a manufacturer cannot treat an integrated library, package, firmware module, hardware component or open-source dependency as somebody else's cybersecurity responsibility. Article 13(5) of Regulation (EU) 2024/2847 requires manufacturers to exercise due diligence when integrating third-party components so that those components do not compromise the cybersecurity of the product with digital elements. A practical implementation therefore needs evidence of how components were selected, assessed in the product context, monitored, updated and handled when vulnerabilities are found.

The Cyber Resilience Act (CRA) does not prescribe one universal supplier questionnaire or a fixed evidence pack for every component. The appropriate depth of due diligence depends on the component and its cybersecurity risk. The useful operating model is risk-proportionate: keep enough evidence to explain why a component was accepted, what assumptions support that decision, how it is tied to particular products and releases, and what will trigger reassessment.

What Article 13 requires for third-party components

The legal requirement begins during product design and development. Article 13(5) states that manufacturers must exercise due diligence when integrating components sourced from third parties, including free and open-source software that has not been made available on the market in the course of a commercial activity.

The European Commission's CRA summary makes the responsibility boundary clear: where the manufacturer integrates third-party components, it needs to exercise due diligence so those components do not compromise the cybersecurity of its product. The Austrian Federal Chancellery's CRA FAQ likewise explains that the manufacturer's cybersecurity risk assessment starts during design and development and includes risk assessment when selecting third-party manufacturer components.

Recital 34 gives useful examples of what risk-proportionate due diligence may consider. Depending on the component, a manufacturer can examine one or more of the following:

whether the component manufacturer has demonstrated CRA conformity, where that is applicable, including whether the component bears CE marking;
whether the component receives regular security updates, including its update history;
whether known vulnerabilities are recorded in the European vulnerability database or other public vulnerability databases; and
whether additional security testing is appropriate.

These are examples, not a mandatory four-step checklist for every dependency. A small, isolated library with limited privileges may justify a different level of scrutiny from a remotely reachable authentication component, privileged update agent or safety-relevant embedded module.

The diligence obligation also continues after integration. Article 13(6) requires a manufacturer that identifies a vulnerability in an integrated component, including an open-source component, to report it to the person or entity manufacturing or maintaining the component and to address and remediate the vulnerability in accordance with the vulnerability-handling requirements in Annex I Part II. Where the manufacturer has developed a software or hardware modification to address the component vulnerability, relevant code or documentation must be shared with the component manufacturer or maintainer where appropriate.

Due diligence should follow product risk, not supplier size

A supplier's size, brand recognition or procurement status does not by itself establish that a component is safe for a particular product. Due diligence should start with the role the component plays in the product and the consequences if that component fails or is compromised.

For each material component, assess questions such as:

What product function does the component provide?
What privileges does it have at runtime?
Does it process untrusted or network-originated input?
Is it reachable across a trust boundary?
Does it participate in authentication, authorisation, cryptography, updates or boot integrity?
What sensitive data or important product functions could it affect?
Can the component be isolated, disabled, replaced or updated independently?
What happens if its maintainer stops issuing security fixes?
How long is the component expected to remain supported compared with the product's own support period?

The answers determine the assurance effort. A component that can execute with high privileges and receives untrusted input may justify a deeper review of provenance, update history, known vulnerabilities, architecture and security testing. A low-impact component may justify a lighter record if the product risk assessment supports that conclusion.

Do not turn this into a score with no rationale. The evidence should show why the selected depth of review is proportionate to the product-specific risk.

Create a component record before approving integration

A durable due-diligence process starts with an identifiable component record. The purpose is not to duplicate every field in an SBOM. It is to preserve the facts and decisions needed to understand why the component was accepted and where it is used.

A practical record can include:

Identity: component name, version, supplier or project, source location and stable identifiers, so the team can identify exactly what was assessed.
Product context: product, variant, release family, function, privileges and exposed interfaces, connecting component risk to the product that integrates it.
Provenance: acquisition source, integrity or authenticity checks and relevant supplier information, supporting confidence that the assessed component matches the integrated one.
Support signals: maintainer status, support policy, security-update history and expected support horizon, showing whether vulnerabilities can realistically be remediated during the product lifecycle.
Known vulnerabilities: relevant vulnerability database checks, supplier advisories and findings, establishing the known security state at the time of the decision.
Risk decision: product-specific exposure, impact, assumptions, controls and acceptance rationale, separating component presence from product risk judgement.
Verification: additional review or testing performed where proportionate, providing evidence that important assumptions were checked.
Ownership: internal owner, review date and reassessment triggers, making the record actionable after the initial integration.

This is an implementation model, not a claim that the CRA mandates these exact fields. The regulatory objective is that third-party integration does not compromise product cybersecurity and that relevant cybersecurity aspects are systematically documented in a manner proportionate to the product's risks.

Evaluate support and security signals before integration

A component's current vulnerability count is only one part of due diligence. A component with no publicly known vulnerabilities may still be a poor choice if it has no active maintainer, no credible update mechanism or an unclear provenance chain.

Security-update history

Review whether the supplier or maintainer responds to security issues and publishes updates. If the product is expected to be supported longer than the component, document the mitigation. Options may include a replacement plan, internal maintenance capability, isolation of the component or another update source. Article 13(8) allows the manufacturer's support-period determination to take into account the support periods of third-party products with digital elements and integrated components that provide core functions.

Known-vulnerability information

Check appropriate vulnerability sources and supplier advisories before integration and during the lifecycle. Recital 34 explicitly mentions the European vulnerability database and other publicly accessible vulnerability databases as possible due-diligence inputs.

A database match is a signal for investigation, not an automatic product-impact conclusion. Version identifiers may be ambiguous, vulnerable code paths may not be present, and product configuration matters. Record the affected or not-affected reasoning separately from the raw match.

Conformity information where applicable

Where a third-party component is itself subject to the CRA and the relevant obligations apply, evidence such as demonstrated conformity or CE marking can be one input. It should not be treated as a universal requirement for every dependency or as a substitute for the manufacturer's own product-context assessment.

Recital 35 recognises that manufacturers may integrate components first made available before the CRA requirements became applicable and for which checking conformity may not be possible. In such cases, use other appropriate means of due diligence rather than treating the absence of CRA conformity evidence as the end of the analysis.

Additional security testing

For components that materially influence product risk, additional testing may be proportionate. Depending on the technology, this could include interface tests, malformed-input testing, configuration review, dependency analysis, update verification, targeted code review or penetration testing. The CRA does not prescribe one universal test stack for all third-party components.

Apply the same responsibility boundary to open-source components

Free and open-source software developed or supplied outside a commercial activity can fall outside the normal manufacturer obligations for placing a product on the market. That does not remove the responsibility of a manufacturer that integrates the software into its own product. Article 13(5) explicitly includes free and open-source components that have not been made available on the market in the course of a commercial activity.

The practical implication is straightforward: do not demand evidence from a volunteer project as if it were necessarily an economic operator under the CRA, but do not treat the absence of a commercial supplier as a waiver of your own integration assessment either.

For an open-source component, useful evidence may include:

the exact project and version or commit integrated;
the authoritative repository or distribution source;
release and security-update history;
known vulnerabilities and security advisories;
maintainer activity and available vulnerability-reporting channels;
the product's exposure to the component's functionality;
internal tests or compensating controls where the risk justifies them; and
the plan for updating, replacing or maintaining the dependency if upstream support changes.

ENISA's 2026 technical advisory on secure use of package managers is useful implementation guidance for software dependencies. It focuses on risks from third-party packages and secure practices for selecting, integrating and monitoring them, including how to address vulnerabilities found in dependencies. It is operational guidance, not a replacement for the CRA legal text.

Connect component diligence to the cybersecurity risk assessment

Third-party due diligence should not live in a procurement spreadsheet that never reaches product engineering. Article 13 links component integration to the manufacturer's broader cybersecurity risk assessment and product lifecycle.

A component assessment should connect to the product risks it can create or influence. For example, if a library parses network-originated data, the product risk assessment should show the relevant threat scenario, exposure and treatment. If a hardware module protects a security boundary, the assessment should capture the consequences of compromise and the verification used to support reliance on that module.

A useful traceability chain is:

component identity -> product/release context -> security role -> threat or risk -> due-diligence evidence -> integration decision -> verification -> lifecycle monitoring

This avoids two common errors. The first is supplier-only diligence, where a vendor questionnaire is completed but nobody evaluates how the component is used. The second is architecture-only diligence, where engineers understand the risk but the decision is not retained in a form that can later support technical documentation and vulnerability handling.

Use the SBOM as inventory evidence, not as the due-diligence decision

The CRA requires manufacturers, as part of vulnerability handling, to identify and document vulnerabilities and components, including by drawing up a software bill of materials (SBOM) in a commonly used and machine-readable format covering at least top-level dependencies.

An SBOM is a strong starting point for third-party governance because it records component identity and relationships. It does not, by itself, show why a component was selected, whether its support horizon is adequate, whether a known vulnerability affects the product, what additional tests were performed or who accepted the residual risk.

Keep the inventory and the decision connected. For each supported release, a security team should be able to move from the release-specific SBOM or component record to the product-risk decision, vulnerability history, remediation evidence and current support status without reconstructing the dependency from memory.

Monitor the component after release

Due diligence is not complete when the integration pull request is merged. Article 13 requires manufacturers to systematically document relevant cybersecurity aspects, including vulnerabilities they become aware of and relevant information provided by third parties, and to update the cybersecurity risk assessment where appropriate.

During the support period, the operating process should be able to:

receive vulnerability and security-update information from suppliers, maintainers, researchers and public sources;
identify which supported products and releases contain the component;
determine whether the reported issue affects the product context;
update the risk assessment where the new information changes the security picture;
inform the component manufacturer or maintainer when the manufacturer identifies a vulnerability in the integrated component;
select and verify a fix, backport, mitigation, replacement or other treatment;
release the remediation through the product's normal security-update process; and
preserve the evidence behind each decision.

If the manufacturer develops a modification that addresses the third-party vulnerability, Article 13(6) also requires relevant code or documentation to be shared with the component manufacturer or maintainer where appropriate. Build that coordination step into the vulnerability workflow rather than relying on ad hoc developer outreach.

A practical component due-diligence checklist

For each component that can materially affect product cybersecurity, verify that the team can answer the following questions with retained evidence:

What exactly is the component? Record the supplier or project, version and authoritative source.
Where is it used? Link the component to exact products, variants and supported releases.
What security role does it have? Document privileges, exposed interfaces, sensitive data and important functions.
What product risk can it create? Connect the component to relevant threat scenarios and the cybersecurity risk assessment.
What security and support signals were checked? Retain relevant update history, vulnerability information, conformity evidence where applicable and maintainer status.
What extra assurance is justified? Record additional review or testing where the risk warrants it.
Why was integration accepted? Preserve the decision, assumptions, controls, owner and date.
How will vulnerabilities reach the team? Define supplier, maintainer, database or monitoring inputs.
How can affected releases be found? Keep component identity connected to release-specific SBOM and lifecycle records.
What happens when a vulnerability appears? Define assessment, maintainer coordination, remediation, verification and update steps.
What happens if support ends? Record replacement, internal maintenance or other treatment before the dependency becomes an unmanaged lifecycle risk.
What triggers reassessment? Include component upgrades, architecture changes, new vulnerabilities, support changes and material changes in product exposure.

The checklist is most useful when it points to real records rather than producing another standalone document.

Keep the evidence connected to the release

Third-party due diligence becomes difficult to defend when the component inventory, risk decision, vulnerability work and release evidence live in separate systems and drift as the product changes. AA-sec is designed around traceability between SBOM and component context, vulnerability work, security evidence, decisions and exact product or lifecycle context, which can help keep that record connected over time. The manufacturer still owns the component-selection, engineering-risk and CRA conformity decisions.

Key takeaway

CRA third-party component due diligence is a lifecycle control, not a one-time supplier check. Manufacturers need a risk-proportionate process that evaluates a component before integration, ties the decision to the product cybersecurity risk assessment, preserves the component's exact release context, monitors support and vulnerabilities, coordinates remediation with suppliers or maintainers, and keeps the resulting evidence available throughout the support period.

For implementation, start with one security-relevant dependency. Trace it from source and version through the product risk assessment, SBOM, integration decision, vulnerability monitoring and update process. Any point where the team cannot show the component, decision, affected release or supporting evidence is a gap to fix before scaling the model.

Official sources

Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
The Cyber Resilience Act - Summary of the legislative text — European Commission
ENISA Technical Advisory for Secure Use of Package Managers — ENISA
Fragen und Antworten zur Cyberresilienz-Verordnung — Bundeskanzleramt Österreich