# The CRA and SaaS: when you are out of scope — and when you are not

Canonical: https://craguard.eu/blog/cra-and-saas-in-or-out-of-scope
Language: en
Last updated: 2026-09-02

- [CRAguard](https://craguard.eu/)/
- [Blog](https://craguard.eu/blog)/
- The CRA and SaaS: when you are out of scope — and when you are not

17 Aug 2026 · CRAguard

Summary A service as such is not a \"product with digital elements\" (recital 12), so pure SaaS is usually out of the CRA's scope. The turning point is the \"remote data processing solution\" (Art. 3): if your backend is necessary for the function of an installable client, agent or device, it counts as part of the product and the CRA applies to it. The decisive question: is there a piece the customer installs or runs?

Of all the scope questions, SaaS and the Cyber Resilience Act generate the most confusion. The short answer: **a pure cloud service is mostly outside** the scope of Regulation (EU) 2024/2847. The longer answer has one important edge — the notion of a *remote data processing solution* — and that edge is the whole point. Let's show precisely when you are out and when you are not.

## Why pure SaaS is mostly out

The regulation applies to *products with digital elements*. **Recital 12** is clear about this: a service delivered remotely (software as a service) is not, in itself, a product with digital elements within the meaning of the CRA — cloud services are covered by other legislation, chiefly NIS2. So if you run an application the customer connects to only through a browser and **installs or runs nothing**, the SaaS itself generally does not fall under the manufacturer's obligations of the CRA.

That does not mean you have no security obligations — only that **this** regulation is not the one imposing them. If you are within the scope of NIS2 (by sector and size), obligations come from there. CRA and NIS2 are covered in a separate [CRA vs NIS2 vs GDPR comparison](https://craguard.eu/blog/cra-vs-nis2-vs-gdpr).

## The edge: a "remote data processing solution"

Here comes the important exception to the exception. **Article 3** defines a product with digital elements to also include its *remote data processing solutions*. This means data processing at a distance for which the software or hardware is designed by the manufacturer and **without which the product could not perform its functions**.

In practice: if you ship a device, a mobile or desktop application, an agent or a plugin that **does not work without your cloud**, then that cloud is not treated as "just a service" but as **part of the product**. The CRA applies to the whole — to the installable piece and to the backend that is necessary for it.

Scope-checker

### Find out whether the CRA applies to you

Six questions, two minutes, no account. Get your product class and first steps.

[Start the scope-checker](https://craguard.eu/checker)

## The decision question

The whole distinction reduces to one question: **is there a part the customer installs or runs on their side, and is your cloud part necessary for its function?**

- **No, the customer installs nothing** (a pure web app in the browser) → mostly out of the CRA (recital 12). Consider NIS2 if it applies.
- **Yes, we ship a client / agent / plugin / device** → the installable piece is a product (Art. 3); the cloud necessary for it is taken with it → the CRA applies.
- **Hybrid — some functions in the browser, some via an installed agent** → the installed part and its necessary backend are assessed; the rest of the service stays out.

This is exactly the logic in our [scope-checker](https://craguard.eu/checker): the "what is the product" question separates pure SaaS from SaaS-with-a-client and sets the result accordingly.

## Common myths about SaaS

A few misunderstandings worth clearing up:

- **"We have a cloud, so we are entirely out."** Not necessarily — if you ship anything installable alongside the cloud, that piece is a product.
- **"We have a desktop client, so our whole service is under the CRA."** Also no — under the CRA are the client and the backend necessary for its function, not every feature of your platform.
- **"SaaS means no security obligations."** On the contrary — they simply come from elsewhere (NIS2, GDPR for personal data), not from the CRA.
- **"The boundary is fixed forever."** SaaS scope is being refined in the Commission FAQ; if you are an edge case, date your result and re-check it periodically.

## Three concrete examples

So it isn't just theory, three real-world situations:

- **A web CRM, entirely in the browser.** The customer signs in, installs nothing, data and logic run on your side. Mostly **out of the CRA** (recital 12). If you're in a regulated sector or hit the thresholds, consider NIS2.
- **SaaS with a sync agent on disk.** Alongside the service you ship a small application that runs on the customer's computer and synchronises files. That **agent is a product** (Art. 3), and the cloud without which the agent doesn't work is taken with it → the CRA applies to this part.
- **A platform with a public API and an official SDK.** If you distribute an SDK/library that customers integrate into their own software, that SDK is a component placed on the market separately (Art. 3) — and it's a product with digital elements, even though the platform itself is a service.

In all three, the decisive question is the same: is there a piece that runs off your server and is your backend necessary for it?

## What to take away

If you are pure SaaS, the CRA mostly passes you by today — but it is worth knowing both the reason (recital 12) and the edge (Art. 3), because adding an installable agent to your offering changes things. If you already ship a client application or a device, you are most likely a manufacturer and the dates concern you: **11 September 2026** (reporting) and **11 December 2027** (conformity and CE).

## FAQ

- **We're a pure web app with no install — are we out?** Mostly yes (recital 12). Consider NIS2 if you fall within its sectors and size.
- **We have a desktop client to a cloud — what's under the CRA?** The client and the backend necessary for its function (Art. 3), not every platform feature.
- **We distribute an SDK — is that a product?** Yes, a component placed on the market separately is a product with digital elements.
- **Does the scope change when we add an agent?** Yes — adding an installable part can bring you within the scope of the CRA.

## Why date your result

The SaaS boundary is one of the places where the Commission keeps refining its interpretation in the FAQ. If you are a borderline case, note down when and on what basis you classified yourself — just as our [scope-checker](https://craguard.eu/checker) does, tying the result to the guidance version and a date. When the interpretation shifts, you'll know what to reassess; and towards a customer or an authority, a dated decision is more credible than "we assumed we were out of scope".

## How CRAguard helps

If you are not sure which side of the edge you are on, the [scope-checker](https://craguard.eu/checker) tells you in two minutes — including the "SaaS + client" case. Once you find that the installable part is a product, the next step is [an SBOM in minutes](https://craguard.eu/blog/how-to-generate-an-sbom-in-10-minutes) for it. [Find out whether the CRA applies to you](https://craguard.eu/checker), or [join the waitlist](https://craguard.eu/#waitlist).

*This article is informational and not legal advice. It is based on Regulation (EU) 2024/2847 (Art. 3, recital 12) and the European Commission's guidance of 27 July 2026. Consult a professional on the SaaS boundary in your specific case.*

Scope-checker

### Find out whether the CRA applies to you

Six questions, two minutes, no account. Get your product class and first steps.

[Start the scope-checker](https://craguard.eu/checker)

## Sources

- [EUR-Lex — Regulation (EU) 2024/2847 (Cyber Resilience Act)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)
- [ENISA — Single Reporting Platform](https://www.enisa.europa.eu/)

---
Source: CRAguard — https://craguard.eu
