Is your cloud backend part of your product?

If your device talks to a server, sooner or later someone asks whether that server is part of your product under the Cyber Resilience Act (Regulation (EU) 2024/2847). The answer decides whether the CRA's essential requirements reach your backend code, or only your device's way of living with it. The Regulation gives one definition; the Commission's guidance turns it into two questions and five worked cases. This guide retells them for a maker of connected devices. It is a documentation aid, not legal advice. Statements are labelled evidence where the Regulation or the guidance says them and argument where they are our reading.

What the guidance is. Section 8 of the Commission's guidance C(2026) 5252 (Annex, points 178 to 208 and use cases 8.3.1 to 8.3.5) is the source for most of this page. Its content was approved on 27 July 2026 as a draft. The cover communication says it "will be formally adopted by the Commission at a later date, when all language versions are available. It is only from that moment that it will apply" (read again on 14 October 2026). It is not binding: only the Court of Justice can interpret the CRA with authority (point 8). It is still the Commission's own reading, so it is the best map there is. Every sentence below that rests on it is guidance, not law.

What the law says

The CRA calls a product with digital elements "a software or hardware product and its remote data processing solutions" (Article 3(1), evidence). It then defines remote data processing as "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), evidence).

So a backend can be part of your product. When it is, it is assessed with the product: the risk assessment, the essential requirements and the Article 14 reporting all cover it (point 178, evidence). Recital 11 gives the reason, so that products "are adequately secured in their entirety by their manufacturers, irrespective of whether data is processed or stored locally on the user's device or remotely by the manufacturer". Recital 12 gives the example of "cloud enabled functionalities provided by a manufacturer of smart home devices that enable users to control the device at a distance". The guidance shortens remote data processing solutions to RDPS; this guide says "remote data processing".

Only the software counts. Remote data processing is "the software elements" of the processing, not the hardware it runs on (point 180, evidence).

The two questions

Before the two questions there is a threshold: is the processing done at a distance? The guidance gives no exhaustive definition and asks for a case-by-case assessment (point 185, evidence). It typically happens outside the user's environment, but it can sit close to the device, "at the edge", over a cable or over Wi-Fi or Bluetooth (point 186, evidence). "At a distance" includes your own premises. A server in your own building or your private cloud is "just as likely to qualify" as one on a public cloud (point 187, evidence). Owning the rack does not take the code out of the CRA.

Then two questions, and both must be answered (points 184 and 188, evidence):

1. Would the product be unable to perform one of its functions without this processing? (Section 8.1.2.)
2. Was the software designed and developed by you, or under your responsibility? (Section 8.1.3.)

Point 202 states the three outcomes (evidence):

Question 1	Question 2	What it is	What you do
Yes	Yes	Remote data processing, part of your product	Assess it and meet the essential requirements for it as part of the product
No	(not asked)	Not remote data processing	Assess the risks it brings in your risk assessment
Yes	No	A third-party solution, treated as a component	Assess the risks of integrating it, mitigate them, and exercise due diligence

In five minutes, for each server your device or app talks to: write down which function stops if that server is gone, then write down who wrote the code it runs. If nothing stops, it is the second row. If something stops and you or a contractor working to your specification wrote the code, it is the first row. If something stops and the code is a service the provider sells to anyone, it is the third row. Then read the limit in the next paragraph.

Only what the device talks to. Remote data processing is limited to the software modules responsible for the product's functionality and the interfaces they use with external services. Back-end systems further behind them, "with which the product with digital elements does not directly interact", are not remote data processing (point 205, evidence). They do not drop out of view: they "remain external dependencies" that your risk assessment covers and product-level measures mitigate (point 206, evidence).

What counts as a function

The first question is wider than it looks. "Functions" is "not limited to the 'core functionality' or 'intended purpose'"; it covers functions users experience and functions "that support the product's overall performance" (point 189, evidence). The guidance lists examples (point 190, evidence):

• sending commands to a device;
• synchronising files;
• onboarding the user;
• configuration, meaning personalising the product;
• automated distribution of updates, including feature updates and security patches;
• identity and access management.

A function you can also do by hand still counts. If a light can be switched from an app or at the wall, the processing behind the app is still a candidate: "Performing this function remotely is also considered part of the functions the product with digital elements offers" (point 191, evidence).

