Product with digital elements is the CRA's central product concept. It can include software, hardware, separately marketed components and qualifying manufacturer-controlled remote data processing, but the definition alone does not determine whether every particular product is within scope.
Article 3 Gives the Core Definition
Article 3 defines a product with digital elements as a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately. The definition is intended to capture the digital product as it actually functions rather than limiting CRA analysis to a physical device. A marketed product may therefore include local software, embedded software, hardware and a necessary manufacturer-controlled remote function within the same CRA product analysis.
A Software Product Can Qualify on Its Own
Software does not need to be embedded in hardware before it can be a product with digital elements. Applications, operating systems, security tools, development products and other software can potentially fall within the definition. The scope analysis then needs to consider Article 2, including whether the software is made available on the Union market and whether its intended purpose or reasonably foreseeable use includes the required data connection.
Hardware Products Can Include Their Digital Functions
A hardware product can also qualify as a product with digital elements. Connected devices commonly combine processors, firmware, applications, communication interfaces and remote functions. The CRA product boundary should reflect the marketed product and the software or processing necessary for its functions. Splitting embedded software away from the hardware for compliance purposes can produce an artificial boundary that does not match how the product operates.
Separately Marketed Components Are Expressly Included
Article 3 specifically refers to software and hardware components being placed on the market separately. That wording means a component can itself be a product with digital elements rather than receiving CRA relevance only after incorporation into a finished product. Examples can include software libraries distributed as products, processors, security components or other digital elements supplied separately, although the actual scope conclusion depends on the facts and the Regulation's other conditions.
Remote Data Processing Can Form Part of the Product
Remote data processing is defined narrowly enough to distinguish product functionality from every external service the product might contact. It covers processing at a distance for which the software is designed and developed by the manufacturer, or under the manufacturer's responsibility, where the absence of that processing would prevent the product from performing one of its functions. A manufacturer-controlled cloud function that is necessary for a smart product can therefore form part of the CRA product boundary.
Not Every Cloud Service Used by the Product Is Automatically Included
The CRA does not convert every third-party cloud dependency into remote data processing belonging to the product. The statutory definition focuses on software designed and developed by the manufacturer or under the manufacturer's responsibility and on processing whose absence would prevent a product function. Teams should document which remote functions meet that test and which external services are ordinary dependencies or infrastructure outside that specific definition.
The Definition Does Not Replace the Article 2 Scope Test
Identifying something as software or hardware within the Article 3 definition is only one part of the analysis. Article 2 generally connects CRA scope to products made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. The product can also be affected by exclusions and special rules. A reliable conclusion therefore combines the Article 3 definition with Article 2 rather than quoting the definition in isolation.
Define the Product Boundary Before Assessing Compliance
Before beginning a cybersecurity risk assessment or Annex I mapping exercise, document what the product actually includes. Record the marketed software or hardware, separately supplied components, embedded code, essential remote processing, interfaces and expected data connections. Also record which organisation controls each part. That product boundary can then be used consistently for CRA scope, risk assessment, vulnerability handling, technical documentation and conformity work.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.