The exclusion list is real, and it is read wrong almost every time
Article 2 of Regulation (EU) 2024/2847 carves several product categories out of the Cyber Resilience Act, on the reasoning that other Union law already addresses the same risks to an equal or higher level. Medical devices and in vitro diagnostics regulated under Regulations (EU) 2017/745 and 2017/746 are excluded. Motor vehicles covered by the type-approval regime under Regulation (EU) 2019/2144 are excluded. Civil aviation products certified under Regulation (EU) 2018/1139 are excluded. Marine equipment within the scope of Directive 2014/90/EU is excluded. Article 2 also carries a narrow spare-parts exemption and a delegated-act mechanism allowing the Commission to limit or exclude CRA application where sectoral rules achieve the same or a higher level of protection.
Read that list in a scoping meeting and the conclusion writes itself: we are a medtech company, medical devices are excluded, we are done. That conclusion has been wrong in every scoping exercise I would expect to see in a regulated business, and the reason is structural rather than legal hairsplitting.
The exclusions attach to products, not to companies. There is no such thing as an excluded manufacturer under the CRA. There are excluded products, defined by their intended purpose, sitting inside portfolios that contain other things. For who carries the obligation in the first place, see who the CRA applies to.
That single distinction is the whole article. What follows is what it costs each sector that gets it wrong.
| Boundary | Excluded or outside | In scope | Deciding test |
|---|---|---|---|
| Medtech | Medical device or in vitro diagnostic governed by the MDR or IVDR | Wellness, fitness or hospital-administration software sold as a separate product | The product's intended purpose |
| Motor vehicles | System delivered inside a type-approved vehicle | The same system sold separately as an aftermarket product | Whether it is covered by the vehicle type-approval regime |
| Drones | Drone in the certified category | Drone in the open or specific category where it meets the product definition | Whether certification under the Basic Aviation Regulation is required |
| Spare parts | Identical replacement made to the same specifications | Replacement that changes function or design | Whether it is genuinely identical to the original product |
| Cloud and SaaS | Standalone SaaS independent of a physical product | Cloud service required for a physical product's core function when the RDPS test is met | Whether the product functionally depends on processing controlled by the manufacturer |
| Open source | Genuinely non-commercial open-source software | Open-source code embedded in a commercial product | Commercial activity, steward status and downstream integration |
Medtech: the exclusion covers the device and stops there
The MDR and IVDR exclusion is genuine. It also has a hard edge, and the edge is intended purpose.
Software that analyses data for a specific medical diagnosis is a medical device and is excluded. Software marketed for general fitness, wellness tracking or hospital administration is not a medical device, does not inherit the exclusion, and sits fully inside the CRA. A company selling a Class II device under the MDR and a companion wellness app is running two regulatory regimes at once, and the second one has a reporting obligation from 11 September 2026.
Three more places the exclusion runs out:
Components sold standalone. Operating systems, microcontrollers, communication modules and software libraries that live inside a regulated device are excluded as part of that device. Sold on their own as products with digital elements, they are in scope on their own terms.
Everything that is not the device. The exclusion is about products placed on the market. It says nothing about the organisation's own IT estate, which is where your NIS2 obligations live if you are an essential or important entity in the health sector.
The direction of travel. The Commission proposed amendments to the MDR and IVDR in December 2025 that would write cybersecurity explicitly into the general safety and performance requirements and introduce reporting of actively exploited vulnerabilities and severe incidents to national CSIRTs and ENISA. If adopted in that form, the practical effect is that medtech gets CRA-shaped reporting duties through medical device law rather than through the CRA. The exclusion survives, the work arrives anyway. Building the detection and escalation capability now is the cheaper path either way.
Automotive, aviation, marine: the carve-out follows the regime, not the part
The vehicle exclusion covers systems delivered inside a type-approved vehicle. The same system sold separately, outside that regime, stays in scope. A supplier shipping an aftermarket telematics unit does not get to point at the type-approval carve-out.
Aviation is the sharpest illustration. Products certified under the Basic Aviation Regulation are excluded. Drones are only excluded where they fall in the certified category. Unmanned aircraft in the open or specific categories do not require that certification, and they remain in scope of the CRA.
The spare-parts exemption follows the same logic: it covers identical replacements manufactured to the same specifications. A replacement that differs in function or design is a new product with digital elements.
Open source: the exemption is about commercial activity, not licence
Non-commercial open-source software developed outside a commercial activity sits largely outside scope. Two things narrow that in practice.
The CRA creates a distinct legal category, the open-source software steward, for entities that provide sustained support for open-source products intended for commercial activity. Stewards carry a lighter, tailored regime: a cybersecurity policy, cooperation with market surveillance authorities, and reporting of actively exploited vulnerabilities. They are explicitly outside the administrative fines in Article 64, which is a meaningful relief and not an exemption from the duties themselves.
And the exemption does not travel downstream. Open-source code embedded in a commercial product is inside that product's scope, and the commercial integrator carries it. "It is upstream and it is MIT-licensed" is not a scope argument.
SaaS: outside, until the product depends on it
Standalone software-as-a-service that operates independently of a physical product sits outside CRA scope. This is the exclusion your buyers will hear most often from vendors, and it is usually correct.
The test that matters is the remote data-processing solution boundary. A cloud component is inside the product's scope when the physical product functionally depends on that remote processing to perform a core function, and the remote software is developed by or under the responsibility of the manufacturer. Incidental cloud features are out. Load-bearing ones are in.
The reason this matters commercially is that the answer flips as products evolve. A device that phoned home for optional analytics in 2023 and now cannot boot without a licence check has moved across the line without anyone filing a scope change.
What no exclusion touches
Whichever of the above applies to you, three things are unchanged.
Your NIS2 duties. If you are an essential or important entity, you carry risk-management and supply-chain security obligations regardless of whether your products are inside the CRA. The CRA exclusion list is not a NIS2 exclusion list.
Your position as a buyer. Every organisation on this page buys products with digital elements from manufacturers who are in scope. Your suppliers' CRA posture is a live procurement question from 11 September 2026, when their reporting obligation starts. See what to ask suppliers of products with digital elements.
Your DORA obligations, if you are a financial entity. Different instrument, different clock, same underlying incident.
How to run the scoping decision so it survives review
The failure is not usually getting the law wrong. It is doing the analysis once, at company level, and never revisiting it.
Do it per product, and record four things for each: the intended purpose as marketed, the exclusion relied on with the article cited, who signed off, and the date. Then set a review trigger rather than a review date, because what changes scope is a product change: a new companion app, a component sold separately, a cloud dependency that becomes load-bearing, a variant that is not an identical spare part.
That is a register with owners and review triggers, which is to say it is the thing your management system already does for every other applicability question. Running it as a one-off slide in a scoping workshop is what produces the answer that falls over eighteen months later.
The CRA anticipates this, which is the part most scoping exercises miss. Where an essential requirement is not applicable to a product, the manufacturer has to include a clear justification to that effect in the technical documentation rather than simply leave it blank (Art. 13(4)). A scope decision you cannot explain is not a scope decision. That is a statement of applicability in all but name, and it is the same discipline your management system already applies everywhere else.
In Acuna, applicability is marked per requirement within a scoped framework, and the justification is recorded against the requirement rather than held in someone's head or a workshop slide. When the CRA sits on the same control set as NIS2 and DORA, a scoping decision and its reasoning have somewhere to live and something to review them against. See how a CRA programme runs alongside NIS2 and DORA.
Regulatory References