Search every question across sub-FAQs

Importers must check, before placing a product on the market, that the appropriate conformity assessment was carried out, the technical documentation was drawn up, the product bears the CE marking, and the product is accompanied by the EU declaration of conformity and required user information.

Distributors must verify, before making the product available, that it bears the CE marking and that the relevant manufacturer and importer obligations have been met. For practical evidence, keep supplier declarations, label or software-page screenshots, version identifiers, user-information checks, and escalation records for missing or inconsistent documentation.

The CRA allows non-compliant products, including prototypes, to be presented or used at trade fairs, exhibitions, demonstrations, or similar events if a visible sign clearly states that the product does not comply and will not be made available on the market until it does.

The CRA also has a specific unfinished-software testing exception. Software may be made available for the limited period required for testing if it carries a visible sign stating that it does not comply with the CRA and is not available for purposes other than testing. That exception is not a substitute for CE marking when the product is placed on the market.

No. CE marking is a pre-market conformity milestone, not the end of CRA responsibility. Manufacturers still have support-period, vulnerability-handling, corrective-action, documentation-retention, and update obligations.

For governance, keep a post-market evidence loop connected to the CE-marking file: vulnerability intake, security update decisions, risk-assessment updates, version history, user notices, third-party component remediation, and records showing when the declaration or technical documentation was updated.

Missing or incorrect CE marking is formal non-compliance under the CRA. Market surveillance authorities must require the manufacturer to end the non-compliance, and if the issue persists Member States must restrict or prohibit availability, or ensure withdrawal or recall.

The CRA also places non-compliance with Article 30(1) to (4) within the administrative-fine category in Article 64(3). Correct both the visible marking issue and the underlying evidence gap that caused it.

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 draft Commission guidance 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 draft 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.

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 draft Commission guidance 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 draft 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.