Does the CRA Apply to SaaS? The Remote Data Processing Test
"We are SaaS, so the Cyber Resilience Act does not apply to us" is half right. The half that is wrong depends on one definition, and the Commission's application guidance of 27 July 2026 now spells out how to apply it.
The Short Answer
- Standalone SaaS is not a product with digital elements. A service used in the browser, with nothing supplied to the customer, is outside the CRA. Recital 12 says cloud services "designed and developed outside the responsibility of a manufacturer of a product with digital elements do not fall within the scope of this Regulation", and the Commission's FAQ (1.2) says the same of "standalone Software-as-a-Service (SaaS)".
- SaaS is a cloud computing service under NIS2. The same recital points to Directive (EU) 2022/2555, and NIS2's own recital 33 lists SaaS among the service models of cloud computing. Providers that are medium-sized enterprises or larger are in its scope.
- A backend behind a product you ship can be part of that product. If you supply a mobile app, desktop client, CLI, SDK, on-premises agent or self-hosted edition, that is a product with digital elements, and the service it depends on can be its remote data processing solution (RDPS). Then it is covered too.
The rest of this post is about the third case, because that is where most SaaS companies actually are.
What Counts as Shipping a Product
The CRA regulates products "made available on the market": "the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge" (Article 3(22)). A free mobile app from a company that charges for the service behind it is supplied in the course of a commercial activity. So is a desktop client, a browser-installed agent, a container image customers run themselves, or a library they embed.
A product with digital elements is "a software or hardware product and its remote data processing solutions". The second half is what brings a backend in.
The Test
Remote data processing is "data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions" (Article 3(2)). The guidance (section 8.1) breaks this into one qualifier and two decisive questions.
At a distance. Relevant but not sufficient. It usually means outside the user's environment, typically in the cloud, but the guidance is explicit that on-premises servers and private clouds count just as much as a public cloud (paragraph 187).
Question 1: would the product lose a function without it? "Functions" is broader than the core purpose. The guidance lists sending commands to a device, synchronising files, onboarding the user, configuration, automated distribution of updates, and identity and access management (paragraph 190). Having a manual alternative does not change the answer. What fails the test: telemetry "collected purely for statistical purposes or future product development" (paragraph 192), and a website that only carries information about the product. An authentication portal that issues the tokens your app needs does pass it (paragraph 194).
Question 2: did you design and develop it, or have it built for you? In-house software qualifies, and so does software built "solely by or on behalf of the manufacturer, based on designs and specifications provided by it" (paragraph 195). Who operates it does not matter (paragraph 196). Applied to cloud models (paragraphs 198 to 200):
| What you run it on | Your software on top | Qualifies as RDPS? |
|---|---|---|
| Third-party IaaS | Your OS images, services, applications | Yes, if question 1 is also yes |
| Third-party PaaS | Your application | Yes, if question 1 is also yes |
| Third-party SaaS integrated into your product | Nothing; the provider built it | No; treat it as a component |
Both answers must be yes. If only the first is, the third-party service is treated "similar to third-party components": you assess the risks of integrating it, address them in your own product, and exercise due diligence comparable to Article 13(5) (paragraphs 201 and 202). The guidance's examples are a support chat embedded in a banking app and a third-party storage service behind an e-reader.
Only What the Product Talks To
The guidance draws a line that matters for any layered backend. In its banking-app example, the banking interface the app calls is an RDPS. The account-management and ledger systems behind it are not, because "the CRA covers only those parts of the system that interact directly with the product with digital elements" (section 8.3.1). Their risks still have to be assessed, and mitigated through measures such as authenticated back-end interfaces and integrity protection of the data the app receives.
It also excludes the rest of the company: HR, payroll, customer relationship management, CI/CD pipelines, and systems for penetration testing or red teaming are not RDPS (paragraph 182). Recital 11 is the basis: the RDPS requirements do not extend to "the security of a manufacturer's network and information systems as a whole".
What Changes When Your Backend Is an RDPS
The guidance puts it plainly: the manufacturer "must consider the product with digital elements as a whole, including its remote data processing solutions" (paragraph 178). In practice:
- Risk assessment. The RDPS is in scope of the cybersecurity risk assessment from the start (Article 13(2)).
- Essential requirements. Annex I applies to the product as a whole, backend included, from 11 December 2027.
- Technical documentation. Document the RDPS and any reliance on third-party infrastructure, including details of the contracted service (the guidance's smart-thermostat case, section 8.3.2).
- Reporting, already now. The guidance names Article 14 explicitly (paragraph 178). An actively exploited vulnerability in the API your mobile app calls is a vulnerability in your product, and Article 14 has applied since 11 September 2026, including to products placed on the market before 11 December 2027 (Article 69(3)). See the reporting clock and the notification template.
A Quick Classification
| Your offering | CRA | NIS2 |
|---|---|---|
| Browser-only SaaS, nothing supplied to customers | Out of scope | In scope as a cloud computing service if medium-sized or larger |
| SaaS plus a mobile app, desktop client, agent or CLI | The client is a product; the backend it calls directly is likely an RDPS | Same as above for the service |
| Self-hosted edition or container images customers run | A product; any vendor service it depends on is tested the same way | Depends on what else you provide |
| Library or SDK embedded in customers' software | A product (a component placed on the market separately) | Usually not by itself |
| Third-party SaaS you integrate into your own product | Not your RDPS; a component you assess and do due diligence on | Relevant to your supplier management if you are in scope |
Even where the CRA does not reach, a SaaS provider with customers under NIS2 or the Dutch Cyberbeveiligingswet will be asked about its security as a supplier. That is a contractual question rather than a regulatory one, and it tends to arrive as a questionnaire; see what Cbw customers may ask of their software suppliers.
Sources
- Regulation (EU) 2024/2847, Article 3, Article 13, Article 14, Article 69, recitals 11 and 12, verbatim Official Journal text on this site.
- European Commission, guidance on the application of the Cyber Resilience Act, C(2026) 5252 of 27 July 2026, section 8 (remote data processing), paragraphs 178 to 202 and use cases 8.3.1 to 8.3.3.
- European Commission, FAQs on the Cyber Resilience Act, version 1.4 of 4 September 2026, FAQ 1.2.
- Directive (EU) 2022/2555 (NIS2), recital 33 and Article 2(1), EUR-Lex.
This article reflects our reading of the Regulation and the Commission's guidance as of the date above. The guidance is not legally binding; only the Court of Justice interprets EU law authoritatively. It is not legal advice.