A product with digital elements is a software or hardware product — and its remote data processing solutions — whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network.
The short answer
A **product with digital elements** is a software or hardware product — **and its remote data processing solutions** — whose intended or reasonably foreseeable use includes a **direct or indirect data connection** to a device or network.
That definition is deliberately wide. Three consequences follow immediately, and each catches a different kind of company:
``` "hardware or software" -> standalone software is in scope. No physical product is required. "direct or INDIRECT" -> a device that never touches the internet itself, but pairs with a phone that does, is connected. "remote data processing" -> the cloud component is part of the product, not a separate service alongside it. ```
**If you sell anything that connects to anything, start from the assumption that you are in scope and work outwards.** The exclusions are narrow and specific; the definition is not.
The three readings that go wrong most often
**1. « Our product is not connected — it only pairs by Bluetooth »**
**Indirect connection counts.** A sensor that talks to a gateway, a wearable that syncs with a phone, an industrial module on a local bus that reaches a supervisory system — each has a data connection to a device or a network.
The regulation does not ask whether the product reaches the internet. It asks whether it connects to a **device or network**. Very little modern equipment does not.
**2. « The cloud part is a separate service, governed by its own contract »**
**Remote data processing solutions are inside the product's scope** where the processing is necessary for the product to perform its functions.
This is the reading that changes engineering plans. A device whose features depend on your backend does not have a device scope and a cloud scope: **it has one scope**, and the security requirements in Annex I follow the function, not the deployment boundary.
Contractual separation does not create regulatory separation.
**3. « It contains open-source components, so that part is exempt »**
**The exclusion attaches to the supply, not to the licence.**
Free and open-source software supplied **outside the course of a commercial activity** is out of scope. **An open-source component shipped inside a commercial product is inside that product's scope**, and the manufacturer answers for it — including under Annex I Part II, which requires identifying and documenting the components and remediating their vulnerabilities.
The regulation does create a lighter, distinct regime for **open-source software stewards** — organisations supporting the development of open-source products used commercially without themselves monetising them. **That regime is for the steward, not for you as an integrator.**
What genuinely falls outside
Products already governed by equivalent sectoral regimes are carved out — among them medical devices, in-vitro diagnostic devices, civil aviation, motor vehicles and marine equipment — as are products developed **exclusively for national security or defence purposes**, and products specifically designed to process classified information.
**Spare parts** made available to replace identical components, and manufactured to the same specifications, are treated distinctly.
**The exclusions are sectoral and precise.** "We are not a security product" is not among them, and neither is "we sell to businesses, not consumers". The CRA does not distinguish consumer from professional products.
Why this page decides the cost of everything else
Every CRA obligation is scoped by this definition. Get it wrong and the error compounds in one direction only — **you find out you were in scope, late**, when the evidence you needed does not exist yet.
``` in scope -> Annex I Part I product security requirements -> Annex I Part II vulnerability handling, for the whole support period -> Article 13 risk assessment, technical documentation, due diligence on third-party components -> Article 14 reporting, from 11 September 2026 -> classification default · Annex III important · Annex IV critical ```
**The support period alone changes the economics.** It must be at least five years unless the expected lifetime is shorter, and it commits you to free security updates for that whole time. A company that concludes late that it is in scope has already priced products without that cost in them.
For exporters — the part that is not obvious from outside the EU
**Scope attaches to the product placed on the Union market, not to where you are established.** A manufacturer in Shenzhen, Taipei, Seoul or San Jose is in scope from the moment the product is made available in the Union.
**And it does not travel through your distributor.** The importer must verify that the manufacturer carried out the conformity assessment and drew up the technical documentation. If you cannot supply it, your importer cannot lawfully place the product — which means the obligation reaches you through the commercial relationship even where enforcement would not reach you directly.
**A certification obtained elsewhere does not substitute.** It may evidence comparable technical practice, and that is worth something in the conformity work — but CRA conformity is a separate legal act with its own assessment, documentation, declaration and marking.
How to determine scope, in order
1. **Does the product connect, directly or indirectly, to a device or network?** If yes, treat it as in scope and continue. 2. **Does a remote component perform functions the product needs?** If yes, that component is inside the same scope. 3. **Is the product listed in one of the sectoral exclusions?** Check the list itself, not a summary of it. 4. **Then, and only then, classify** — default, Annex III class I or II, or Annex IV. That determination decides whether you can self-assess. 5. **Write down the reasoning and the date.** A market surveillance authority may ask why you concluded you were out of scope. "We assumed" is not an answer; a dated assessment is.
Tools available on NexCyber
- Free applicability assessment — confirm CRA scope and product classification
- Compliance responsibility mapper — RACI by role
- Penalty calculator — exposure by regulation
Further reading
→ What is the Cyber Resilience Act → Important versus critical: Annex III and Annex IV → CE marking explained → SBOM under the CRA: format, depth and signing → RED Article 3(3) for connected devices → CRA regulation overview
*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. The technical description of product categories and several scope questions are refined by delegated and implementing acts — verify against the current text of Regulation (EU) 2024/2847 and the Official Journal. Consult your competent authority or a qualified adviser.*
This is an educational explainer. For the canonical regulation reference, see the dedicated CRA page — or run an assessment to see how it applies to your product.