Search every question across sub-FAQs

No. The draft 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.

The CRA recognises four ways to demonstrate conformity with the essential cybersecurity requirements:

- internal control based on module A

- EU-type examination based on module B followed by conformity to EU-type based on module C

- full quality assurance based on module H

- where available and applicable, a European cybersecurity certification scheme specified under Article 27(9)

A cybersecurity certificate is not automatically a CRA conformity route. The relevant certification scheme must be specified for CRA purposes under Article 27(9), cover the applicable requirements or assurance conditions, and be available for the product category.

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.

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.

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.

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.

Important products of class II must use one of these routes:

- module B+C

- module H

- where available and applicable, a European cybersecurity certification scheme specified under Article 27(9) at assurance level at least substantial

Outside the free and open-source software exception in Article 32(5), module A is not available for class II products.

Critical products listed in Annex IV must use:

- a European cybersecurity certification scheme where Article 8(1) requires one, or

- if the conditions in Article 8(1) are not met, one of the class II routes in Article 32(3)

So critical products do not automatically have to use the same third-party route in every case. The legal answer depends first on whether a certification scheme has been made mandatory under Article 8(1).

No.

The CRA and the Commission FAQ both say that integrating an important or critical product into another product does not by itself make the finished product subject to the conformity assessment regime for that component category. The decisive factor is the core functionality of the finished product as a whole.

Yes.

Manufacturers of products qualifying as free and open-source software that fall under Annex III categories may use any of the Article 32(1) procedures, including module A, provided that the technical documentation is made available to the public at the time of placing the product on the market.

Yes.

The CRA sets minimum route requirements for certain product categories, but the manufacturer can still choose a more demanding route. For example, a default-category product may still go through module B+C or module H, and a class I product that could rely on module A may still opt for third-party assessment.

Module A is the internal control route.

Under this route, the manufacturer verifies that the product complies with the CRA, draws up the technical documentation, performs the necessary testing or equivalent verification, and declares compliance on its sole responsibility. No notified body participates.