Cloud Services, SaaS and Remote Data Processing Under the CRA

The CRA Starts With a Product With Digital Elements

Cloud analysis under the CRA begins with the product concept rather than with the word cloud. Article 2 applies the Regulation to products with digital elements made available on the Union market where intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Article 3 then defines a product with digital elements as a software or hardware product and its remote data processing solutions. A cloud service therefore does not become part of a CRA product merely because the manufacturer uses cloud technology somewhere in its business.

• Begin with the product with digital elements.
• Confirm the product is made available on the Union market.
• Identify the relevant connected functionality.
• Then analyse any remote processing supporting that product.

Article 3 Includes Remote Data Processing in the Product Definition

Article 3(1) expressly includes remote data processing solutions within the definition of a product with digital elements. This matters because cybersecurity analysis cannot always stop at the software installed on a device or downloaded by a user. Where a qualifying backend is necessary for product functionality, the CRA treats the local and remote elements as parts of the product security problem. The manufacturer should therefore define the product boundary in a way that captures qualifying remote software rather than documenting only the local executable or hardware device.

Article 3(2) Creates the Remote Data Processing Test

The operative definition has several connected elements. There must be data processing at a distance. The software responsible for that processing must be designed and developed by the manufacturer or under the manufacturer's responsibility. The absence of the remote processing must prevent the product with digital elements from performing one of its functions. These elements prevent the term remote data processing from expanding automatically to every externally hosted system used somewhere in the manufacturer's organisation.

• Data processing occurs at a distance.
• The relevant software sits under manufacturer design or responsibility.
• The product depends on it for at least one function.
• The analysis should be documented against the actual architecture.

The Product Does Not Need to Fail Completely for the Backend to Matter

Article 3(2) asks whether absence of the remote processing would prevent the product from performing one of its functions. The wording does not require the entire product to become unusable. A connected product can continue to perform local functions while losing a remote-control, synchronisation or other product function when the backend disappears. That lost function can still be relevant to the remote data processing analysis. Manufacturers should therefore test functionality feature by feature instead of asking only whether the product would switch on without the cloud.

• Complete product failure is not required by Article 3(2).
• Loss of one product function can be sufficient.
• Local fallback does not automatically place the backend outside scope.
• Map remote dependencies to specific product functions.

Recital 11 Gives an API and Database Example

Recital 11 illustrates the concept with a mobile application that requires access to an application programming interface or database provided through a service developed by the manufacturer. In that scenario, the service falls within the CRA as a remote data processing solution. The example is important for modern product architecture because a backend does not need to look like a traditional cloud control panel. An API endpoint, remote database or service layer can form part of the product when the statutory responsibility and functional-dependency conditions are met.

• APIs can be remote data processing.
• Remote databases can be remote data processing.
• Service layers can be relevant.
• The statutory test still needs to be applied.

Cloud Technology Alone Does Not Put a Service Inside the Product

Recital 12 makes clear that cloud solutions constitute remote data processing solutions only when they meet the CRA definition. Hosting something in a public cloud, private cloud or managed platform does not determine the legal boundary. Manufacturers need to identify the software function, who is responsible for its design and development, and whether the product requires that processing for a function. This prevents generic infrastructure, unrelated business systems and independent third-party services from being swept automatically into the CRA product boundary.

• Cloud hosting is not the legal test.
• Deployment model alone does not determine scope.
• Manufacturer responsibility matters.
• Functional dependency matters.

Manufacturer-Controlled Smart-Home Cloud Functions Are the CRA's Clear Example

Recital 12 gives the example of cloud-enabled functionality provided by a manufacturer of smart-home devices that enables users to control a device at a distance. That functionality falls within the CRA where it meets the remote data processing definition. The example shows why product teams need to treat the cloud layer as part of product security when a remote manufacturer service delivers an advertised or intended device capability.

• Connected-device remote control can be in scope.
• The manufacturer provides the functionality.
• The cloud functionality supports a product function.
• The remote layer should be represented in the product security boundary.

