Do important and critical products always need third-party conformity assessment?
Important class II products always do, and important class I products do whenever Article 32(2) is triggered.
For critical products, the route is also third-party in practice, either through Article 8(1) certification if that delegated-act route exists, or through Article 32(3) if it does not. The draft guidance describes important class II and critical products as subject to mandatory third-party conformity assessment, and says the same for important class I when the internal-control path is unavailable.
Is there a special rule for important products qualifying as free and open-source software?
Yes.
Article 32(5) says that manufacturers of products qualifying as free and open-source software and falling under Annex III may use one of the Article 32(1) procedures, provided that the technical documentation is made available to the public at the time of placing on the market.
Does being classified as important or critical mean that only the core function is assessed?
No.
The draft guidance says that once the core functionality has been identified and the route selected, the conformity assessment still has to cover the product as a whole. Additional or ancillary functions can create additional risks that still need to be addressed.
If a harmonised standard covers only the core functionality of an important class I product, does the whole product automatically get presumption of conformity?
No.
The draft guidance explains that a harmonised standard may support the use of internal control for an important class I product where it covers the core functionality, but the presumption of conformity extends only to the parts whose risks are actually covered by that standard. Additional functions and additional risks may still need to be addressed through other means.
What should manufacturers use as the main reference for deciding whether a product matches a listed CRA important or critical category?
The CRA itself points to a Commission implementing act that sets the technical descriptions, and the Commission FAQ says those descriptions are now laid down in Implementing Regulation (EU) 2025/2392.
So in practice, manufacturers should compare the product's actual features and technical capabilities against those technical descriptions, not classify the product only by marketing label or broad product family.
Can the Annex III and Annex IV lists change over time?
Yes.
The CRA empowers the Commission to amend Annex III and Annex IV by delegated act. For Annex III changes, the CRA generally requires a minimum transitional period of 12 months where appropriate. For Article 8 delegated acts and Annex IV changes, the CRA generally requires a minimum transitional period of six months.
How does the CRA work for important or critical products that are also high-risk AI systems?
The CRA contains a special overlap rule.
As a rule, Article 12(2) points to the relevant AI Act conformity assessment procedure for products covered by both regimes. But Article 12(3) creates a derogation for certain important and critical CRA products that are also high-risk AI systems and use the AI Act's internal-control route. In that situation, the CRA's own conformity assessment procedures still apply for the CRA essential cybersecurity requirements.
Can a manufacturer downplay or overstate the core functionality to avoid the stricter regime?
No.
The draft guidance says a manufacturer may not misrepresent the product's core functionality in order to escape the conformity assessment regime applicable to important or critical products. It gives the example of inconsistencies between promotional materials, instructions for use, and technical documentation.
Does being classified as important or critical create a separate set of CRA essential cybersecurity requirements?
No.
The core CRA essential cybersecurity requirements still come from Article 6, Article 13 and Annex I. The classification as default, important class I, important class II or critical mainly determines which conformity assessment route applies before the product is placed on the market. The Commission FAQ's risk-assessment section likewise explains that manufacturers of all products with digital elements must implement the essential requirements in a way proportionate to the product's risks.
Can a product move into a stricter class just because one version is intended for a more sensitive environment or presents higher deployment risk?
No, not by itself.
Classification still turns on the product's core functionality against the Annex III or Annex IV category descriptions. The Commission FAQ's VPN example shows that two products with the same core functionality can present different risk levels because of their intended deployment and therefore require different risk treatment measures, but that does not by itself change whether they are an important, critical or default-category product.
Does the Article 32(5) free-and-open-source-software rule apply to critical products?
No.
Article 32(5) is expressly limited to products qualifying as free and open-source software that fall under the categories set out in Annex III. So that special route can apply to important products in Annex III, subject to the public-technical-documentation condition, but it does not extend the same derogation to Annex IV critical products.
If the Commission later adds, removes, or reclassifies an Annex III or Annex IV category, does that automatically retroactively change products already placed on the market?
Not automatically.
Read together, the CRA's delegated-act transition rules and the Blue Guide's placing-on-the-market principle mean that the new classification matters for products placed on the market after the new rules start applying, while products already placed on the market are not automatically reclassified just because the legislation is later revised. For Annex III changes, the CRA generally requires a transitional period of at least 12 months where appropriate. For Article 8 delegated acts and Annex IV changes, the CRA generally requires at least six months, unless urgency justifies less.
What is the difference between an integrated component, a remote data processing solution, and an external dependency?
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
Does the manufacturer remain responsible for the cybersecurity of the whole product when it integrates third-party components?
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.
Are CRA cybersecurity risk assessment and component due diligence the same obligation?
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.
What does due diligence mean when integrating third-party components?
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.
Does a CE-marked component automatically make the finished product compliant?
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.
Can a manufacturer integrate components that are not CE-marked under the CRA?
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.
Can the integrating manufacturer rely on the component manufacturer's own CRA work?
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.
Do vulnerability-handling obligations extend to integrated components?
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.