Search every question across sub-FAQs

The EU declaration of conformity is the document where the manufacturer declares that the product complies with the CRA and takes responsibility for that conformity. It must use the CRA Annex V model structure, be updated as appropriate, and be available in the languages required where the product is placed or made available on the market.

Where several EU harmonisation acts apply, the CRA requires one EU declaration of conformity covering all those acts. The Commission FAQ also explains that the product may be accompanied by the full declaration or by the simplified declaration from Annex VI with an internet address where the full declaration can be accessed.

The technical documentation must contain the data and details needed to show that the product with digital elements and the manufacturer's processes comply with the CRA essential cybersecurity requirements. It must include at least the Annex VII elements.

In practice, the CE-marking evidence file should include the cybersecurity risk assessment, product description and versions, design and development evidence, vulnerability-handling process evidence, applied standards or technical specifications, test or evaluation results, user information, declaration materials, and records explaining why any essential requirement is not applicable.

No. Harmonised standards, common specifications, and qualifying certification schemes can help show conformity, but they do not replace the manufacturer's cybersecurity risk assessment. The manufacturer still has to identify the relevant risks and essential requirements, check which parts are actually covered, and document any gaps or alternative solutions.

A practical decision path is straightforward: first assess the risks, then decide whether a harmonised standard, common specification, or certification scheme covers them fully or only in part, and finally explain in the technical documentation how the remaining requirements are met. If none of those tools is used for a relevant requirement, the evidence file needs a clear technical explanation instead.

Yes, the CRA does not require manufacturers to integrate only CE-marked components. The final product manufacturer must exercise due diligence so third-party components, including free and open-source software components, do not compromise the cybersecurity of the product.

A CE-marked component can support the evidence file through its declaration and accompanying documentation, but it does not automatically make the finished product compliant. Component evidence should be tied back to the final product's risk assessment, vulnerability handling, and essential-requirement coverage.

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). The useful compliance response is to fix 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.

This is not limited to 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 therefore 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.

That means the integrating manufacturer cannot skip due diligence just 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. The question is whether the component can affect the cybersecurity of the finished product and what risk-based checks are needed 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 where appropriate.

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.

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.