Is My Product in Scope of the CRA? A Plain-English Guide to "Products with Digital Elements"
On 27 July 2026, the European Commission published its final practical guidance on the Cyber Resilience Act. The guidance directly addresses the question that trips up most product teams first: does the CRA even apply to what we make? If your product is hardware or software that can connect - directly or indirectly - to a device or network, and you place it on the EU market commercially, the answer is almost certainly yes. Read on to work through it systematically.
General guidance, not legal advice. This post explains how the CRA's scope rules work in plain English. It is not a substitute for qualified legal or compliance advice on your specific product.
Key points
- The CRA (Regulation (EU) 2024/2847) applies to "products with digital elements" (PDEs) - hardware or software placed on the EU market whose intended or reasonably foreseeable use involves a direct or indirect data connection to a device or network.
- The CRA entered into force on 10 December 2024. Reporting obligations apply from 11 September 2026. Full application is 11 December 2027.
- The scope is intentionally broad. Connected devices, companion apps, firmware, networking gear, OT systems, and most commercial software all qualify.
- A product's cloud backend can be in scope too, if it qualifies as a "remote data processing solution" - meaning the manufacturer built it and the product cannot function without it.
- Purely analogue/mechanical products, products with no data connection, standalone SaaS that isn't tied to a product, and products already covered by certain sectoral laws (medical devices, motor vehicles, civil aviation, marine equipment) are out.
- The Commission's 27 July 2026 guidance includes 67 practical examples, flowcharts, and use cases, with particular attention to remote data processing solutions, free and open-source software (FOSS), and microenterprises/SMEs.
- The guidance is non-binding but represents the Commission's authoritative interpretation and is what market surveillance authorities will use.
What "product with digital elements" actually means
The definition in Article 2 of the CRA is deliberately wide. A product with digital elements is:
Any software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.
Two conditions must both be true for the CRA to apply:
- Placed on the market - made available to a third party in the EU in the course of a commercial activity (selling, licensing, distributing, even giving away as part of a commercial bundle).
- Data connection - the product's intended purpose or reasonably foreseeable use involves a direct or indirect logical or physical connection to another device or network.
That second condition is the threshold test. It does not require the product to be always connected, or connected by default. If a reasonable user could connect it - or if the manufacturer's documentation describes a connected use case - the product is in scope.
The CRA applies regardless of where the manufacturer is established: a company outside the EU that sells into the Union is in scope and must ensure an economic operator in the EU is responsible for the relevant obligations.
The data-connection test is about intended or reasonably foreseeable use — not actual use. A device shipped without a SIM card but designed to accept one, or software that ships with Wi-Fi disabled but has a settings page to enable it, is still in scope.
What's clearly in scope
If your product fits any of the following descriptions, it is a product with digital elements and the CRA applies:
| Product type | Why it's in scope |
|---|---|
| IoT / smart home devices | Direct network connection is core to the product's function |
| Routers, switches, firewalls, VPNs | Network connectivity is the product |
| Industrial control systems, OT/SCADA | Indirect data connections to networks |
| Smartphones, tablets, laptops | Designed for network connectivity |
| Companion mobile apps | Software placed on the market; connects to device/network |
| Firmware distributed separately | Software component placed on the market separately |
| Update/configuration servers (manufacturer-built) | Remote data processing solution integral to product function |
| Embedded software in connected appliances | Software component; device has data connection |
| Desktop/server software with network features | Placed on market; connects to network |
| Wearables with Bluetooth or Wi-Fi | Indirect data connection |
The key point: software is explicitly included. The CRA covers nearly all hardware and software products that can be connected, directly or indirectly, to another device or network - including standalone software distributed as an installable file.
Components count too. A hardware or software component placed on the market separately — even if it is ultimately integrated into another manufacturer's product — is itself a product with digital elements and carries its own CRA obligations.
What's clearly out of scope
Not everything with a chip is a PDE. The CRA does not apply to:
Products with no data connection
A product that has digital logic but no data connection - an offline pocket calculator, a non-networked dishwasher, a coffee machine with no Wi-Fi or Bluetooth - is not a product with digital elements. The digital element alone is not enough; the data connection is what triggers scope.
Standalone SaaS, PaaS, and IaaS
Standalone Software-as-a-Service and other cloud services that are not the remote data processing solution of a specific product are generally outside the CRA. They are typically covered by NIS2 instead. See our CRA vs NIS2 guide for the full analysis.
Non-commercial free and open-source software
FOSS that is made available outside the course of a commercial activity sits largely outside CRA manufacturer obligations. Where FOSS is not placed on the market, it falls outside the CRA's scope - unless the entity publishing it qualifies as an "open-source software steward" under Article 3(14), in which case a lighter set of obligations under Article 24 applies.
Sectoral exclusions
The CRA explicitly carves out products already covered by equivalent EU sectoral legislation:
- Medical devices and IVDs - covered by MDR (Regulation (EU) 2017/745) and IVDR (Regulation (EU) 2017/746), which already impose IT security requirements throughout the product lifecycle.
- Motor vehicles - covered by the type-approval regime under Regulation (EU) 2019/2144, which incorporates UNECE cybersecurity rules. Note: the same systems sold separately outside that type-approval regime remain in CRA scope.
- Civil aviation products - certified under Regulation (EU) 2018/1139 (EASA). Drone components and certain aviation software modules sold separately may still be in scope.
- Marine equipment - within the scope of the Marine Equipment Directive (2014/90/EU).
- National security and defence - products developed or modified exclusively for national security or military purposes.
Sectoral exclusions are narrower than they look. A wellness tracker is in scope even though a certified medical device is not. Software marketed for general fitness does not qualify as a medical device. Pedal-assisted e-bikes (EPACs) are not type-approved and remain subject to the CRA. Always check whether your specific product is actually covered by the sectoral regime — don't assume.
The grey areas: remote data processing, FOSS, and sectoral edge cases
Remote data processing solutions (RDPS)
This is the single most contested scope question. The short version: a cloud or SaaS backend that is integral to a product's function is part of that product for CRA purposes - even though standalone SaaS is out of scope.
The CRA defines a remote data processing solution as data processing at a distance where:
- The software is designed and developed by or on behalf of the manufacturer of the product; and
- The absence of the solution would prevent the product from performing one of its functions.
Both conditions must be met. A backend that is optional, merely enriching, or operated by a third party outside the manufacturer's responsibility does not bring the cloud into scope. The product must genuinely fail to deliver an advertised function without it.
Example: A smart thermostat that can only set schedules via a manufacturer-run cloud app - the cloud backend is an RDPS and is in scope. A thermostat that works fully offline but optionally syncs to a third-party weather service - that third-party service is not an RDPS.
The Commission's July 2026 guidance pays particular attention to remote data processing solutions, clarifying how to determine whether a cloud component meets the three-part test.
Free and open-source software (FOSS)
The FOSS question turns on commercial activity and control, not on whether the code is open.
The decisive factor is whether access to the FOSS itself - including its maintenance and support - is conditioned on payment. Where FOSS can be downloaded and installed freely, and users can optionally purchase support separately, that FOSS is generally not considered to be "placed on the market."
Responsibility for FOSS is linked to who publishes and controls a project. Mere technical permissions - such as commit access - are not sufficient to make someone a manufacturer. Voluntary donations alone do not make FOSS commercial. However, once open-source components are bundled into a commercial product you place on the market, the manufacturer of that finished product carries the CRA obligations for the whole product, including those components.
Sectoral edge cases
The sectoral exclusions are not blanket passes. Components sold separately outside a type-approval regime, drone software modules, and wellness apps that do not qualify as medical devices all remain in CRA scope. If you are relying on a sectoral exclusion, document your reasoning - market surveillance authorities will expect to see it.
How the Commission's July 2026 guidance helps you decide
On 27 July 2026, the European Commission published its final practical guidance (C(2026) 5252) on the Cyber Resilience Act, as required by Article 26 of the Regulation. The guidance is non-binding - an authoritative interpretation of the CRA may only be given by the Court of Justice of the EU - but it represents the Commission's settled view and is what regulators will use in practice.
The guidance is directly relevant to the scope question in several ways:
- 67 practical examples and flowcharts walk through real-world product types, including edge cases around RDPS, FOSS, and combined hardware/software systems.
- It clarifies what "placing on the market" means for products designed before the CRA's full application date, and how the concept of substantial modification affects products already on the market.
- It addresses how to determine the product boundary in complex systems composed of multiple hardware and software elements.
- It explains that sample or demo code provided as part of tutorials is not treated as being placed on the market.
- It gives specific guidance on support periods: they must reflect how long the product is reasonably expected to be in use, and should generally be at least five years unless the expected use is shorter.
What remains unsettled: the technical descriptions for Annex III (important products) and Annex IV (critical products) are still being refined through delegated and implementing acts. Harmonised standards are expected in the second half of 2026 but are not yet cited in the Official Journal - until they are, conformity must be demonstrated directly against the Annex I requirements. These open questions affect how you comply once you are in scope, not whether you are in scope.
What to do next
Once you have confirmed your product is in scope, the immediate priority is the 11 September 2026 reporting deadline - vulnerability and incident reporting obligations apply to all in-scope products already on the market, not just new ones. See our CRA deadlines guide for the full timeline.
List every hardware component, software module, and firmware element that makes up your product as placed on the market. Include components you source from third parties and distribute as part of your product.
For each element, ask: does its intended or reasonably foreseeable use involve a direct or indirect connection to a device or network? If yes to any element, the product is in scope.
For each backend or cloud service associated with the product, apply the three-part RDPS test: (1) Is data processed remotely? (2) Would the product fail to perform a function without it? (3) Is it designed and developed by or under your responsibility? If all three are yes, it is part of your product's CRA scope.
If you believe a sectoral exclusion applies (MDR, automotive type-approval, EASA, marine equipment), verify that your specific product is actually covered by that regime — not just that it operates in that sector. Document your reasoning.
Record your reasoning in writing: which test you applied, what evidence you relied on, and your conclusion. Market surveillance authorities may ask for it. If you are relying on a sectoral exclusion or a FOSS carve-out, the documentation is especially important.
Once you have confirmed you are in scope, the next question is whether your product is default, important (Annex III), or critical (Annex IV) — this determines your conformity assessment route. See our product classes guide.
Where to go next on CRA Facts
- Run the CRA scope & class checker for a guided scope and classification answer.
- Read Default, Important or Critical? Find your CRA product class once you have confirmed you are in scope.
- See CRA vs NIS2: Which EU Cyber Rule Applies to Your Software? if you are unsure whether your SaaS product is a remote data processing solution or a standalone service.
- Check the CRA deadlines guide - the 11 September 2026 reporting deadline is closer than it looks.
Stay current. The Commission will update its guidance as new questions arise, and harmonised standards are expected later in 2026. Subscribe to The CRA Brief for plain-English updates when anything changes.
Related reading
Does This Trigger a CRA Report? How to Identify an Actively Exploited Vulnerability and a Severe Incident Under Article 14
With the 11 September 2026 CRA reporting deadline under 45 days away, here's exactly what triggers a mandatory Article 14 report - and what doesn't.
CRA and Third-Party Components: You Own the Risk, Even If You Didn't Write the Code
Under the Cyber Resilience Act, you stay responsible for every component in your product - including third-party and open-source software. Here's what Article 13 requires and how to act on it.
Connected Toys, Smart Locks, and Health Wearables: Why Your Consumer IoT Product Is Probably "Important" Under the CRA
If you make connected toys, smart-home security devices, or health wearables, you are likely in CRA Important Class I - not the default tier. Here is what that means for conformity assessment.