Telemetry for statistics does not count. Processing whose absence stops no function is not remote data processing, for example "remote analysis of telemetry data collected purely for statistical purposes or future product development" (point 192, evidence). Our reading (argument): the word that matters is purely. Telemetry that also drives something the user relies on, such as an alert or a schedule the device follows, is a function and is asked the second question.

It still goes in the risk assessment. Even processing that supports no function may bring risks to the product, which you consider in the risk assessment and mitigate, for example with product-level measures (point 193, evidence). A telemetry endpoint the device posts to is still an endpoint the device talks to (argument).

Websites. A website that only carries information about the product is not remote data processing, even when the product links to it. A website that enables or supports a function can be: the guidance's example is "an authentication portal that issues credentials or tokens required for the product with digital elements to operate" (point 194, evidence; recital 12 says the same of websites that do not support a function).

What it never covers. The CRA does not reach your whole IT estate (recital 11; point 182, evidence). The guidance names internal systems that are not remote data processing: human resources, payroll, customer relationship management, CI/CD pipelines, "the distribution of security updates to edge locations", and auditing and testing such as penetration testing, threat hunting and red teaming (point 182, evidence). Testing your product's security is still an essential requirement (Annex I, Part II, point 3); the systems you test with are not part of the product (point 182, evidence).

Whose software it is

The second question is about who designed and developed the code, not where it runs and not who runs it.

In-house code is yours, and so is code built for you. Software you wrote "would naturally qualify"; so does software an external provider builds for you, which is what "under its responsibility" means. The guidance reads that phrase as tailor-made: "built solely by or on behalf of the manufacturer, based on designs and specifications provided by it". It is not "merely licensing an existing product with digital elements or service that a service provider offers to its customers or slightly modified versions thereof" (point 195, evidence).

Who operates it does not decide. In the guidance's words, "the notion of 'who operates the solution' is not a decisive factor" (point 196, evidence). If you design and develop the backend and a hosting firm runs it, you remain responsible for it (point 196, evidence).

The three cloud models (points 197 to 201, evidence):

• IaaS, rented machines: the provider controls the hardware and the hypervisor; you deploy your own operating system and applications. That software is yours and may be remote data processing (point 198).
• PaaS, a managed runtime: you deploy your own application, created or acquired, into the provider's execution environment and control it. The application is yours and may be remote data processing (point 199).
• SaaS, a finished application: the provider offers a fully developed application and you have limited configuration. It is not designed and developed by you or under your responsibility (point 200).

What is not yours still matters. The hypervisor under your IaaS, the operating system under your PaaS, and a SaaS application are not remote data processing, but where they are integrated in a way that affects the product's security they are treated "similar to third-party components" (point 201, evidence). You identify and assess the risks of integrating them, meet the essential requirements on the product itself, may use the provider's own security functions under its shared responsibility model, and exercise due diligence like that in Article 13(5), in proportion to the risk (point 201, evidence). Article 13(5) asks you to make sure third-party components "do not compromise the cybersecurity of the product with digital elements" (evidence).

A bought IoT platform (argument, ours: the guidance has no case for it). A device platform you subscribe to, offered to any customer, which you configure but did not have built, reads like the SaaS in point 200 and the storage service in use case 8.3.3: not part of your product, but a component you assess, mitigate and do due diligence on. Code you write and deploy on that platform, such as your own functions, rules engine scripts or API for your app, reads like the PaaS application in point 199: yours, and part of your product if a function needs it. For the platform's provider itself, recital 12 points to the NIS2 Directive (Directive (EU) 2022/2555), which applies to cloud computing services from providers of at least medium size (evidence, recital 12).

Five cases

The guidance tells five fictional cases (section 8.3). Here they are briefly, each ending in what the maker documents and checks.

1. A bank's mobile app (8.3.1). The app talks to a self-hosted "banking interface" that the bank built; behind it sit an account-management system and a ledger. The banking interface is remote data processing: the app needs it and the bank built it. The account and ledger systems are not, because the app never talks to them directly, but they remain external dependencies: a compromised ledger could change what the app shows. A support chat bought as SaaS is needed for a function but not built by the bank, so it is a third-party component. What the maker does: covers the banking interface in the risk assessment and the essential requirements; assesses the back-end systems and mitigates with product-level measures such as strong authentication of back-end interfaces, integrity protection, secure channels and checking responses in the app; isolates the chat from core banking features, controls data flows, validates content and does due diligence on the chat provider.

