CRA scope
The Cyber Resilience Act covers products with digital elements placed on the EU market that have a data connection to a device or network. That is a wide net, and the exclusions are narrower than most manufacturers assume. This page sets out what counts as a product, who carries which obligations, which sectors are carved out and why, and the four boundary calls that decide most real cases.
The scope in one paragraph
Article 2(1) applies the CRA to products with digital elements made available on the market, where the intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. A product with digital elements is a software or hardware product together with its remote data processing solutions, including components placed on the market separately. Article 2 then removes products already carrying cybersecurity duties under a sector regime, plus spare parts and defence products. The Regulation applies in full from 11 December 2027, with the Article 14 reporting duty arriving earlier on 11 September 2026.
Two consequences catch people out. The trigger is the data connection rather than the product being obviously a computer, so a mechanical product with one network-capable microcontroller in it is likely inside. And the exclusions are single-regulation provisions rather than exemptions, so an excluded product is regulated for cybersecurity by its own regime instead of by this one.
What is excluded, and what regulates it instead
Every exclusion in Article 2 exists because another instrument already carries the cybersecurity duty. None of them means the product is unregulated.
| Excluded | Regime that applies | What that means in practice |
|---|---|---|
| Medical devices and IVDs | Art. 2(2)(a)-(b) — Reg. (EU) 2017/745 and 2017/746 | Cybersecurity duties, post-market surveillance and incident reporting already run through MDR and IVDR, enforced by notified bodies and EUDAMED. Software that is itself a medical device is excluded with the device. General-purpose software that merely interfaces with one is not automatically excluded. |
| Type-approved vehicles | Art. 2(2)(c) — Reg. (EU) 2019/2144 | UNECE WP.29 requires a cybersecurity management system maintained across the vehicle lifecycle. Components designed and constructed exclusively for integration into covered vehicles are out of scope too, but selling a generic equivalent through channels open to the general public brings it back in whatever the stated intended use. |
| Certified aviation products | Art. 2(3) — Reg. (EU) 2018/1139 | EASA certification already covers security assessment for aircraft software and systems. The carve-out reaches products certified in accordance with that Regulation, which is narrower than the aviation sector as a whole. An uncertified product sold into aviation is not excluded by this paragraph. |
| Marine equipment | Art. 2(4) — Directive 2014/90/EU | A full carve-out for equipment falling within the marine equipment Directive, and the one most often left out of published scope summaries. A supplier of covered bridge, navigation or safety equipment is outside the CRA for those products and inside it for everything else it sells. |
| Spare parts | Art. 2(6) | Reaches spare parts made available to replace identical components and manufactured to the same specifications as the components they replace. The wording is narrow. A replacement part that is improved, redesigned or built to a different specification falls outside the exclusion, so a whole spares catalogue rarely qualifies as a block. |
| Defence and classified | Art. 2(7) | Products developed or modified exclusively for national security or defence purposes, and products specifically designed to process classified information. Dual-use products are not automatically excluded. Where a civilian version is made available on the general market, the CRA applies to that version. |
Manufacturers operating across several of these should document which framework applies per product line. A single company can be inside the CRA for one product and outside it for the next.
Four boundary calls that decide most cases
The Regulation is broad and the edges were settled by Commission guidance C(2026) 5252 rather than by its own text.
Web applications are generally out
For software to fall within the CRA it must be provided to a user, obtained by that user, and operated on or as part of an electronic information system on the user's side. Software that executes remotely and is merely accessed through a browser does not meet that description, which covers most web applications including progressive web apps. Websites are not products with digital elements in themselves.
Delivery model decides it, not technology
A desktop application built with web technologies but packaged for local installation is a product with digital elements. So is a browser extension, and so is a mobile application downloaded from an app store. The same codebase can land on either side of the line depending on how the user obtains and runs it.
Hardware and its necessary software are one product
Software needed for hardware to perform its intended functions forms a single product with that hardware, even where the software arrives through a separate channel after the hardware was placed on the market. Printer drivers and companion apps for wearables both sit on this side.
A backend can pull you in as remote data processing
A website or hosted service enters scope where it supports the functionality of a product, which makes it a remote data processing solution. The question is whether the product could deliver its intended functions without it. This is the route by which a manufacturer with a hardware product finds its cloud backend inside the technical file.
Who is in scope, and for what
Scope is not a single yes or no. The same product carries different duties depending on which role you occupy in the supply chain.
| Role | Who this is | What it carries |
|---|---|---|
| Manufacturer | Develops or manufactures the product, or has it developed or manufactured, and markets it under its own name or trademark. | The full weight. Annex I essential requirements, risk assessment, technical documentation, conformity assessment, CE marking, support period, vulnerability handling, and the Article 14 reporting cascade. |
| Importer | Places on the EU market a product from a manufacturer established outside the Union. | Verification duties. Confirm the conformity assessment was carried out, the technical documentation exists, the CE marking is affixed, and the product carries contact details. An importer who markets under its own name becomes a manufacturer. |
| Distributor | Makes a product available on the market without being the manufacturer or importer. | Due care. Check the CE marking and documentation are present, do not supply a product you know or should know is non-conforming, and inform the manufacturer and authorities where you find one. |
| Open-source steward | A legal person, other than a manufacturer, providing systematic and sustained support for the development of free and open-source products intended for commercial activities. | A lighter regime under Article 24. A documented cybersecurity policy, cooperation with market surveillance authorities, and vulnerability reporting. No conformity assessment, no CE marking, no declaration of conformity. |
The role can change under you. An importer or distributor that markets a product under its own name or trademark, or modifies a product substantially, becomes the manufacturer of it and picks up every manufacturer obligation.
Open source sits on a spectrum
The test is commercial activity rather than licence. Free and open-source software developed and supplied outside a commercial activity is outside the scope. Monetisation through support contracts, managed services or integration into a commercial product brings the monetising entity in as a manufacturer.
Between those two positions the Act creates the open-source software steward, a legal person other than a manufacturer that provides systematic and sustained support for the development of open-source products intended for commercial activities. Article 24 gives stewards a documented cybersecurity policy, cooperation with market surveillance authorities and vulnerability reporting, and stops short of conformity assessment, CE marking and a declaration of conformity.
For most commercial software companies consuming open-source components, the obligations flow to the manufacturer of the final product rather than upstream to the project maintainers. That does not remove the component due diligence duty, which stays with you.
Frequently asked
What is the scope of the CRA?
What is a product with digital elements?
Does the CRA apply to web applications?
Does the CRA apply to open source software?
Does the CRA apply to software developed in-house?
Does the CRA apply to companies outside the EU?
Are medical devices covered by the CRA?
Settle the scope question for your product
The classifier walks the scope test and the Annex III and Annex IV categories against your product, then returns whether the CRA applies, which class you land in, and the conformity route that follows, with reasoning you can put in the technical documentation.
Free, no account needed to run it. EU data residency by default.
CVD Portal supports CRA compliance work but does not provide legal advice and does not by itself establish conformity or a presumption of conformity. It is an independent platform, not affiliated with or endorsed by the EU or ENISA.