Use this CRA FAQ to understand when hardware and software form one product, when software is standalone, and how the CRA treats source code, apps, remote functions, and hosting infrastructure.
Built for product, platform, firmware, cloud, legal, and compliance teams defining CRA product scope.
Structured answer sets in this page tree.
Cited legal and guidance references.
CRA compliance depends on drawing the product boundary correctly. This FAQ focuses on when hardware and software form a single product with digital elements, when software stands alone, and how to treat source code, companion apps, remote data processing, and third-party hosted functions.
Yes.
The CRA definition is broad enough to cover hardware and software supplied together as one product, including cases where the hardware and software are supplied separately but are intended to operate together as a single product.
Article 3(1)
points 17-19
Research Copilot can turn EU Cyber Resilience Act FAQ Hardware and Software Boundaries into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ.
Start from EU Cyber Resilience Act FAQ Hardware and Software Boundaries and move to source-backed decisions and evidence workflows.
Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ.
The draft guidance says the key question is whether the software is necessary for the product to perform its intended functions in light of the product's intended purpose and reasonably foreseeable use.
The delivery channel is not decisive on its own. What matters is whether the hardware is designed to operate together with that software as part of one product concept.
No.
Software can still be part of the same product even if it is obtained through a separate channel such as an app store, a manufacturer website or another digital link after the hardware is supplied.
Yes.
The Commission FAQ expressly lists software placed on the market together with hardware even where it is not preloaded, such as printer drivers, laptop operating systems and tools used to design and program FPGAs.
section 1.2
They can be.
The Commission FAQ gives printer drivers as an example of software that may be placed on the market together with hardware. The draft guidance then makes the point more explicit: where the printer cannot fulfil its intended purpose without the drivers, the printer and the drivers together constitute a single product with digital elements.
Yes, if it is necessary for the product's intended functionality.
The draft guidance gives the example of a fitness wearable and a companion smartphone app that together form one product because they are designed and intended to operate together to deliver the product's functionality.
Not automatically.
The draft guidance points to necessity as the decisive factor. If the device can still perform its intended functions without the app, that points away from treating the app as part of the same combined product, although the exact answer still depends on intended purpose and reasonably foreseeable use.
It is more likely to be treated as standalone software when it is supplied as software in its own right and is not necessary for a hardware product to perform its intended functions.
The Commission FAQ confirms that standalone downloadable software can itself be a product with digital elements. The draft guidance then distinguishes that case from software that forms part of a hardware-software product.
No.
The draft guidance says its specific explanation for digitally supplied standalone software applies only to standalone software. It does not govern cases where the software is combined with hardware as part of one product.
No.
The draft guidance distinguishes software supplied via physical means from standalone software supplied digitally. In that case, the physical carrier with the software on it is treated as the product supplied for distribution.
Yes.
The CRA defines software as computer code, and the draft guidance explains that this can include both machine code and source code.
Article 3(4)
points 20-22
No.
The draft guidance says whether code is uncompiled, compiled or interpreted is not relevant to whether it is software within the CRA.
Yes.
The draft guidance says that where a manufacturer provides customers with computer code as part of its commercial activity, that code is considered to be placed on the market regardless of whether it is machine code or source code.
The draft guidance says the original supplier is responsible for the code it placed on the market. The customer's later adaptations and compilation are a separate matter.
No.
The draft guidance says sample or demo code provided as part of tutorials or training materials is not considered placed on the market.
No.
The draft guidance says unfinished code shared during design and development is not considered placed on the market because its manufacturing phase is not complete. Separately, Article 4(3) deals with unfinished software intentionally made available for testing under specific conditions.
point 21
Article 4(3)
section 1.6
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.
Article 3(1)
section 1.2
No.
The Commission FAQ says websites that do not support the functionality of a product are not themselves products with digital elements. It also says standalone SaaS or other cloud solutions designed and developed outside the responsibility of a manufacturer are not themselves products with digital elements. Where such elements meet the definition of remote data processing, they may instead fall within scope on that basis.
section 1.2
Article 3(2), recital 12
Yes.
The draft guidance says complex systems can constitute a single product where the system is placed on the market as one product.
point 26
Article 3(1)
No.
The draft guidance says those characteristics do not in themselves exclude a complex system from the CRA. They affect how the CRA's risk-based compliance analysis is applied, not whether the product is in scope.
points 27-29
Article 13(2)-(4), recital 55
Yes.
The CRA definition of a product with digital elements includes its remote data processing solutions. Whether a specific remote function qualifies depends on the separate Article 3(2) test, but the product boundary is not limited to the local hardware or software alone.
Article 3(1), Article 3(2)
section 1.2
Yes.
The Commission FAQ gives tools used to design and program FPGAs as an example of software placed on the market together with hardware. Read together with the draft guidance, this shows that relevant software does not need to be preloaded on the hardware or run on the hardware itself. If, in light of the intended purpose and reasonably foreseeable use, the software is necessary for the hardware product to perform its intended functions or to be meaningfully used, it can form part of the same product boundary.
Not automatically.
The cited sources identify the wearable and the manufacturer-provided smartphone application as together constituting a single product because they are designed and intended to operate together. At the same time, the Commission FAQ separately recognises mobile apps and smartphones or laptops as products with digital elements in their own right. Taken together, those examples indicate that the necessary app can fall within the combined product boundary without automatically absorbing the user's general-purpose host device into that same boundary.
point 19, Example 4
section 1.2
Yes, if it is designed and developed under the manufacturer's responsibility.
The draft guidance explains that remote data processing can qualify as part of the product not only when it is developed fully in-house, but also when an external provider develops it solely on behalf of the manufacturer, based on the manufacturer's designs and specifications. In that situation, the remote software can still fall within the product boundary as remote data processing.
Article 3(1), Article 3(2)
point 179
No, not as such.
The draft guidance explains that remote data processing is defined as the software elements of data processing at a distance. It is not meant to include, as part of the product boundary, the hardware that the remote data processing relies on. So the relevant remote software may fall within the product boundary, but the entire hosting infrastructure does not automatically do so as hardware.
Article 3(2), Article 3(4), Article 3(5)
point 164
No.
For remote functionality to qualify as remote data processing, the software must be designed and developed by the manufacturer or under its responsibility. The draft guidance says standard third-party SaaS, and comparable third-party elements in PaaS or IaaS stacks, do not meet that test merely because the product depends on them. Instead, they should be treated similarly to third-party components: the manufacturer must assess the resulting risks and address them through product-level measures and due diligence.
Article 3(2), Article 13(5)
points 179, 184-185