Article 3(1) of the Cyber Resilience Act, Regulation (EU) 2024/2847, defines a product with digital elements as "a software or hardware product and its remote data processing solutions". Article 3(2) 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". Whether your product is in scope at all turns on Article 2 and Recital 12. Once it is, the next question for every company with an app and a cloud is which parts of the cloud came into scope with it, because those parts go into the risk assessment, the essential requirements, the technical file and the reporting duty.
The Commission's guidance on the application of the Regulation, C(2026) 5252 of 27 July 2026, section 8, paragraphs 178 to 208, answers that question with more precision than the Regulation does. This article is that section, with its five use cases, read for a software manufacturer.
Two cumulative tests
Paragraph 184 breaks the definition into three elements: whether the processing is at a distance, whether its absence would prevent the product from performing one of its functions, and whether the software was designed and developed by the manufacturer or under its responsibility. Paragraph 185 then sets the first aside as "relevant but not sufficient": cloud, edge and the manufacturer's own on-premises servers all count as at a distance (paragraph 187), so the first element rarely decides anything. Paragraph 188 states the rule: the second and third are "the two decisive and cumulative questions", and "if both questions are answered in the affirmative, the remote data processing qualifies" as a remote data processing solution.
Paragraph 202 gives the three outcomes. Both yes: it is part of your product, and Annex I applies to it. The function test no: not part of the product, but "manufacturers should assess the risks stemming from the existence of such data processing as part of their risk assessment". The function test yes but the responsibility test no: "manufacturers should treat the third-party solution as a component", assess and mitigate the risks of integrating it, and "exercise due diligence".
Test one: would its absence stop a function
The word is "functions", not core functionality. Paragraph 189: "the notion of 'functions' included in this definition is not limited to the 'core functionality' or 'intended purpose' of the product with digital elements", and covers "both functions that directly fulfil the intended purpose of the product with digital elements as experienced by users and functions that support the product's overall performance". Paragraph 190 lists six examples of remote processing that a product cannot do without: "(i) sending commands to a device; (ii) synchronising files; (iii) onboarding the user; (iv) configuration (personalisation of the product with digital elements); (v) automated distribution of updates, including feature update and security patching; (vi) identity and access management".
Two refinements matter for software. A function the user can perform either remotely or manually, the light bulb switched from an app or by hand, still counts: "performing this function remotely is also considered part of the functions the product with digital elements offers" (paragraph 191). And the counter-example is telemetry: "remote analysis of telemetry data collected purely for statistical purposes or future product development" is not a function the product needs, so it is not remote data processing (paragraph 192), although paragraph 193 adds that the risks of those remote components still belong in the risk assessment.
Websites get their own paragraph, 194. A website that only carries information about the product is not in, "even if the product redirects to such website". A website that "enables or supports a function" is: "an authentication portal that issues credentials or tokens required for the product with digital elements to operate would be considered RDPS". For most software companies that single sentence puts the login service inside the product.
Test two: designed and developed by you, or under your responsibility
Paragraph 195: software built in-house qualifies, and so does software an external provider builds for you, but "under the responsibility of the manufacturer" means "tailor-made for the manufacturer", cases where "the software is built solely by or on behalf of the manufacturer, based on designs and specifications provided by it". Licensing an existing service, "or slightly modified versions thereof", is not that.
Who runs it is irrelevant. Paragraph 196: "the notion of 'who operates the solution' is not a decisive factor, as the CRA definition only refers to the design and development". A backend you wrote and a hosting company operates is yours.
Paragraphs 197 to 200 then sort the three cloud models. On third-party IaaS, you deploy your own operating systems and applications; that software "is designed and developed by the manufacturer, or under its responsibility, and may therefore qualify" (paragraph 198). On third-party PaaS, you deploy your own application on the provider's runtime; "the application is therefore designed and developed by the manufacturer" and may qualify (paragraph 199). A third-party SaaS application integrated into your product "is therefore not designed and developed by the manufacturer" (paragraph 200) and is not remote data processing, whatever function it supports.
What falls outside the definition does not fall outside your responsibility. Paragraph 201: the hypervisor under your IaaS, the operating system under your PaaS, the third-party SaaS, "should be considered similar to third-party components" where they affect the product's security, and the manufacturer "is required to identify and assess risks linked to the integration of those elements and to address them by implementing the essential requirements on the product with digital elements itself", exercising "a similar obligation to the obligation to perform due diligence referred to in Article 13(5)".
The boundary: modules your product talks to, not everything behind them
This is the part that decides how large the technical file gets. Paragraph 205: the remote data processing subject to the product's conformity assessment "should be limited to those software modules that are responsible for the functionality of the product with digital elements, and to the interfaces those modules use with external services. Further back-end systems that carry out subsequent processing, and with which the product with digital elements does not directly interact, are not considered RDPS". Paragraph 206 keeps them in the risk assessment as "external dependencies that must be assessed" and mitigated "through product-level measures".
Paragraph 182 lists what the definition was never meant to reach, on the strength of Recital 11: "internal systems relating to the manufacturer's own human resources, payrolls, customer relationship management, continuous integration/continuous delivery (CI/CD) pipelines, the distribution of security updates to edge locations, should not be considered as RDPS", and neither are "systems linked to auditing and testing activities, such as penetration testing, threat hunting and red teaming". The CRA covers the product, not "the whole IT infrastructure of an organisation". That is NIS2's territory, and Recital 12 says so.
The mobile banking case, which is most software companies' case
Section 8.3.1 walks through a bank's app with a self-hosted backend and a third-party support chat. The app talks to a "banking interface" the bank built, which in turn queries an account-management system and a ledger. The interface authenticates the customer, submits transfer instructions and returns their status; it "is necessary for the app to perform its functions" and "is designed and developed under the responsibility of the manufacturer", so it is remote data processing and "must therefore be included in the cybersecurity risk assessment and in the implementation of the essential requirements". The account-management and ledger systems are not: "the app does not interact directly with them", and "although their availability may be necessary for a function to be completed, the CRA covers only those parts of the system that interact directly with the product". They remain external dependencies whose compromise "could allow an attacker to influence transaction results", to be mitigated at product level "such as strong authentication of back-end interfaces, integrity protection of transaction data, secure communication channels and verification of responses received by the app".
The support chat, "developed and operated by a third-party provider", is necessary for a function but fails the responsibility test, so it is "not an RDPS" and "should be treated like a third-party component", isolated from core features, with due diligence on the provider.
Translate that to a typical B2B SaaS with a desktop or mobile client: the API gateway and authentication service the client calls are in the product; the data warehouse three hops behind them is an external dependency; the embedded third-party analytics, chat or payments widgets are components. The other four cases confirm the pattern: a thermostat's cloud functions on third-party IaaS are in (8.3.2), an e-reader's third-party SaaS storage is a component (8.3.3), a robot's vision service on IaaS is in (8.3.4), and a phone's 5G network is neither, "only a communication channel", with no due diligence owed to the operator (8.3.5).
What goes in the file, and what you can reuse
Paragraph 204: manufacturers "should (i) indicate in the technical documentation that their product with digital elements has RDPS or relies on third-party remote solutions and (ii) describe such solutions", and where one backend serves several products, it is declared in each product's file and the documentation "may be re-used from one product conformity assessment to another".
For the third-party services you rely on, paragraph 207 lists the assurance artefacts that can be reused in support of your assessment and due diligence: evidence of the provider's compliance with the NIS2 implementing regulation, with DORA, a certificate under a European cybersecurity certification scheme, or "evidence of conformity with ISO/IEC 27017:2015 or ISO/IEC 27001:2022". Paragraph 208 adds the contractual side: security guarantees in service level agreements, "including assurances that providers adequately handle vulnerabilities", and a provider's major change is not a substantial modification of your product, but it may require your risk assessment to be revised.
Read from the other side, paragraph 207(d) is also what your own customers may ask of you. If your product is remote data processing for theirs, your ISO 27001 certificate is the artefact the guidance names for their file.
The determination, in six lines
For each remote service your product calls, record:
- The service and the function it supports, in the guidance's sense of function.
- Test one: would the product lose that function without it. Telemetry and information websites: no.
- Test two: built by you or to your specification, or a licensed third-party application. IaaS and PaaS put your code on the in side; SaaS puts the application on the component side.
- The outcome under paragraph 202: part of the product, a component to assess with due diligence, or an external dependency to assess.
- The boundary under paragraph 205: which modules the product interacts with directly, and which systems sit behind them.
- The artefact you hold for each third-party service, from the paragraph 207 list, and the date you obtained it.
That table is the remote-processing section of the technical file, the input to the risk assessment Article 13 requires, and the answer to the second question in our scope determination. It is also the list of systems whose compromise starts the reporting clock, because paragraph 178 says the product, remote processing included, is what Article 14 reports on.
Sources
- Regulation (EU) 2024/2847, Article 3(1), (2) and (4), Article 13(2), (3) and (5), Recitals 11 and 12.
- European Commission, Commission guidance on the application of Regulation (EU) 2024/2847, C(2026) 5252 final of 27 July 2026, Annex, section 8, paragraphs 178 to 208 and use cases 8.3.1 to 8.3.5.
- Directive (EU) 2022/2555 (NIS2) and Commission Implementing Regulation (EU) 2024/2690, for the cloud services the guidance leaves to them.
This is not legal advice. Section 8 is eleven pages and the five cases are the clearest part of the whole guidance; read them before you draw your own line.