CRA vs NIS2: Which EU Cyber Rule Applies to Your Software - and Is SaaS in or Out?
The short answer: the Cyber Resilience Act (Regulation (EU) 2024/2847) applies to products placed on the EU market; NIS2 (Directive (EU) 2022/2555) applies to organisations operating essential or important services. Pure SaaS is generally outside CRA scope - but a cloud backend that is necessary for a connected product to function is inside it. Both rules can apply to the same company at the same time, for different reasons.
This article is general guidance on EU cybersecurity regulation, not legal advice. Confirm specifics against the official sources linked below or with a qualified adviser.
Key points
- CRA = product law. It regulates software and hardware-with-software placed on the EU market ("products with digital elements").
- NIS2 = organisational law. It regulates how entities in covered sectors manage cybersecurity risk and report incidents.
- Pure SaaS is generally out of CRA scope - the European Commission's March 2026 draft guidance explicitly confirms this.
- The big exception: a cloud or SaaS component that is necessary for a connected product to function is treated as part of that product under the CRA's "remote data processing solution" (RDPS) rules.
- Both can apply. A company that ships a connected device (CRA) and also operates a cloud platform in a covered sector (NIS2) faces both regimes.
- Switching from on-premise to hosted is not a free escape - it may reduce CRA exposure while pulling you into NIS2.
- Key CRA dates: reporting obligations apply from 11 September 2026; full CRA requirements from 11 December 2027.
What the CRA actually covers
The CRA regulates products with digital elements (PDEs): software, or hardware-with-software, that can connect to a device or network - including components placed on the market separately. It also covers the manufacturer's own remote data processing solutions that are necessary for the product to perform its functions.
The CRA entered into force on 10 December 2024, with main obligations applying from 11 December 2027. It is product law in the same tradition as CE marking: the obligation attaches to the act of placing a product on the market, not to operating a service.
What is clearly in scope:
- Embedded firmware, endpoint agents, operating systems, network equipment, and IoT devices marketed as discrete products
- Standalone downloadable or installable software (desktop apps, mobile apps, identity managers)
- Smart home devices, wearables, industrial controllers, connected sensors
- The cloud backend built by the same manufacturer that a connected product cannot function without
What is clearly out of scope:
- Products already covered by sector-specific EU law: medical devices (MDR/IVDR), motor vehicles, civil aviation, marine equipment
- Software developed exclusively for national security or defence purposes
- Pure SaaS - cloud-hosted applications consumed via the internet without local installation, not presented to the market as a distinct product
Does the CRA apply to SaaS? The cloud scope question
This has been the most debated question in CRA implementation circles throughout 2025 and into 2026. The answer is now clearer, though edge cases remain.
There had been debate in industry as to whether SaaS software would fall in scope of the CRA, but the Commission's March 2026 draft guidance now explicitly confirms that standalone SaaS is out of scope.
Pure SaaS offerings - cloud-hosted applications consumed via the internet without local installation and not presented to the market as a distinct product - are distinguishable as services rather than products, and may be excluded from the reach of the CRA.
The European Commission published this draft guidance on 3 March 2026 for public stakeholder consultation. The draft guidance focuses on remote data processing solutions and free and open-source software, the notion of 'support periods', as well as the interplay between the CRA and other EU legislation.
The draft guidance is not yet final. The Commission published it on 3 March 2026 for public feedback. The feedback period has closed, but the Commission has not yet formally adopted the final version. Treat it as the clearest available signal of Commission intent — not settled law.
The remote data processing solution (RDPS) exception
This is where "SaaS is out of scope" stops being the whole story.
Cloud services and products are only in scope where the cloud or SaaS component qualifies as a "remote data processing solution" (RDPS) within the meaning of the CRA - that is: (i) the RDPS processes data at a distance; (ii) the product is unable to fulfil a core function without such RDPS; and (iii) it was designed by or under the responsibility of the same manufacturer that designed the product supported by the RDPS. Only components that satisfy all three legs fall within scope as an RDPS.
Cloud solutions constitute remote data processing solutions within the meaning of the CRA only if they meet that definition. For example, cloud-enabled functionalities provided by a manufacturer of smart home devices that enable users to control the device at a distance fall within scope. On the other hand, websites that do not support the functionality of a product with digital elements, or cloud services designed and developed outside the responsibility of a manufacturer of a product with digital elements, do not fall within scope.
In plain terms: if you make a fitness wearable and your companion app's cloud backend is what actually processes the health data the device collects, that backend is part of the CRA product. If you run a generic analytics SaaS that a third-party device vendor happens to send data to, you are not in scope as an RDPS.
What NIS2 covers - and why it matters here
NIS2 (Directive (EU) 2022/2555) reshapes cybersecurity compliance across the EU, imposing uniform risk management and reporting obligations on both "essential" and "important" entities, and expanding scope beyond traditional critical infrastructure providers.
Where the CRA asks "is this product secure?", NIS2 asks "is this organisation managing its cyber risks properly?". The obligations are organisational: risk management measures, incident reporting to national authorities, supply chain security, and governance accountability.
Directive (EU) 2022/2555 applies to cloud computing services and cloud service models, such as Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS). So a SaaS company that is out of CRA scope is not unregulated - it may well be an "important entity" under NIS2 if it meets the sector and size thresholds.
Those services are already addressed by adjacent cybersecurity regimes, notably NIS2, which includes digital service providers, and DORA, specifically for financial services ICT.
The framing difference: product law vs organisational law
This table captures the core distinction:
| Dimension | CRA (Regulation (EU) 2024/2847) | NIS2 (Directive (EU) 2022/2555) |
|---|---|---|
| What it regulates | Products placed on the market | Organisations operating essential/important services |
| Core question | Is this product secure? | Is this organisation managing cyber risk? |
| Who it targets | Manufacturers, importers, distributors | Essential and important entities in covered sectors |
| SaaS/cloud | Generally out of scope (unless RDPS) | Explicitly in scope as a digital service |
| Key obligation | Essential security requirements, CE marking, SBOM, vulnerability reporting | Risk management measures, incident reporting to national authority |
| Can both apply? | Yes — to the same company for different reasons | Yes — to the same company for different reasons |
| First deadline | 11 September 2026 (reporting) | October 2024 (transposition deadline) |
The "compliance escape" that isn't one
A question that comes up regularly: if I move a feature from an on-premise component to a purely hosted service, do I exit the CRA?
Sometimes, yes - but it is not a free escape. Moving a capability from an installable component to a purely remote/hosted feature can reduce CRA exposure. But if your organisation operates that hosted service in a covered NIS2 sector (energy, health, digital infrastructure, managed services, and others), you may simply be trading one regulatory regime for another. The security obligations under NIS2 are substantial - risk management, incident reporting, supply chain due diligence - and they apply at the organisational level, not just to one product.
The architecture decision and the compliance decision need to be made together.
A practical decision flow
Ask these questions in order:
Is it a product placed on the market? Software or hardware-with-software that you sell, distribute, or make available - including open-source with commercial activity - is likely a PDE. -> CRA applies.
Is it a pure service you operate? A hosted application with no installable component, not presented as a product, consumed via the internet. -> CRA generally does not apply. Check NIS2.
Is the cloud part necessary to the product's function? If you also make a connected product and your cloud backend is what makes it work, that backend is an RDPS. -> CRA applies to the RDPS as part of the product.
Does your organisation operate services in a covered NIS2 sector? Energy, transport, banking, health, digital infrastructure, managed services, digital providers (cloud, online marketplaces, search engines), and more. -> NIS2 may apply regardless of CRA status.
Could both apply? A company shipping a connected device (CRA) that also operates a cloud platform in a covered sector (NIS2) faces both. They regulate different things and do not cancel each other out.
Not sure where your product sits? Start with our CRA Scope Checker for a structured walkthrough, then check the CRA Deadlines guide to understand what you need to do and by when. If you are in scope, the SBOM guide and compliance checklist are your next stops.
For ongoing updates as the Commission finalises its guidance, subscribe to The CRA Brief — a plain-English newsletter covering CRA developments as they happen.
Where things stand in 2026
On 3 March 2026, the European Commission published its first draft guidance on the CRA. With the first CRA obligations starting to apply from June and September 2026, this guidance is the clearest signal yet of how the Commission expects manufacturers and other economic operators to apply the new rules in practice.
The themes highlighted by the Commission include remote data processing solutions, free and open-source software, support periods, and the interplay between the CRA and other EU legislation.
CRA implementation projects reveal some legal uncertainty on key questions on the CRA's scope and key obligations - particularly the determination of in-scope products, especially with regard to remote data processing solutions and free and open-source software.
The SaaS/product boundary is a live question. Legal commentary from early 2026 - including DLA Piper's analysis of "the fine line between SaaS and digital products" - highlights that the RDPS edge is exactly where scope assessments most often go wrong. The Commission's draft guidance sharpens the three-part RDPS test considerably, but edge cases still turn on the specifics of your architecture and how your product is presented to the market.
If your situation is anything other than clearly in or clearly out, confirm it against the regulation text and, where the stakes are high, with a qualified adviser.
Related reading
The CRA Support Period: It's Not a Flat Five Years
The CRA support period is not a flat five-year rule. It's the expected product lifetime - and at least five years. Here's how to set, justify, and communicate yours.
Article 13 CRA Risk Assessment: The Document That Holds Everything Together
Article 13 of the Cyber Resilience Act requires a documented cybersecurity risk assessment before CE marking. Here's what it must cover, why it's load-bearing, and how to build one.
How to Build a CRA-Compliant Coordinated Vulnerability Disclosure Policy
The CRA requires a CVD policy and a reachable contact point. Here's exactly what to put in it - and how it differs from the mandatory 24h/72h ENISA reporting clock.