Search every question across sub-FAQs

Yes. The CRA definition of software is not limited to compiled binaries; it refers to computer code. The source support notes for the draft guidance treat source code, machine code, compiled code and interpreted code as part of the software analysis.

The boundary question is not only format. Teams should also ask whether the code is supplied for distribution or use on the Union market in the course of a commercial activity, or whether it is merely sample, tutorial, demo or unfinished development material.

No. Article 4(3) allows unfinished non-compliant software to be made available for testing only under limited conditions: it must be available only for the testing period and carry a visible sign that it does not comply and will not be available for purposes other than testing.

The Commission FAQ gives alpha versions, beta versions and release candidates as examples. That means a test release should be labelled, time-limited and separated from a normal product release.

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, it does not meet the Article 3(2) remote-data-processing definition. Non-binding draft Commission guidance says a third-party service that is necessary for a product function should instead be treated similarly to a third-party component: document the boundary decision, assess the integration risk, exercise proportionate due diligence, and apply product-level controls. A connectivity service with no provider software integrated into the product may remain only an external dependency, although its risks still belong in the product risk assessment.

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.