EU Cyber Resilience Act FAQ Hardware and Software Boundaries

Yes. The CRA defines a product with digital elements as a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately.

For a combined product, the practical question is whether the software is part of the product concept: for example, firmware, an operating system, a driver, a required companion app or a configuration tool that the hardware needs in order to perform its intended functions.

The delivery channel is not decisive by itself. Software can still sit inside the same CRA product boundary when it is supplied for use with the hardware and is necessary for the product to work as intended.

A printer driver, a laptop operating system or an app that enables a connected device function should therefore be analysed by function and intended use, not only by the download path.

Software is more likely to be analysed as standalone when it is supplied as a product in its own right and is not necessary for a particular hardware product to perform one of its intended functions.

That does not take it outside the CRA. The Commission FAQ lists standalone downloadable software, mobile apps and programs downloaded from websites as examples of products with digital elements.

Yes. The CRA definition of software is not limited to compiled binaries; it refers to computer code. The grounding 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, 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.