CRA vs NIS2: which one applies to you
Short answer. The difference is the thing being regulated.
- The CRA regulates a product. Does this thing you place on the EU market meet the security requirements, and can you prove it? Output: a technical file, a declaration of conformity, CE marking.
- NIS2 regulates an organisation. Are you an entity of a certain size in a listed sector, and are you managing your own cyber risk? Output: risk-management measures, governance duties, incident reporting about your own services.
So: the CRA asks what you sell. NIS2 asks what you are. Many businesses answer both, and the answers are independent.
Most of the confusion here is a category error rather than a close call. People try to work out which of the two regimes “covers cybersecurity” for them, as though they were alternatives. They are not alternatives and they do not compete. They attach to different things and can both attach at once.
Side by side
| Cyber Resilience Act | NIS2 | |
|---|---|---|
| Instrument | Regulation (EU) 2024/2847 | Directive (EU) 2022/2555 |
| Attaches to | A product with digital elements placed on the EU market | An entity operating in a listed sector |
| Trigger question | Do you make, import, distribute or rebrand this product? | What sector are you in, and how big are you? |
| Size threshold | None. Size affects documentation depth, not applicability | Generally medium-sized and large entities |
| What you produce | Technical documentation, EU declaration of conformity, CE marking, user information, a vulnerability-handling process | Risk-management measures, governance and management accountability, business continuity, supply-chain security, registration with the authority |
| Reporting is about | Your product: an actively exploited vulnerability in it, or a severe incident affecting its security | Your services: a significant incident affecting what you operate |
| Enforced by | Market surveillance authorities — the CE-marking enforcement machinery | National competent authorities designated under NIS2 |
| National law needed? | No — directly applicable across the EU | Yes — transposed into each Member State's own law |
| Cloud services | Generally outside, unless remote data processing essential to a product's function | Inside — cloud computing services are a listed sector |
Regulation versus directive, and why it changes your homework
This distinction is not academic and it changes what you have to read.
The CRA is a regulation. It applies directly and identically in every Member State. You can read Regulation (EU) 2024/2847 and know your obligations, and a product compliant in Sweden is compliant in Spain. The only thing that varies by country is the penalty regime, because Article 64 requires Member States to legislate that part themselves.
NIS2 is a directive. It sets what Member States must achieve, and each one transposes it into national law — so your actual obligations live in your country's implementing act, which may go further than the directive, define significance thresholds its own way, and name its own authority and reporting portal. Reading the directive tells you the shape of your duties. It does not tell you what they are.
Practically: for the CRA, read the regulation. For NIS2, find your national law.
Where SaaS lands, and the one exception
This is the single most common scope question, and the regulation's own recitals answer it.
Recital 12 notes that Directive (EU) 2022/2555 applies to cloud computing services and cloud service models, such as Software as a Service, Platform as a Service or Infrastructure as a Service. The CRA's subject matter is products placed on the market — a defined concept from EU product law, meaning made available for distribution or use in the course of a commercial activity. A service customers log into is not a product being placed on the market. So pure SaaS sits under NIS2, if it sits anywhere.
The exception is remote data processing, and Recital 11 defines it tightly: data processing at a distance for which the software is designed and developed by or on behalf of the manufacturer of the product concerned, the absence of which would prevent the product from performing one of its functions.
Read that test in three parts, because all three have to hold:
- There has to be a product. Something placed on the market — a device, or software people install.
- You have to have built the remote part, or had it built for you.
- The product has to stop doing one of its functions without it. Not “worse without it”. Not “loses a nice-to-have”. Prevented from performing a function.
So the smart thermostat and the cloud backend it cannot work without are one regulated object under the CRA. The analytics dashboard you also happen to sell, which customers use on its own in a browser, is a service. And a business selling both has a product duty for the first and an organisational duty for the second.
Two things follow. First, if your product sits near that boundary, the decision is worth documenting with your reasoning rather than assumed, because your reasoning is what you will be asked for. Second, this is an area where later Commission guidance can move the answer, so treat your conclusion as dated rather than settled.
The size threshold: NIS2 has one, the CRA does not
This catches people out more than any other difference, and it catches out exactly the businesses least equipped to handle it.
NIS2 is generally built around medium-sized and large entities in its listed sectors, which leaves most micro and small businesses outside it — subject to specific provisions and national choices that can pull particular entities back in regardless of size.
The CRA has no such threshold. There is no headcount below which a manufacturer stops being a manufacturer. A sole trader in Melbourne selling a connected device into Germany has the same set of obligations as Siemens: build to Annex I, compile the Annex VII technical documentation, sign the Annex V declaration, affix CE marking, run a vulnerability-handling process, report under Article 14, retain for ten years.
What size does change is narrower than people hope:
- A simplified technical documentation form is contemplated for micro, small and medium-sized enterprises, including for microenterprises specifically — a lighter format for the same content, not an exemption from having it.
- One penalty derogation. Article 64(10)(a) disapplies administrative fines for micro and small manufacturers that miss the 24-hour early-warning deadline — and only that deadline.
- Proportionality in setting a fine. Article 64(5) requires authorities to give due regard to the size of the operator when deciding an amount.
So the mental model “we are too small for EU cyber rules” may be right about NIS2 and is wrong about the CRA. That asymmetry is the most consequential line on this page for a small manufacturer.
When both apply
Consider four businesses:
| Business | CRA? | NIS2? |
|---|---|---|
| Two-person company selling a downloadable desktop application in the EU | Yes — software placed on the market | No — below the size threshold, and not an operator of a listed service |
| Mid-sized SaaS company, no downloadable product, hosting for EU customers | No — a service, not a product | Likely — cloud computing is a listed sector |
| Industrial manufacturer, 400 staff, sells connected machinery and runs its own plants | Yes — products with digital elements | Likely — size plus a listed sector such as manufacturing |
| Importer bringing a connected consumer device into the EU, 15 staff | Yes — importer obligations | Probably not — below the threshold |
Where both apply, they are two compliance tracks and neither discharges the other. The useful overlap is evidential rather than legal: the vulnerability-handling process the CRA requires in Annex I Part II, and the incident-response and supply-chain measures NIS2 requires, are close enough in practice that one well-built process can supply evidence for both. The documents and the filings stay separate.
Two reporting duties, two destinations
Both regimes make you report, on deliberately similar clocks, about different subjects.
| CRA, Article 14 | NIS2, Article 23 | |
|---|---|---|
| What is reportable | An actively exploited vulnerability contained in your product; a severe incident having an impact on the security of your product | A significant incident affecting the services you provide |
| First step | Early warning within 24 hours | Early warning within 24 hours |
| Second step | Notification within 72 hours | Incident notification within 72 hours |
| Final step | Final report — for a vulnerability, within 14 days of a corrective or mitigating measure becoming available | Final report within one month of the 72-hour notification |
| Where it goes | Your CSIRT designated as coordinator, and ENISA, through the single reporting platform | Your CSIRT or competent authority under your national law |
The overlap in the clocks is not a coincidence — the CRA's reporting architecture was deliberately built to sit alongside NIS2's rather than cut across it. But the subject of the report differs, and so does the destination. A ransomware incident at a connected-device manufacturer that both disrupts its own operations and affects the security of its shipped product can require two filings, to two places, on two clocks. That is a scenario worth rehearsing on paper before it happens, because 24 hours is not enough time to work out who to tell.
When neither applies
It does happen, and it is worth checking rather than assuming the opposite.
- A small consultancy, agency or professional services firm. No product placed on the market, below the NIS2 threshold, not a listed operator. Your clients' contracts may impose security obligations; neither of these instruments does.
- A small internal-tools team. Software built for use inside your own organisation and not made available on the market is not placed on the market.
- Products already covered by another EU regime. Medical devices, road vehicles and their parts, civil aviation and marine equipment are excluded from the CRA because those regimes set the cybersecurity requirements instead. That is an exclusion from the CRA, not from regulation.
Working out which is which for you
Two questions, asked separately. Do not try to answer them together.
Question one, about the CRA: do you place a product with digital elements on the EU market — as manufacturer, importer, distributor or under your own brand? If yes, the CRA applies, at any company size. Then classify it, because classification decides whether you can self-assess.
Question two, about NIS2: is your organisation in one of the listed sectors, and at or above the size threshold in your national implementing law? If yes, NIS2 applies to your operations. Then read your national act, not the directive.
The answers are independent. Getting a “no” on one tells you nothing about the other.
An honest note on confidence: the CRA-side statements here rest on work checked against multiple reproductions of the relevant articles and recitals. The NIS2-side statements are deliberately general — the size thresholds, the significance thresholds for an incident, the designated authority and the reporting portal are all matters of national transposition and vary between Member States, so nothing on this page should be relied on as a statement of your national NIS2 obligations. The four example businesses in the table above are illustrations of how the two tests operate, not determinations. Nothing here is legal advice.
If the CRA is the one that applies, the file is the work
Every document the regulation asks for, written for your product from one questionnaire, kept current as the standards underneath it land, and versioned and dated for the ten years the regulation requires.
Not sure which side of the product-versus-service line you are on? The free check asks that question directly and tells you.