2. A smart thermostat (8.3.2). The app and the thermostat exchange commands and store preferences through processing built under the manufacturer's responsibility, running on rented IaaS. Without it the thermostat cannot perform its smart functions, so it is remote data processing. What the maker does: documents the remote data processing and its reliance on the IaaS in the technical documentation, "including details of the contracted service"; covers both in the risk assessment; meets the essential requirements on the remote data processing; and checks the provider's security measures are appropriate, for example by asking for evidence that NIS2 obligations are met.

3. An e-reader (8.3.3). The reader's books are stored in a third-party SaaS storage service that is offered to customers "for any use case". The reader needs it, but the maker did not build it, so it is not remote data processing. What the maker does: treats the SaaS like a component; covers it in the risk assessment; implements product-level measures such as secure authentication, encryption and integrity protection of communications with the service; does due diligence when choosing and integrating it.

4. An industrial robot (8.3.4). The robot sends camera images to a service the manufacturer designed and developed, on rented IaaS; the service works out where the part is and tells the robot to pick it up. Without it the robot cannot pick parts, and the manufacturer built it, so the software is remote data processing. What the maker does: documents the remote data processing and the IaaS in the technical documentation, with the contracted service; covers both in the risk assessment; meets the essential requirements on the product including the remote data processing; does due diligence on the IaaS provider, for example asking for evidence that NIS2 obligations are met.

5. A phone on a cellular network (8.3.5). The phone needs a network to connect, but the network is "only a communication channel"; whether it is running does not tell you whether the phone works. An ethernet cable, a router or a Wi-Fi signal is the same. It is not remote data processing and, because no software from it is integrated into the phone, not a third-party component either. What the maker does: no due diligence on the network operator is needed (evidence, use case 8.3.5). Our reading (argument): the phone's own handling of a hostile or absent network stays in its risk assessment like any other part of its operating environment.

What it costs you

The technical documentation. Say in it that the product has remote data processing, or relies on third-party remote solutions, and describe them (point 204, evidence). If one backend serves several products, declare it in each product's technical documentation; the description can be reused between them (point 204, evidence).

The risk assessment, and controls on the product. The CRA is risk-based (Article 13(2) and (3); Annex I, Part I, point 1; point 203, evidence). The guidance asks the risk assessment to cover three kinds of risk: those of your remote data processing, those of relying on third-party remote solutions, and those of the product's environment, such as the hardware underneath. You mitigate them with security controls "on the product with digital elements itself" (point 206, evidence). Our reading (argument): for a service you do not control, the question the risk assessment answers is how your device behaves when that service fails or is breached.

Due diligence, and what a provider can show you. For third-party remote services, the guidance lists assurance evidence you can reuse, and says the list is not exhaustive (point 207, evidence):

• evidence of meeting Commission Implementing Regulation (EU) 2024/2690 (the NIS2 rules for cloud and other digital providers);
• evidence of meeting Regulation (EU) 2022/2554 (DORA);
• a statement of conformity or certificate under a European cybersecurity certification scheme adopted under the Cybersecurity Act (Regulation (EU) 2019/881);
• evidence of conformity with ISO/IEC 27017:2015 or ISO/IEC 27001:2022.

Our reading (argument): keep what you asked for, what you got and the date, as you would for any component; see "Asking suppliers for CRA evidence" and "Due diligence on open-source components".

When the provider changes its service. Put security commitments in your service level agreement, including that the provider handles vulnerabilities adequately (point 208, evidence). A major change to a third-party service "should not qualify as a substantial modification" of your product, because it is not under your responsibility (point 208, evidence). You are encouraged to make sure the provider keeps you informed of changes; on that information you may need to revise the risk assessment, ask whether the provider still gives enough guarantees and whether your product-level controls are still adequate, and in some cases change those controls or change provider (point 208, evidence).

What is not settled

• How far a ready-made service can be adapted before it counts as built for you. Point 195 says "slightly modified versions" of an existing service are not under your responsibility and tailor-made software is; it gives no threshold between the two (argument, ours). If you paid a provider to extend its platform for you, write down what was built to your specification and what is its standard product, and why you read it as you do.
• What "at a distance" covers. The guidance gives no exhaustive definition and leaves it to a case-by-case assessment by the manufacturer (point 185, evidence).
• Whether the guidance will change. It is a draft, not yet formally adopted, and not binding (point 8; the cover communication). Its examples "are not intended to replace a case-by-case assessment" (point 8, evidence). The wording can still change before adoption.

For which duties start when, and what the CRA does and does not punish, see "What the CRA does and does not punish".