CRA Remote Data Processing and SaaS Scope Explained

Under the Cyber Resilience Act (CRA), a cloud backend can become part of a product with digital elements when the product depends on that remote service to perform one of its functions. The CRA calls this a remote data processing solution. The practical boundary is not whether something is marketed as SaaS, cloud, API or backend, but whether it is manufacturer-controlled software whose absence would prevent the product from performing a function.

This distinction matters for connected devices and software products that rely on remote APIs, databases, identity services, control planes or manufacturer-hosted application logic. Recitals 11 and 12 and Article 3(2) make clear that some remote services belong inside the CRA product boundary, while unrelated websites and cloud services outside the manufacturer's responsibility do not.

The CRA's main obligations apply from 11 December 2027. Reporting obligations under Article 14 have applied since 11 September 2026. Teams designing or maintaining connected products can use the remaining implementation period to document which remote services are actually part of each product, who controls them, and what cybersecurity evidence covers the combined local and remote system.

Start with the legal definition, not the cloud label

Article 3(1) defines a product with digital elements as a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately.

Article 3(2) then defines remote data processing as data processing at a distance where two conditions are met:

the software is designed and developed by the manufacturer, or under the manufacturer's responsibility; and
without that remote processing, the product with digital elements would be unable to perform one of its functions.

Both conditions matter. A service does not become part of the CRA product simply because the product sends data to it. Equally, a manufacturer cannot assume that a backend is outside the product merely because it runs in the cloud rather than on the user's device.

The scope analysis should therefore begin with architecture and responsibility. Ask what the product does, which remote functions it depends on, who designed or controls the relevant service software, and what happens if that service disappears.

Use the absence test to find integrated remote functions

Recital 11 provides the most useful operational test: processing or storage at a distance falls within CRA scope only insofar as it is necessary for the product with digital elements to perform its functions.

A practical way to apply that rule is to ask what the product can still do if the remote service is removed.

For each backend dependency, document:

the product function supported by the service;
whether that function stops entirely, degrades or remains available without the service;
whether the service software is developed by or under the responsibility of the manufacturer;
what data and commands cross the remote boundary;
which product versions or variants depend on it; and
whether the dependency is required by the intended purpose or reasonably foreseeable use of the product.

The CRA definition says "one of its functions", not "all essential functions". A remote service can therefore be in scope even when the product retains substantial offline functionality.

At the same time, not every optional web property, analytics endpoint or general corporate system automatically becomes part of the product. The connection has to satisfy the legal definition.

An API or database can be part of the product boundary

Recital 11 gives a concrete example: a mobile application may require access to an API or database provided through a service developed by the manufacturer. In that situation, the service can fall within CRA scope as a remote data processing solution.

That example is useful because many modern products split behavior across a client and backend. The user may install a mobile or desktop application, while authentication, configuration, device commands, entitlement checks, synchronization or business logic runs remotely.

Product teams should not document only the downloadable client and treat the backend as a generic operational dependency. If the remote service meets Article 3(2), the cybersecurity risk assessment and product evidence need to account for the local and remote parts together.

This does not mean the CRA converts the manufacturer's entire IT environment into one regulated product. Recital 11 expressly distinguishes remote data processing solutions from technical, operational or organisational measures for securing the manufacturer's network and information systems as a whole.

Cloud does not automatically mean in scope

Recital 12 makes the opposite boundary equally clear. Cloud solutions are remote data processing solutions under the CRA only when they meet the Article 3(2) definition.

The Regulation gives a positive example: cloud-enabled functionality provided by a manufacturer of smart-home devices that lets users control the device remotely can be within scope.

It also gives exclusion examples:

a website that does not support the functionality of a product with digital elements; and
a cloud service designed and developed outside the responsibility of the product manufacturer.

That means a corporate website, marketing portal or unrelated third-party cloud product is not pulled into the CRA product boundary merely because the same manufacturer uses it.

For third-party cloud infrastructure, distinguish infrastructure from product-specific software. Running a manufacturer-controlled product backend on a third-party hosting platform does not by itself make the backend independent of the manufacturer. The key question remains who is responsible for the software that provides the remote product function and whether the product depends on it.

Do not use "SaaS" as a shortcut for the scope decision

SaaS is a deployment and service model, not a CRA scope conclusion.

Recital 12 notes that cloud computing service models such as Software as a Service, Platform as a Service and Infrastructure as a Service are addressed by the NIS2 framework for qualifying cloud providers. That statement should not be read as a blanket rule that every remote service is excluded from the CRA.

A manufacturer-controlled cloud service can still be part of a product with digital elements when it meets the remote data processing definition. Conversely, a standalone SaaS service that is not an integrated remote processing solution for a product with digital elements should not be labelled a CRA remote data processing solution merely because users access it over a network.

The correct approach is to classify the actual product architecture first and then assess which legal regimes apply to the relevant entities and services.

