Cyber Resilience Act FAQ Component due diligence

The manufacturer must exercise due diligence when integrating third-party components so that those components do not compromise the cybersecurity of the product with digital elements.

Component due diligence goes beyond procurement paperwork. It supports the manufacturer's Article 13 duty to design, develop, and produce the product in line with the CRA's essential cybersecurity requirements. The due-diligence record should connect each security-relevant component to the product risk assessment, the checks performed, the accepted residual risk, and any mitigation or replacement decision.

No. Article 13(5) expressly includes components sourced from third parties, including free and open-source software components that have not been made available on the market in the course of a commercial activity.

The integrating manufacturer cannot skip due diligence because a dependency is non-commercial open source, predates CRA application, lacks CE marking, or is not itself placed on the market as a CRA product. Assess whether the component can affect the finished product's cybersecurity and choose proportionate checks before and after integration.

No. Recital 34 describes a risk-based approach: the appropriate level of due diligence depends on the nature and level of cybersecurity risk associated with the component.

In practice, a low-risk UI library and a privileged update agent should not receive the same review. Useful factors include whether the component processes sensitive data, exposes network interfaces, runs with elevated privileges, performs authentication or cryptography, is reachable from untrusted inputs, affects safety or availability, or provides a core function during the product's support period.

The CRA and Commission FAQ describe examples rather than a fixed checklist. Depending on risk, checks can include whether the component manufacturer has demonstrated CRA conformity, whether the component bears CE marking, whether it receives regular security updates, whether known vulnerabilities appear in the European vulnerability database or other public vulnerability databases, and whether additional security tests are needed.

For software dependencies, the FAQ also points to software composition analysis, reviewing an available SBOM, checking the support period, confirming that the component's intended purpose fits the integrating manufacturer's use, and assessing the component manufacturer's security posture. For higher-risk components, the FAQ gives examples of additional testing such as fuzz testing, penetration testing, firmware analysis, side-channel analysis, red-team exercises, network traffic analysis, and sensor spoofing.

No. CE marking can be useful evidence when the component is itself a CRA product, but the CRA does not require manufacturers to integrate only CE-marked components.

Where a component bears CE marking, the integrating manufacturer may use the component's EU declaration of conformity and accompanying documentation as supporting evidence. Where CE marking is unavailable, for example because the component falls outside the CRA, predates CRA application, or has not been placed on the market, the integrating manufacturer must use other due-diligence evidence and mitigation measures.

Keep evidence that shows why the component was acceptable for the product's intended purpose and risk profile. Useful records include the component inventory entry, version and source, role in the product architecture, privilege and data-flow notes, known-vulnerability search results, security-update history, support-period information, SCA output, SBOM review notes, supplier security documentation, conformity or assurance documentation, test results, mitigation decisions, and approvals for exceptions.

The Commission guidance adopted in July 2026 says evidence may include documentation obtained from the component manufacturer, such as technical specifications, security documentation, and relevant conformity or assurance documentation. The CRA also requires technical documentation to contain vulnerability-handling process information, including the SBOM where applicable, and to be continuously updated where appropriate during the support period.

No. The CRA requires manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the product's top-level dependencies. It also requires technical documentation to include the SBOM where applicable.

That does not mean the SBOM must be made public. Recital 77 says manufacturers should not be obliged to make the SBOM public, and Annex II only requires user information on where the SBOM can be accessed if the manufacturer decides to make it available to users.

The manufacturer must handle the risk for its own product and report the vulnerability upstream to the person or entity manufacturing or maintaining the component. If the manufacturer develops a software or hardware modification to address the vulnerability in that component, it must share the relevant code or documentation with the component manufacturer or maintainer and, where appropriate, use a machine-readable format.

The adopted Commission guidance narrows the upstream-reporting duty to the version of the component actually integrated and to vulnerabilities that exist in the integrated component itself. It does not require upstream reporting where the component no longer has a maintainer, or where the manufacturer has made an independent fork and no longer relies on the original maintainer for new versions or security fixes. The adopted guidance also says manufacturers need not submit a duplicate upstream report where they can confirm that the manufacturer or maintainer already knows of the vulnerability. Check public vulnerability records, project security advisories or established issue trackers and retain that confirmation; the finished-product remediation duty continues.

It can rely on it as part of the response, but not as a complete substitute for its own obligations. If the component was placed on the market after the CRA applies, the component manufacturer may itself have vulnerability-handling obligations, which can help the integrating manufacturer remediate the finished product.

The integrating manufacturer still has to meet the vulnerability-handling obligations for the product as a whole. If the component is not supported by its developer, was not placed on the market, or was placed on the market before CRA application, the integrating manufacturer may need to disable the compromised function, replace the component, develop its own patch, or use another suitable mitigation.

No, not by itself. The Commission guidance adopted in July 2026 says manufacturers that integrate FOSS components do not become responsible for those components' individual CRA compliance merely because they contribute source code to their maintenance.

The status of the FOSS component depends on whether the entity that publishes it places it on the market and has responsibility for it. The integrating manufacturer remains responsible for its own product, must perform Article 13(5) due diligence on the FOSS component, and must report component vulnerabilities and share security fixes upstream where Article 13(6) applies.

The adopted Commission guidance treats certain third-party services like components when the service is necessary for the product to perform one of its functions but is not designed or developed by the manufacturer or under its responsibility.

For those services, the manufacturer should include the integration risks in the cybersecurity risk assessment, mitigate them through product-level controls, and carry out due diligence on the third-party solution. The guidance gives examples such as SaaS customer support chat, PaaS notification environments, and SaaS storage services used by an e-reader product.

No. The adopted Commission guidance distinguishes integrated third-party components from mere communication or connectivity enablers.

For example, it says a cellular network used by a smartphone for connectivity should not be treated like a third-party component where no software from the network provider is integrated into the product. The network reliance can still matter for the product risk assessment, but Article 13(5) component due diligence is not aimed at every external service the product communicates through.

Yes. The support period of third-party integrated components that provide core functions is one factor a manufacturer may take into account when determining the support period for its own product.

The support-period evidence should therefore identify core-function dependencies, their support status, and what the manufacturer will do if a supported product depends on an integrated component whose own support ends. The Commission FAQ explains that if a product with an active support period contains a vulnerability in an unsupported component, the manufacturer may need to switch out the component, develop a patch autonomously, or use another adequate mitigation.

First identify the exact component, version, source, maintainer, function, privileges, interfaces, and data access. Next rate its product impact and exposure, check known vulnerabilities and update history, review available SBOM and conformity or assurance evidence, confirm the intended use and support period, and run additional tests where the risk warrants them.

Then record the decision to accept, mitigate, isolate, replace, or reject the component. Assign an owner for vulnerability monitoring and define what happens if a new vulnerability appears or upstream support ends. Re-run the review when the component version, product use, threat exposure, maintainer, or support status changes. This sequence is Sorena's explanatory synthesis of the CRA's risk-based duty, not an official mandatory form.

No. The CRA requires a risk-based due-diligence process that prevents integrated components from compromising the finished product. It does not create a requirement to prove that every component has no vulnerabilities in every possible context.

A defensible record should instead show the component's role, known vulnerabilities checked, risk relevance to the product, mitigations applied, remaining risk accepted, and the process for monitoring new vulnerabilities during the support period.