A Website Unrelated to Product Functionality Is Different

Recital 12 expressly distinguishes websites that do not support the functionality of a product with digital elements. A corporate website, marketing site or unrelated account-information page is not converted into a remote data processing solution merely because the manufacturer operates it. The analysis changes where a web service actually supplies functionality that the product needs. Teams should therefore document what a web property does rather than classify every manufacturer-operated domain as part of the CRA product.

• Marketing websites are not automatically product backends.
• Corporate web presence does not automatically enter CRA product scope.
• Functional support is the important distinction.
• Analyse each service according to its actual role.

Cloud Services Outside Manufacturer Responsibility Are Not Remote Product Processing

Recital 12 also states that cloud services designed and developed outside the responsibility of the manufacturer of the product with digital elements do not fall within CRA scope on the basis of remote data processing. This boundary is important where a product depends on general-purpose services supplied independently by another provider. The manufacturer should nevertheless analyse its own application software and integration layer separately. Using third-party infrastructure does not automatically answer whether manufacturer-controlled software deployed on that infrastructure satisfies Article 3(2).

• Independent cloud services need separate treatment.
• Manufacturer responsibility remains central.
• Underlying infrastructure and manufacturer application software can require different analysis.
• Document the boundary instead of treating the entire cloud stack as one legal object.

Standalone SaaS Needs a Different Scope Analysis

Recital 12 points out that cloud computing services and service models such as SaaS, PaaS and IaaS are addressed by NIS2 where its scope conditions are met. This does not mean that the labels SaaS or cloud produce an automatic CRA answer. A standalone service designed outside the responsibility of a manufacturer of a product with digital elements is different from a manufacturer-controlled backend integrated into such a product. The exact architecture, market offering and legal role should therefore be established before applying either framework.

• Do not use SaaS as an automatic CRA inclusion rule.
• Do not use SaaS as an automatic CRA exclusion slogan either.
• Distinguish standalone service from integrated product backend.
• Assess NIS2 separately where relevant.

CRA Product Scope and NIS2 Entity Scope Are Different Questions

The CRA and NIS2 regulate different objects. The CRA establishes cybersecurity requirements for qualifying products with digital elements made available on the Union market. NIS2 establishes cybersecurity risk-management and reporting obligations for covered entities as implemented through Member State law. Recital 12 acknowledges the relevance of NIS2 to cloud computing services. A company can therefore need separate analyses for its product architecture under the CRA and its organisational service-provider status under NIS2.

• CRA asks a product-scope question.
• NIS2 asks an entity and service-scope question.
• One framework does not automatically determine the other.
• Maintain separate legal-scope records.

The CRA Does Not Extend to the Manufacturer's Entire Corporate Network

Recital 11 limits an important possible overreading. Requirements concerning qualifying remote data processing solutions do not entail technical, operational or organisational measures aimed at managing risks to the security of the manufacturer's network and information systems as a whole. The remote solution needs to be secured as part of the product, but that does not transform every internal corporate system into a CRA product component. Product teams should distinguish the remote software supporting product functions from broader enterprise infrastructure.

• Secure the qualifying remote product solution.
• Do not automatically classify the whole corporate network as part of the product.
• Define product-facing services explicitly.
• Separate product-security evidence from enterprise-security scope.

Document the Product Boundary Before Building CRA Evidence

For cloud-connected products, a written product-boundary record should identify the local product, mobile or desktop applications, APIs, databases, authentication layers, remote processing functions, third-party cloud dependencies and internal systems that are not part of the product. For each remote service, record whether the manufacturer controls its design or development and which product function would stop if the service disappeared. This boundary then informs the cybersecurity risk assessment, technical documentation, vulnerability handling and future change reviews.

• Map the complete architecture.
• Identify manufacturer-controlled software.
• Identify independently supplied cloud services.
• Map each remote dependency to product functionality.
• Record in-scope and out-of-scope reasoning.
• Review the boundary when architecture changes.