Map responsibility, not only technical ownership

The definition covers software developed by the manufacturer or under the responsibility of the manufacturer. That makes outsourcing arrangements relevant.

A backend does not necessarily fall outside the product boundary because an external supplier wrote or operates part of it. If the manufacturer remains responsible for the software as part of the product function, the architecture and evidence model should reflect that responsibility.

Useful records include:

the supplier and contractual role;
which software or service layer the supplier provides;
who specifies security requirements;
who controls release and change decisions;
who receives vulnerability information;
how security fixes are delivered;
which evidence the manufacturer can obtain; and
what happens when the supplier or service becomes unavailable.

The CRA already requires manufacturers to exercise due diligence when integrating third-party components. Remote-service dependencies deserve the same discipline of product-specific ownership and traceability.

Include remote services in the cybersecurity risk assessment

If a remote data processing solution is part of the product with digital elements, treating it as an unrelated operations system creates an evidence gap.

The cybersecurity risk assessment should consider threats and controls across the remote boundary. Depending on the architecture, that can include:

authentication between client, device and backend;
authorization for remote commands or data access;
confidentiality and integrity of data in transit;
credential and key handling;
exposed APIs and attack surface;
availability and resilience of remote functions;
tenant or customer isolation where relevant;
logging and security monitoring;
update and deployment controls for backend software;
vulnerability handling and coordinated remediation; and
failure behavior when the remote service is unavailable or compromised.

The point is not to force every cloud control into a CRA checklist. It is to show how the product's actual remote architecture was considered when deciding which essential cybersecurity requirements and technical measures are applicable.

Keep product and backend releases connected

Remote services change more frequently than many physical products. That creates a practical traceability problem: the product placed on the market may continue to depend on backend software that is updated many times during the support period.

Teams need a way to answer:

which backend version or deployment state supported a given product release;
what security-relevant changes were made later;
which vulnerabilities affected the backend or its dependencies;
what test evidence supported those changes;
whether a change altered the product's intended or security-relevant behavior; and
which product variants or markets were affected.

Do not rely on a single architecture diagram created before market placement. The product boundary may remain stable while the implementation behind that boundary changes continuously.

A controlled service inventory, release history and evidence trail can make those changes reviewable without pretending that every operational deployment is a new market-placement event.

Document exclusions as carefully as inclusions

A good scope record should explain why a remote service is outside the product boundary as well as why another one is inside it.

For an excluded service, record the factual basis. For example:

the product performs all relevant functions without the service;
the service is a general corporate website unrelated to product functionality;
the service is a third-party offering outside the manufacturer's responsibility; or
the connection is auxiliary and does not meet the Article 3(2) absence test.

This prevents later teams from repeating the scope analysis from memory and helps keep architecture, legal reasoning and product evidence aligned when integrations change.

Revisit exclusions when a new release introduces tighter dependency on a remote service. A service that was once optional can become necessary for a product function after a feature or architecture change.

Build one evidence package for the combined product boundary

For products that include remote data processing solutions, useful evidence should connect the physical or local product with the remote service instead of maintaining separate, unlinked compliance records.

A practical evidence package can include:

the product and variant identifiers;
the remote-service inventory;
architecture and data-flow diagrams;
the Article 3(2) scope rationale;
manufacturer and supplier responsibility records;
cybersecurity risk-assessment references;
applicable requirement decisions;
backend and client security-test evidence;
SBOM or dependency evidence where applicable;
vulnerability decisions and remediation history; and
release or change records showing which product context the evidence supports.

This becomes particularly important when the same backend supports multiple products. Evidence should make clear which findings apply to all consumers of the service and which are product-specific.

Keep remote-service evidence tied to lifecycle context

Connected-product teams can easily end up with product records in one system, cloud deployment evidence in another, vulnerabilities in a third and scope decisions in documents that are rarely revisited.

AA-sec is designed around traceability between requirements, security evidence, decisions and exact product or lifecycle context. That model can support teams that need remote-service scope decisions and backend evidence to remain connected to the relevant product and release, while engineering and legal ownership of the architecture and CRA interpretation remain with the manufacturer.

Key takeaway

Under the CRA, the cloud boundary is functional and responsibility-based. A remote service belongs within the product with digital elements when it is software designed and developed by, or under the responsibility of, the manufacturer and the product would lose one of its functions without that remote processing.

Do not classify scope by labels such as SaaS, API or cloud alone. Map each remote dependency to a concrete product function, apply the Article 3(2) absence test, document manufacturer responsibility, include in-scope services in the cybersecurity risk assessment, and keep backend changes and evidence connected to the exact product lifecycle context.

Official sources

Regulation (EU) 2024/2847 - Cyber Resilience Act — EUR-Lex
Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
The Cyber Resilience Act - Summary of the legislative text — European Commission