Search every question across sub-FAQs

Yes. Article 3(1) expressly includes software or hardware components placed on the market separately.

The Commission FAQ gives firmware, embedded software, integrated circuits, motherboards and sensors as examples. If such a component is later integrated into another product, the integrator still needs to assess the resulting product risks and component dependencies.

No. The Commission FAQ explains that integrating an important or critical product with digital elements into another product does not automatically subject the whole product to the conformity assessment procedures for important or critical products.

The compliance analysis still has to look at the product's own core functionality and the risks introduced by the integrated component.

Not automatically. Websites that do not support the functionality of a product with digital elements are not themselves products with digital elements. Standalone SaaS or other cloud solutions designed and developed outside the responsibility of the manufacturer are also not products with digital elements on that basis alone.

They can become relevant if they meet the CRA definition of remote data processing: data processing at a distance, implemented through software designed and developed by the manufacturer or under its responsibility, whose absence would prevent the product from performing one of its functions.

Article 3(2) has three practical checks: the processing is at a distance; the relevant software is designed and developed by the manufacturer or under its responsibility; and without it the product cannot perform one of its functions.

Recital 11 gives the example of a mobile application that requires a manufacturer-provided API or database service. In that case, the remote service can be part of the product boundary as a remote data processing solution.

No, not as hardware merely because the remote function runs there. The CRA definition of remote data processing focuses on data processing software, and Recital 11 says the related requirements do not cover the manufacturer's network and information systems as a whole.

The risk assessment should still consider dependencies on hosting, availability, interfaces and third-party services where those dependencies can affect the product's cybersecurity.

No. A third-party service does not become CRA remote data processing merely because the product depends on it. The manufacturer-responsibility test still matters.

If the service was not designed and developed by the manufacturer or under the manufacturer's responsibility, the safer analysis is to treat it as an external dependency or component risk: document why it is outside the product boundary, assess the cybersecurity risk it creates, and control the dependency through architecture, supplier due diligence and user information where relevant.

Yes, where it is placed on the market as one product with digital elements. Industrial IoT devices, machinery, smart devices and other connected systems can combine hardware, firmware, software, interfaces and remote functions inside one compliance boundary.

Long development cycles, legacy architecture and interoperability constraints do not remove the CRA analysis. They affect the cybersecurity risk assessment, technical documentation, support-period decisions and conformity approach.

Review the boundary when a release adds a required app, driver, firmware package, cloud API, database service, identity function, remote-command feature, update service, paid module, separately marketed component or third-party dependency that a product function relies on.

Also review it when software moves from sample or test distribution into commercial supply, when source code is licensed for customer use, when a component starts being sold separately, or when a remote service moves under or out of the manufacturer's design responsibility. Those changes can alter what is placed on the market and what the cybersecurity risk assessment must cover.

Keep a product-boundary record that names the hardware, firmware, installed software, downloadable software, source-code packages, required apps, hosted functions, APIs, databases, update services and separately marketed components included in the product.

For each item, record whether it is necessary for a product function, who designed and developed it, who places it on the market, whether it is under the manufacturer's responsibility, whether it is remote data processing, and how it is covered in the cybersecurity risk assessment and technical documentation.

They are technical conformity tools for showing how a product with digital elements and the manufacturer's processes meet the CRA's essential cybersecurity requirements.

Harmonised standards are European standards requested and assessed through the EU standardisation system. Common specifications are Commission implementing acts that can be used only as an exceptional fallback where the Article 27 conditions are met. European cybersecurity certification schemes can support CRA conformity only to the extent the relevant certificate or EU statement of conformity covers the CRA requirements.

No. Applying harmonised standards is voluntary, but the manufacturer must still demonstrate conformity with the CRA's essential cybersecurity requirements.

If a manufacturer does not use a relevant harmonised standard, or uses only part of it, the technical documentation needs to explain the other solutions and technical specifications used for the requirements not covered by the standard.

No. For a harmonised standard to create CRA presumption of conformity, its reference must be published in the Official Journal of the European Union for the relevant coverage.

A non-harmonised international, European, ISO, IEC, or ETSI standard may still be useful evidence, but it does not by itself create CRA presumption of conformity. The Blue Guide also warns that where a European standard is based on ISO or IEC text, the presumption attaches to the European version published by reference in the OJEU, not automatically to the source international text.

It means authorities should presume conformity with the specific CRA essential cybersecurity requirements covered by the applied harmonised standard, common specification, or qualifying certification evidence.

The presumption is not product-wide unless the applied conformity tool covers all relevant CRA requirements and risks for that product and the manufacturer's processes. If coverage is partial, the presumption is partial.

No. The cybersecurity risk assessment remains the starting point for deciding which CRA essential requirements are relevant to the product.

The Commission FAQ says that even when a harmonised standard is used, the manufacturer remains responsible for assessing product risks, selecting suitable standards or other specifications, and checking whether the standard covers all relevant risks.

Then only that part benefits from presumption of conformity.

For the remaining requirements or risks, the manufacturer must use other technical specifications or solutions, explain them in the technical documentation, and show why those solutions meet the applicable CRA requirements.

The Commission says M/606 requests a set of harmonised standards in support of CRA compliance, with both horizontal and vertical standards.

Horizontal standards are intended to provide a common framework, methodology, taxonomy, and processes such as vulnerability handling. Vertical standards are product-specific and focus on risks tied to particular intended purposes and reasonably foreseeable uses, especially for important and critical product categories in CRA Annexes III and IV.

No. M/606 starts and frames the standards-development work; it is not the same as an OJ-published harmonised standard.

Even after an ESO adopts a European standard, Article 27(6) requires the Commission to assess it before publishing its reference in the Official Journal. Until the relevant reference is published, the standard does not create CRA presumption of conformity.

The product can still be compliant, but the manufacturer must demonstrate conformity by other means.

The absence of a harmonised standard can also affect route selection. For important products of class I, if relevant harmonised standards, common specifications, or qualifying certification schemes do not exist, Article 32(2) requires a third-party conformity assessment route for the corresponding essential cybersecurity requirements.

Only in the fallback situations set out in Article 27.

The Commission may adopt common specifications after it has requested harmonised standards and the request was not accepted, the standards were not delivered on time, or the standards do not comply with the request. Article 27 also requires that no relevant OJ-published harmonised-standard reference exists and no such reference is expected within a reasonable period.

No. Common specifications are an exceptional fallback tool, not the normal first-line standardisation route.

If common specifications are adopted and applied, they can create presumption of conformity for the CRA requirements they cover. If a manufacturer does not apply them, Annex VII still requires the technical documentation to describe the alternative solutions and relevant technical specifications used.