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.
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 developed or supplied outside a commercial activity is also outside the scope. Monetising it changes the analysis, and the boundary of “commercial activity” is one of the genuinely unsettled parts of the regulation — a paid-support model around otherwise free software is not a clear case either way.
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. | Self-assessment only if you apply the relevant harmonised standards in full. Otherwise a notified body. |
| 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.