CRA for SaaS and Remote Data Processing: When Your Cloud Backend Is In Scope

Most SaaS teams reading the Cyber Resilience Act have quietly decided it is about firmware and shipped software, and that their cloud backend, being a service they operate rather than a thing they place on the market, sits outside it. For a meaningful slice of them, that reading is wrong — and the part of the estate they have mentally excluded is exactly the part that carries product-level duties.

The Cyber Resilience Act — Regulation (EU) 2024/2847 — is written around products. It entered into force on 10 December 2024, its vulnerability and incident reporting obligations begin to apply on 11 September 2026, and the main body of manufacturer obligations applies from 11 December 2027. Because the whole apparatus talks about “products with digital elements”, conformity assessment and CE marking, teams that ship a hosted service rather than a boxed one assume the whole thing is someone else’s problem. The definitions do not support that assumption as cleanly as people would like.

The definition that pulls the backend in

Article 3 defines a “product with digital elements” as a software or hardware product and its remote data processing solutions. That last clause is the one to sit with. The product is not just the thing on the device or the client in the user’s hands; it expressly includes the remote processing the product depends on.

“Remote data processing” is then defined as data processing at a distance for which the software is designed and developed by the manufacturer, or under the manufacturer’s responsibility, and the absence of which would prevent the product from performing one of its functions. Read those two definitions together and the boundary becomes clear: if you build a backend without which your product stops doing something it is meant to do, that backend is part of the product for CRA purposes. It does not matter that you never “placed it on the market” as a separate artefact. It is in scope by attachment.

Where “integral to the product” is actually judged

The test is not “does this run in the cloud”. It is two questions asked together: did you build it (or have it built under your responsibility), and would the product lose a function without it. Both have to be true.

Consider a connected device or an app whose core feature is that data syncs, is analysed server-side, and comes back. Strip the backend out and the feature dies. That backend is the manufacturer’s, and it is functionally load-bearing — it is in scope. Now consider the same product using a general-purpose analytics service or a third-party cloud platform that the product happens to call but that exists independently of it. That service was designed and developed outside your responsibility; it is not your remote data processing solution. The distinction is authorship plus necessity, not deployment location.

This is where most teams misclassify. They look at where the code runs and conclude “cloud, therefore service, therefore not a product”. The regulation looks at whether the code is theirs and whether the product needs it. A backend you wrote, that your product cannot function without, is a product component regardless of the fact that you operate it as a live service.

SaaS as a service is out — but that is not the whole story

The counter-argument people reach for is real, and it is worth stating precisely so you do not over-correct. Recital 12 makes clear that cloud services designed and developed outside the responsibility of a manufacturer of a product with digital elements do not fall within CRA scope, and it points to Directive (EU) 2022/2555 — NIS2 — as the instrument that applies to cloud computing and Software-as-a-Service models. So a pure SaaS offering, sold and consumed as a standalone service, is generally not a CRA product. It is governed elsewhere.

The trap is treating that as a blanket exemption for anything you host. The exemption is about SaaS as the service you sell. It does not reach back and rescue a backend that is the remote data processing solution of a product you also place on the market. If you ship an app, a device or a downloadable client, and that client leans on a backend you built to do its job, you can be a SaaS operator for one purpose and a product manufacturer for another at the same time. The two characterisations are not mutually exclusive, and firms that assume the SaaS label settles the question tend to discover otherwise when someone maps the product boundary properly.

What the backend inherits once it is in scope

Scope is not an academic label. Once a backend is treated as part of the product, it carries the essential cybersecurity requirements in Annex I, the obligation to handle vulnerabilities across the support period, and the reporting duties that begin in September 2026. It has to be reflected in the conformity assessment and in the technical documentation that supports the CE marking of the product it belongs to. The evidence a market surveillance authority asks for — the CRA technical file — has to describe the backend as part of the product, not as an off-stage service you decline to document.

The enforcement weight behind that is not trivial. Non-compliance with the essential requirements and the core manufacturer obligations can attract administrative fines of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. That is the exposure sitting behind a scope call that a lot of teams are making by instinct rather than by reading the definitions.

Drawing the boundary around your architecture

The useful work here is neither over-scoping nor under-scoping. Over-scoping means dragging your entire cloud estate — internal tooling, analytics, unrelated services — into a product conformity exercise it does not belong in, which is expensive and dilutes the evidence for the parts that genuinely matter. Under-scoping means the classic error above: leaving out a backend a supervisor will treat as in scope.

Do it component by component. For each service in the estate, ask the two questions: is this designed and developed by us or under our responsibility, and would a product we place on the market lose a function without it. Where both are yes, that service is a remote data processing solution and inherits product duties. Where the service is third-party and independent, or where it supports the business but no shipped product depends on it, it is out — though it may well be caught by NIS2 in its own right, which is a separate assessment you should not conflate with this one.

The mapping exercise is worth doing carefully because the same architectural instincts that make backends replaceable also make them auditable. Teams that already think hard about coupling — the kind of discipline that shows up in functional equivalence and cloud exit work, or in how they select a data platform and manage lock-in — usually find the CRA boundary easier to draw, because they already know which services their product genuinely cannot live without and which it merely calls.

The teams that will get caught are not the ones who read the regulation and disagreed with it. They are the ones who never looked, because the word “product” told them it did not apply, and the backend that was quietly holding the product together was never on anyone’s list.