CRA for SaaS — when remote processing may bring a service into scope

There is no safe answer to “does SaaS fall under the CRA?” based only on the subscription model. CRA regulates products with digital elements, while cloud computing services — including SaaS — are also addressed by the NIS2 framework. The key question is what the product is, what software is made available on the market and whether a remote service is an integral part of a product function.

Start with architecture and the delivery model, not the marketing label.

Two questions that are often mixed together

Is the cloud service itself a product with digital elements under CRA?

Do not assume that simply because users access software through a browser.

Is the remote service part of another product with digital elements?

It can be. CRA defines a “remote data processing solution” as data processing at a distance for which the software is designed and developed by or under the responsibility of the manufacturer and whose absence would prevent the product with digital elements from performing one of its functions.

The CRA recitals give an example where a mobile application needs access to an API or database provided through a service developed by the manufacturer. In that situation, the service can fall within the product scope as a remote data processing solution.

Map the architecture before deciding scope

For a SaaS offering, describe separately:

software delivered to the customer — agent, desktop/mobile application, appliance, plugin, library;
web frontend — what the user accesses in the browser;
backend/API — functions performed remotely;
databases and processing — which remote elements are required for product functions;
third-party integrations — what is under the manufacturer’s responsibility and what is not;
market model — who makes the solution available and under whose brand;
updates — which elements are changed by the manufacturer and how they affect security;
support — how long each relevant component is maintained.

That map supports both the scope assessment and later technical documentation.

Three example situations

A. Browser-only cloud service

The user signs into a service through a browser without a separate software/hardware product being delivered. Do not jump from “SaaS” to “CRA applies”. Check the CRA definitions and current Commission guidance, and separately assess NIS2 obligations where relevant to the organisation.

B. Software product with a manufacturer-operated backend

The customer receives an application or component whose important function cannot operate without a backend designed by the manufacturer. The remote processing may be part of the product for CRA purposes.

C. A product uses an independent cloud service

Where the service is designed and developed outside the manufacturer’s responsibility, the relationship may differ from an own backend. “Data is in the cloud” does not, by itself, answer the CRA question.

These are orientation examples, not legal determinations for a specific architecture.

Why this matters operationally now

Article 14 has applied since 11 September 2026 and extends to in-scope products placed on the market before 11 December 2027.

If an offering consists of an application, component and backend, the team needs to know, for the relevant product and release:

where vulnerability reports enter;
who performs triage;
how product impact is assessed;
how fixes are released;
how users are informed;
when the CRA reporting assessment is triggered.

Without a clear product boundary, it is difficult to define T0, accountable ownership or the scope of a notification.

What to record in a SaaS scope decision

product-boundary diagram;
locally delivered elements;
remotely executed elements;
function provided by each element;
whether removing the remote element prevents a product function;
responsibility for developing the remote element;
distribution and branding model;
organisation role;
legal/guidance basis used for the assessment;
person approving the result;
next review date.

How Pulsar can help

Pulsar can retain the scope decision and supporting artefacts and connect the result to risks, documents, actions, vendors and evidence. When architecture changes in a later release, the decision can return for review instead of remaining a stale PDF.

Pulsar should not autonomously return a legally definitive “CRA applies / does not apply” answer without a reviewable basis and human approval.

See Pulsar GRC on one assessment workflow

Sources

Sources checked: 12 September 2026.