Does the CRA Apply to Your Product? A Scope Decision Walkthrough

Every obligation in the Cyber Resilience Act rests on a threshold question. Does the regulation cover your product at all. Article 2 of Regulation (EU) 2024/2847 draws that boundary with a deliberately broad general rule followed by a short list of targeted carve-outs. Getting the answer right early matters, because scope determines whether you face the Article 14 reporting obligations from 11 September 2026 and the full conformity requirements from 11 December 2027.

This post walks the scope test step by step. Once you have established that a product is covered, the follow-on questions are handled in our guides to which vulnerabilities and incidents must be reported and when CRA reporting becomes mandatory. For the provision itself, see our Article 2 explainer.

The general rule is broad by design

Article 2(1) applies the CRA to products with digital elements made available on the EU market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Three elements do the work.

• A product with digital elements. Hardware or software. That includes firmware, operating systems, embedded controllers, mobile and desktop applications, and software components supplied for integration into other products.
• Made available on the EU market. Supplied for distribution or use in the EU in the course of a commercial activity. Where you are headquartered or where the product is manufactured is irrelevant. Software developed purely for internal use and never supplied to third parties falls outside the rule.
• A data connection, direct or indirect. The connection does not need to be the product's primary function, and it does not need to be permanent or wireless.

The indirect connection criterion is the one manufacturers most often underestimate. A sensor that speaks only to a local gateway over a serial link, a controller that connects to a laptop during servicing, a device whose firmware is updated over USB. All of these have an indirect data connection and are likely in scope. If the honest answer to "can this product exchange data with anything, through any path" is yes, assume Article 2(1) is satisfied and move on to the exclusions.

Check the sectoral exclusions next

Article 2 removes products already governed by EU sector regimes that carry their own cybersecurity requirements. The excluded categories are specific.

• Medical devices and in vitro diagnostics regulated under the MDR (Regulation (EU) 2017/745) and the IVDR (Regulation (EU) 2017/746).
• Motor vehicles type-approved under Regulation (EU) 2019/2144, which implements the UNECE vehicle cybersecurity framework in the EU.
• Civil aviation products certified under the EASA framework, Regulation (EU) 2018/1139.
• Marine equipment falling under the Marine Equipment Directive (2014/90/EU).
• National security and defence products, meaning products developed or modified exclusively for national security or defence purposes, along with products specifically designed to process classified information (Article 2(6)).

Two caveats keep these exclusions narrower than they first appear. First, the exclusion follows the product's regulatory classification. A health wearable that qualifies as a medical device under the MDR is excluded, while a functionally similar wearable sold as a consumer fitness product remains in CRA scope. General-purpose IT used in hospitals is assessed under the CRA in the ordinary way unless it is itself a medical device. Second, dual-use products are in scope for their civilian market version. Selling the same product to defence customers does not remove the CRA obligations for the units placed on the general market. The exclusion covers products designed exclusively for military or national security purposes.

Spare parts get a narrow exemption

Article 2 also carves out spare parts that are made available to replace identical components in products with digital elements and that are manufactured according to the same specifications as the components they replace. The logic is continuity of repair. A like-for-like replacement should stay available without triggering a fresh compliance exercise.

The exemption is easy to lose. A replacement module that ships with updated firmware, added features, or a redesigned board is no longer an identical component built to the same specifications. At that point you are supplying a new product with digital elements and the ordinary scope rule applies.

Open-source software turns on commercial activity

Free and open-source software supplied outside a commercial activity sits outside the CRA. The pivotal question is what counts as commercial. Accepting donations without the intention of making a profit does not by itself make a project commercial. Charging for the software, selling paid support or hosted versions built around it, or shipping it inside a commercial product does. In those cases the obligations attach to the entity doing the monetising, and for integrated components they attach to the manufacturer of the final product rather than the upstream maintainers.

The regulation also created a distinct role for open-source software stewards, meaning legal persons that provide sustained support for the development of open-source software intended for commercial use without placing a product on the market themselves. Article 24 gives stewards a lighter regime than manufacturers. They must put in place a cybersecurity policy covering secure development and vulnerability handling and cooperate with authorities, but they do not carry CE marking or conformity assessment duties. If your company builds on open-source components, the practical takeaway is that the CRA obligations for your product rest with you. Upstream projects are unlikely to carry them for you.

The SaaS boundary follows the product's functions

Pure SaaS, where customers access software running on your infrastructure and no product is supplied to them, is generally outside the CRA. Cloud services of that kind are NIS2 territory rather than CRA territory.

The boundary shifts when a cloud component belongs to a product. The CRA includes remote data processing solutions in the definition of a product with digital elements where the processing is designed by the manufacturer, or under its responsibility, and its absence would prevent the product from performing one of its functions (Article 3(1) and 3(2)). A smart lock whose remote unlock feature depends on the manufacturer's cloud service cannot draw a scope line at the device casing. That cloud service is part of the product and falls inside the CRA assessment. An optional analytics dashboard sold separately, which the product functions fully without, likely stays outside.

For hybrid vendors the same product family can straddle the line. A downloadable on-premise edition is in scope as software made available on the market, while the hosted edition of the same codebase may be out of scope as a service. Map each distribution channel separately.

A stepwise decision sequence

Run each product through the questions in order and record the answer and reasoning at every step.

1. Is it hardware or software with a direct or indirect data connection? If no data connection exists under any intended or reasonably foreseeable use, the CRA does not apply.
2. Is it made available on the EU market in the course of a commercial activity? Internal-only tools and genuinely non-commercial open-source software stop here.
3. Does a sectoral exclusion apply? Check MDR, IVDR, the vehicle type-approval framework, EASA certification, marine equipment, and the national security and defence carve-out. If one applies, the CRA steps back and the sector regime governs.
4. Is it an identical spare part built to the same specifications? If yes, it is exempt. If anything about it changed, continue.
5. If it is open source, does the commercial activity test pull it in? Identify whether your organisation acts as a manufacturer, a steward under Article 24, or neither.
6. Draw the product boundary. Include any remote data processing solution the product needs to perform one of its functions. Leave standalone services outside.
7. If the product is in scope, classify it. Determine whether it is a default product or an important or critical product under Annex III or Annex IV, since that drives the conformity assessment route.

What this means for manufacturers

Treat the scope determination as a documented decision rather than a hallway conclusion. Market surveillance authorities can ask why you concluded a product is out of scope, and a written walkthrough of the sequence above is far stronger evidence than a recollection. Record the determination per product, revisit it whenever a product gains connectivity, adds a cloud dependency, or is substantially modified, and keep the reasoning alongside your technical documentation.

The deadlines give this urgency. Products in scope carry Article 14 reporting obligations from 11 September 2026 and must meet the full conformity requirements by 11 December 2027. A scope assessment finished this year leaves time to build the vulnerability handling and reporting processes the regulation expects. Our CRA guides cover the obligations that follow once a product lands in scope, and a maintained scope register gives you audit-ready evidence that the boundary was drawn deliberately.