If a component does bear the CE marking, can the manufacturer rely on that?
Yes, but only as supporting evidence.
The Commission's FAQ says that when integrating components that bear the CE marking, manufacturers may rely on the component's EU declaration of conformity and accompanying documentation to support their own compliance. That still does not remove the integrating manufacturer's own obligation to make sure the component is suitable for the finished product and does not compromise its cybersecurity.
What if the component was integrated before the CRA became applicable and cannot yet be checked for CRA conformity?
The CRA anticipated that situation.
Recital 35 says that immediately after the transition period a manufacturer may not yet be able to verify, for example by checking CE marking, that a previously integrated component's manufacturer has demonstrated conformity with the CRA. In that case, the manufacturer should exercise due diligence through other means.
How is component due diligence different from the CRA cybersecurity risk assessment?
They are distinct but complementary obligations.
The draft Commission guidance explains that the cybersecurity risk assessment under Article 13(2) covers the risks affecting the product as a whole, including external dependencies and operating context. Due diligence under Article 13(5) focuses more specifically on third-party components that form part of the product and on verifying, in a risk-based way, that those components match the product's cybersecurity needs.
What kind of evidence can support CRA component due diligence in practice?
The draft Commission guidance says evidence may consist of documentation obtained from the component manufacturer, such as technical specifications, security documentation, or relevant conformity or assurance documentation. Where appropriate, the manufacturer may also carry out functional tests on the component.
The CRA also requires manufacturers to systematically document relevant cybersecurity aspects and to keep technical documentation showing conformity, so this material will normally form part of the broader compliance record for the product.
Does the CRA require the manufacturer to make the component SBOM public?
No.
The CRA encourages identification and documentation of components, including by drawing up an SBOM, and the Commission's FAQ lists review of a component SBOM, when available, as one possible due-diligence step. But the CRA recital also says manufacturers should not be obliged to make the SBOM public.
What happens if the manufacturer identifies a vulnerability in an integrated component?
The manufacturer must report the vulnerability to the person or entity manufacturing or maintaining the component and must address and remediate it in line with the CRA's vulnerability-handling requirements.
The draft guidance adds two important limits: the upstream-reporting obligation concerns the version of the component that the manufacturer actually integrates, and it covers vulnerabilities that exist in the integrated component itself, not vulnerabilities caused only by the manufacturer's own integration choices. 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 person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.
Can the integrating manufacturer rely on the component manufacturer's own vulnerability handling?
Often yes, but not completely.
Where the component itself was placed on the market after the CRA applies, the integrating manufacturer can benefit from the component manufacturer's own vulnerability-handling obligations. But the integrating manufacturer still remains responsible for the finished product and must continue to meet its own vulnerability-handling duties for that product as a whole.
If the manufacturer contributes code to an upstream FOSS component, does that make it responsible for that component's own CRA compliance?
No, not by itself.
The draft guidance says that manufacturers integrating FOSS components do not become responsible for those components' individual CRA compliance merely because they contribute source code to their maintenance. The status of that FOSS component depends on whether the entity that publishes it places it on the market. The integrating manufacturer still remains responsible for its own product and must still perform due diligence on the FOSS component it uses.
How does due diligence work for open-source components that are outside the CRA manufacturer regime?
The same due-diligence obligation still applies.
Manufacturers may integrate open-source components that are outside the CRA because they were not made available on the market in the course of a commercial activity, but they still have to apply risk-based due diligence. The CRA also empowers the Commission to establish voluntary security attestation programmes that could help manufacturers assess such open-source components.
How should manufacturers treat integrated third-party SaaS, PaaS or similar solutions that are necessary for product functions but are not designed or developed by the manufacturer?
The draft guidance says those solutions should be treated like third-party components.
Where the solution is necessary for the product to perform one of its functions but is not designed and developed by the manufacturer or under its responsibility, the manufacturer should assess the integration risks in the cybersecurity risk assessment, mitigate them through product-level measures, and exercise due diligence on that third-party solution. The guidance gives this logic for examples such as third-party SaaS support chat, PaaS notification environments and SaaS storage services.
Does every external dependency need Article 13(5) due diligence?
No.
The draft guidance distinguishes between integrated third-party components and mere communication or connectivity enablers. For example, a cellular network that a smartphone uses for connectivity is not treated like a third-party component, because there is no software integrated into the product from that network provider. In that scenario, the guidance says it is not necessary to exercise due diligence obligations toward the network provider.
Must the manufacturer report upstream if the component no longer has a maintainer or if the manufacturer maintains an independent fork?
Not necessarily.
The draft guidance says manufacturers are not required to report upstream where the component no longer has a maintainer. It also says upstream reporting is not required where the manufacturer has duplicated a FOSS component and no longer relies on the original maintainer for new versions or security fixes.
If the manufacturer shares a security fix upstream, must it ensure that the maintainer accepts or merges it?
No.
The draft guidance says the CRA requires the manufacturer to share the fix, where appropriate, but not to ensure that the maintainer accepts it or integrates it into the component's codebase. It also does not require the manufacturer to accept a fix proposed by the maintainer if the manufacturer prefers another suitable mitigation.
Does the support period of integrated components matter for CRA component due diligence?
Yes.
The Commission's FAQ expressly lists the support period of a component as one of the due-diligence checks manufacturers may undertake, and Article 13(8) allows manufacturers to take into account the support periods of third-party integrated components that provide core functions when determining the support period for their own product.
Does due diligence mean proving that every component is perfect or vulnerability-free before integration?
No.
The CRA sets a due-diligence obligation aimed at ensuring that integrated components do not compromise the finished product's cybersecurity. The Commission's FAQ and draft guidance both describe a risk-based process of verification, testing, mitigation and remediation, not a requirement to prove that every component is free of all flaws in every context.
What decides which CRA conformity assessment route a manufacturer has to use?
The starting point is the product's classification under the CRA.
Manufacturers first need to determine whether the product is in the default category, an important product of class I, an important product of class II, or a critical product. That depends on the product's core functionality, not simply on the fact that it includes components that are themselves important or critical products.
Which CRA conformity assessment route applies to products in the default category?
Products in the default category can always use module A.
They may also use module B+C or module H if the manufacturer chooses, because Article 32(1) makes those routes generally available. The key point is that the CRA does not require third-party conformity assessment for default-category products.
When can an important product of class I use module A?
An important product of class I can use module A if, in assessing compliance, the manufacturer has applied relevant harmonised standards, common specifications, or European cybersecurity certification schemes at assurance level at least substantial.
If those instruments have not been applied, have been applied only in part, or do not exist, Article 32(2) requires the relevant essential cybersecurity requirements to be covered through module B+C or module H instead.
What if a harmonised standard covers the core functionality of an important class I product, but not every cybersecurity risk of the full product?
The draft Commission guidance takes the view that the manufacturer may still use internal control if the harmonised standard covers the product's core functionality.
But that does not mean the whole product automatically benefits from a full presumption of conformity. The guidance explains that the manufacturer still has to address additional risks presented by broader product scope or additional functions, and the presumption of conformity extends only to the parts covered by the standard.