EU Cyber Resilience Act FAQ Integrated Components and Dependencies

Under the CRA, an integrated component is a software or hardware component that forms part of the product with digital elements. A remote data processing solution can also form part of the product where it meets the Article 3(2) definition. Other outside systems or services may remain external dependencies rather than part of the product itself.

The consequence is different in each case:

- integrated components are part of the product and trigger due diligence under Article 13(5)

- remote data processing solutions that meet the CRA definition are also part of the product

- outside systems may remain external dependencies, but their risks still have to be considered in the cybersecurity risk assessment and mitigated through product-level measures

Yes.

The CRA places the compliance obligation on the manufacturer of the finished product. The Commission FAQ is explicit that vulnerability-handling obligations apply to the product in its entirety, including integrated components.

No.

The draft guidance treats them as distinct but complementary obligations. The cybersecurity risk assessment covers risks affecting the product, including risks originating outside the product. Due diligence under Article 13(5) is the additional obligation to verify, in a risk-based way, that third-party integrated components do not undermine the product's compliance.

It means taking appropriate, risk-based steps so that the integrated components do not compromise the cybersecurity of the product.

Recital 34 and the Commission FAQ give examples such as checking whether the component already bears the CE marking, checking whether it receives regular security updates, checking relevant vulnerability databases, and carrying out additional security tests where appropriate.

The Commission FAQ also lists practical due-diligence evidence that is useful for third-party software: software composition analysis, reviewing the component's SBOM when available, checking the component support period, verifying that the component's intended purpose fits the integrating manufacturer's use, and assessing the component manufacturer's security posture.

Yes, as part of vulnerability handling and technical documentation, but the CRA does not turn every SBOM into a public artifact.

Annex I Part II requires manufacturers to identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies. Annex VII also lists the SBOM as part of the vulnerability-handling information in technical documentation, and Annex II only requires user-facing access information if the manufacturer decides to make the SBOM available to users.

For integrated components, that means the useful compliance record is a maintained component inventory tied to vulnerability handling, support-period checks, update evidence, third-party documentation, and the risk assessment. The CRA grounding does not support saying that the full SBOM must always be published.

No.

The Blue Guide explains that CE-marked components do not automatically guarantee that the finished product also complies. In the CRA context, a CE-marked component can support the integrating manufacturer's assessment, but the integrating manufacturer still has to ensure that the finished product complies as a whole.

Yes.

The CRA does not require manufacturers to integrate only CE-marked components. Manufacturers can integrate components that are outside the CRA, that were placed on the market before the CRA applies, or that were never placed on the market as CRA products. But they still have to exercise due diligence and ensure that the finished product complies.

Partly, but not completely.

The Commission FAQ says that where the component is itself subject to the CRA, the integrating manufacturer can rely in part on the component manufacturer's lifecycle work, such as its vulnerability handling and conformity documentation. But that does not transfer the finished-product manufacturer's own obligations.

Yes.

Recital 34 and the Commission FAQ say that the CRA vulnerability-handling obligations apply to the product in its entirety, including all integrated components.

The CRA expects more than just recording the issue.

Article 13(6) and recital 34 require the manufacturer to inform the person or entity manufacturing or maintaining the component, address and remediate the vulnerability, and, where applicable, provide that person or entity with the applied security fix.

That does not end the finished-product manufacturer's duties.

The Commission FAQ says the manufacturer must comply with the vulnerability-handling obligations for the duration of the product's own support period, for the product in its entirety, including integrated components. If the upstream component is no longer supported, the manufacturer may still need to patch it, replace it, disable affected functions, or mitigate the risk through other means.

Yes.

The draft guidance says the cybersecurity risk assessment must cover relevant risks that originate outside the product itself, such as external networks, environmental factors, infrastructure, or other systems on which the product relies. The CRA then requires those risks to be mitigated through product-level measures rather than by imposing obligations on the outside environment.

It depends on whether the service qualifies as a remote data processing solution.

If the relevant software is designed and developed by the manufacturer or under its responsibility, and its absence would prevent the product from performing one of its functions, it can be part of the product as RDPS. If that second condition is met but the software is a third-party solution not designed and developed by the manufacturer or under its responsibility, the draft guidance says it should be treated similarly to a third-party component: the manufacturer must assess the integration risk and exercise due diligence.

Not necessarily.

The draft guidance's cellular-network example says such a network does not qualify as RDPS and should not be treated like a third-party component where no provider software is integrated into the product. The manufacturer still has to assess the network-related risks and address them through product-level controls.

No.

The draft guidance says the CRA does not provide for transfer of cybersecurity risk or responsibility to users or third parties. Contracts, service levels, and supplier commitments can support compliance and due diligence, but the obligation to place a compliant product on the market remains with the manufacturer.

Yes, where relevant.

Annex VII requires technical documentation to contain enough information to assess compliance, including system architecture, vulnerability-handling processes, the SBOM, test reports, the support-period basis, and the cybersecurity risk assessment. The draft guidance adds that manufacturers should indicate in the technical documentation whether the product has RDPS or relies on third-party cloud solutions and should describe those solutions.

Yes.

The Commission FAQ says that if a vulnerability in an integrated component cannot be adequately addressed by the original component supplier, the integrating manufacturer still has to remediate it by other means, for example by switching out the component, developing a patch itself, or disabling the affected functionality where that is the appropriate product-level remedy.

Yes.

The Commission FAQ says intended purpose, reasonably foreseeable use, and conditions of use can include direct or indirect logical or physical connections to devices or networks. That means the manufacturer has to take the integration context into account in the risk assessment and provide users with the information needed for secure deployment and operation.

No, not by itself.

The draft guidance says manufacturers integrating FOSS components do not become responsible for those components' individual CRA compliance merely because they contribute source code to their maintenance. The same logic applies where manufacturers provide financial support to keep a dependency viable. The integrating manufacturer still remains responsible for its own product and still has to exercise due diligence toward the integrated dependency.

No.

The draft guidance says the fact that other manufacturers integrate a FOSS component into monetised products does not by itself change the status of that component under the CRA. Whether the CRA applies to the dependency itself depends on whether the entity publishing it places it on the market. A FOSS component published for integration by other manufacturers can therefore remain outside the manufacturer regime, or fall under the steward regime, if the publisher does not monetise that component.

Yes.

Where a legal person publishes a FOSS dependency intended for commercial activities but does not place that specific dependency on the market, it may be an open-source software steward rather than a manufacturer. The draft guidance also says the same legal entity can be a manufacturer for one FOSS and a steward for another, including being a manufacturer for a paid version and a steward for a free or community version. That changes the publisher's own CRA role, but it does not remove the integrating manufacturer's obligations for the finished product.

No.

The draft guidance's package-repository example says that merely hosting a FOSS library in a public repository does not by itself give the repository CRA obligations for that dependency. More generally, hosting or infrastructure support does not automatically make a legal person responsible for every project it hosts. A legal person may become a steward only for specific FOSS where it systematically provides sustained support and ensures that project's viability.