Does the Cyber Resilience Act apply to your product?
Short answer. If you place a product with digital elements on the EU market, yes — unless another EU regime already covers it, or what you sell is a service rather than a product. Hardware with software in it, firmware, downloadable apps and desktop programs, and components other manufacturers build on are all in scope. Pure software-as-a-service, where nothing is installed, generally is not.
There is no exemption for small companies. A two-person manufacturer has the same obligations as a large one.
- Test one: do you place it on the EU market?
- Test two: is it a product, or a service?
- Test three: does another EU regime already cover it?
- Free and open-source software, and stewards
- Which category, and which conformity route
- Manufacturer, importer or distributor
- What you actually have to hold
- The dates
The Cyber Resilience Act — Regulation (EU) 2024/2847 — covers “products with digital elements”. That phrase is doing a lot of work, and most of the confusion about who is affected comes from three separate questions being treated as one. They are independent, and the order matters: fail the first and nothing else is relevant.
Test one: do you place it on the EU market?
The regulation applies to products made available on the EU market, regardless of where the manufacturer is. A company in Taipei, Bangalore, Austin or Melbourne selling into the EU is in scope; being outside the Union is not a defence, and there is no minimum volume.
Selling nothing into the EU puts you outside the regulation entirely. If you are planning to, you will be in scope when you do — and the documentation has to exist before the product is placed on the market, not after.
Test two: is it a product, or a service?
This is the test that catches people out, and the answer turns on how the thing is delivered rather than on what technology it uses.
In scope: anything a customer installs or takes delivery of. Hardware with software inside it. Firmware. A desktop program. A paid mobile app from an app store. A downloadable browser extension. A library, SDK or chip that other manufacturers build into their own products.
Generally out of scope: a cloud-hosted application that customers use over the internet, with nothing installed locally, sold as a service rather than as a distinct product. That is a service, and its cybersecurity obligations come from NIS2 rather than the CRA.
The exception, and it is a real one
Remote data processing is pulled into scope when it is essential to the core function of a product you also place on the market. A connected sensor whose backend the device cannot work without is not a separate service — it is part of that product and is covered along with it.
So the question is not “do we run servers?” It is: does something we sell as a product stop working if this service goes away? If yes, the service is in scope. If your customers just log in and use the service itself, it is not.
A plugin or extension sits on the line, and the line is the same one: if the customer installs it, it behaves like a product; if it is hosted and consumed through a platform, it behaves like a service. This is a genuine grey area and worth a conversation with whoever handles your conformity work.
Test three: does another EU regime already cover it?
Some sectors are carved out because another regulation already sets their cybersecurity requirements. If your product falls in one of these, the CRA does not add to it:
| Excluded | Covered instead by |
|---|---|
| Medical devices | The Medical Devices Regulation and IVDR |
| Road vehicles and parts | The type-approval regulation for motor vehicles |
| Civil aviation | The civil aviation safety regulation |
| Marine equipment | The Marine Equipment Directive |
| Defence and national security | Outside the regulation’s purpose entirely |
Free and open-source software, and the steward regime
The regulation applies to products made available on the market in the course of a commercial activity. So the open-source question is not whether the software is free. It is whether it is monetised.
On the recitals' own account of that test:
| Situation | Commercial activity? |
|---|---|
| You charge a price for the software | Yes |
| You charge for technical support, and the charge does more than recover your actual costs | Yes |
| You intend to monetise it — hosting, a dual licence, advertising, personal data | Yes |
| It is free and open source and its manufacturers do not monetise it | No |
| You accept donations, without the intention of making a profit | No, on its own |
| You publish regular releases | No, on its own |
| A company gives the project financial support | No, on its own |
| A not-for-profit organisation develops it, and all earnings after costs go to its not-for-profit objectives | No |
Read that list as a whole and the shape is clear: the regulation is trying to leave genuine volunteer and foundation-run open source alone, and to catch businesses whose product happens to be open source. The paid-support model is the case that most clearly is commercial, because charging for support beyond cost recovery is named in the test.
The steward regime is a third answer, not a lighter version of the second
Between the volunteer project and the manufacturer sits a category most summaries miss: the open-source software steward. A steward is a legal person — a company, foundation or association, expressly not an individual maintainer — that systematically provides sustained support for the development of open-source products intended for commercial activities, and that is not itself the manufacturer.
A steward is in scope, and has its own regime in Article 24, which is three paragraphs long:
- Put in place and document in a verifiable manner a cybersecurity policy covering secure development and vulnerability handling.
- Cooperate with market surveillance authorities at their request, supplying documentation in a language they can readily understand.
- A narrowed slice of the Article 14 reporting duties, applying to the extent the steward is involved in the development, and — for severe incidents — to the extent those incidents affect the network and information systems the steward provides for that development.
And what a steward does not do is the more striking half of the list. A steward cannot affix the CE marking. There is no technical documentation under Article 31, no declaration of conformity, no SBOM duty and no Annex I conformity assessment. The entire document set this regulation is known for does not apply.
1. The commercial-activity boundary is genuinely unsettled at the edges. The clear cases are clear. A project with one corporate sponsor, a paid hosted version and a free download is not, and reasonable advisers differ. If you are near the line, the useful move is to write down which limb of the test you think you fall on and why — that reasoning is what you would be asked for.
2. The list of what a steward does not produce comes from the open-source sector's own trade body, the Open Regulatory Compliance Working Group, rather than from a regulator or a law firm. It is consistent with the structure of Article 24, which creates no document duties. But it is one operator's reading of an exclusion, and an exclusion is exactly the kind of statement worth a second source before you rely on it.
3. Whether Article 14's CSIRT routing machinery travels with the duties Article 24(3) imports is not stated anywhere we have found. Article 24(3) applies the obligations in Article 14(1); whether the routing rules in the later paragraphs come with them is an inference, and we are not going to present an inference as the answer to “who do I report to”.
Which category, and which conformity route
Being in scope is not the same as needing an external assessor. The regulation sorts products by what security job they do, and the great majority land in the default category, where you assess your own product and sign your own declaration.
| Category | What lands here | Route |
|---|---|---|
| Default | Products performing none of the security functions the regulation singles out. Most products, including most sensors, instruments, apps and consumer hardware. | Self-assessment. No notified body, no external audit, no certification fee. |
| Annex III Class I | Identity and access management, password managers, operating systems, routers and switches, network monitoring, VPNs, antivirus, boot managers, certificate issuance, browsers, microcontrollers with security features, smart home hubs and voice assistants, connected toys, personal wearables that monitor health. | A notified body, on today’s reading. Article 32(2) removes self-assessment where the relevant harmonised standards have not been applied in full — and where such standards do not exist. The CRA’s do not exist yet. |
| Annex III Class II | Hypervisors and container runtimes, firewalls and intrusion detection and prevention systems, tamper-resistant microprocessors and microcontrollers. | Notified body required. Third-party conformity assessment. |
| Annex IV — critical | Hardware devices with security boxes, smart meter gateways within smart metering systems, smartcards and similar devices including secure elements. | The heaviest route: European cybersecurity certification or a notified body. |
Manufacturer, importer or distributor
Three roles, three different sets of duties:
- Manufacturer — you carry the full set: the essential requirements, the technical documentation, the declaration of conformity, the vulnerability-handling duties and the reporting obligation.
- Importer — you must verify that the manufacturer did the conformity assessment and that the documentation exists before you place the product on the EU market. You cannot take it on trust.
- Distributor — you must act with due care, and not make available a product you know or ought to know does not conform.
The trap: if you place a product on the market under your own name or trademark — rebranding another manufacturer’s hardware, white-labelling an OEM device — you are treated as the manufacturer, with the full set of manufacturer obligations, even though you designed and built none of it. Companies that think of themselves as resellers are often manufacturers in law.
What you actually have to hold
For an in-scope product in the default category, five things:
| Reference | Document |
|---|---|
| Annex VII | The technical documentation — product description, architecture, vulnerability-handling processes, software bill of materials, your risk assessment against each essential requirement, the support-period justification, standards applied, and test reports. |
| Annex V | The EU declaration of conformity, in eight components. This is the document the CE marking rests on. |
| Annex II | Information and instructions for the user, in nine points, shipped with the product — including the vulnerability-reporting contact and the date your security updates stop. |
| Annex I Pt II | A published coordinated vulnerability disclosure policy, and the contact address that goes with it. |
| Article 13 | The justification for your support period — not the date, the reasoning. At least five years unless the product is expected to be in use for less. |
And then you keep them. Article 13 sets out three separate ten-year retention duties running on three different clocks: each security update from the day it is issued, the technical documentation and declaration of conformity from the day the product is placed on the market, and the user information from that same day. Three clocks, per product, per update, per document version — which is why a folder of PDFs on a laptop fails this within a couple of years without anyone noticing.
The dates
| Date | What happens |
|---|---|
| 11 Sep 2026 | Already in force. Reporting of actively exploited vulnerabilities and severe incidents: 24 hours for an early warning, 72 hours for the notification, then 14 days after a fix exists for a vulnerability or one month after the 72-hour notification for a severe incident. Filed by hand on ENISA’s Single Reporting Platform, which needs an account registered in advance. |
| 31 Oct 2026 | First tranche of harmonised standards expected |
| 31 Dec 2026 | Second tranche expected |
| 30 Oct 2027 | Third tranche expected |
| 11 Dec 2027 | Full application. Without the documentation there is no CE marking, and without the CE marking there is no EU sale. |
Those standards dates have already moved once, and only a fraction of the standards will carry presumption of conformity — several of the central technical references, including the IEC 62443 series, are not expected to be listed in the Official Journal at all. Practically, that means the correct answer to the “standards applied” part of your technical file changes more than once between now and full application.
The ceiling on administrative fines for breaching the essential requirements or the Article 13 and 14 obligations is €15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher. Enforcement is national and has to be proportionate, so a small manufacturer is not realistically facing €15m — but that is the number the regulation sets.
One deliberate omission: this page never cites sub-paragraph labels within Article 14(7). Published versions of that paragraph disagree on its internal numbering, so a sub-label would look precise while being unreliable. The rule is quoted instead.
Work out your own category in two minutes
Eight questions, no email needed. You get your conformity route, every document that applies to you, and where each requirement comes from.
Or see what it costs to have all five documents written for your product and kept current as the standards land — €390 a year.