The purpose of this Regulation is to ensure a high level of cybersecurity of products with digital elements and their integrated remote data processing solutions. Such remote data processing solutions should be defined as data processing at a distance for which the software is designed and developed by or on behalf of the manufacturer of the product with digital elements concerned, the absence of which would prevent the product with digital elements from performing one of its functions. That approach ensures that such 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. At the same time, processing or storage at a distance falls within the scope of this Regulation only in so far as it is necessary for a product with digital elements to perform its functions. Such processing or storage at a distance includes the situation where a mobile application requires access to an application programming interface or to a database provided by means of a service developed by the manufacturer. In such a case, the service falls within the scope of this Regulation as a remote data processing solution. The requirements concerning the remote data processing solutions falling within the scope of this Regulation do therefore not entail technical, operational or organisational measures aiming to manage the risks posed to the security of a manufacturer’s network and information systems as a whole.
Recital 11
Regulation (EU) 2024/2847 — published 10 December 2024 · Last reviewed by Kunnus: March 2026
European Commission Interpretation
Guidance of 27 July 2026The EU Commission guidance of 27 July 2026 provides official interpretation notes on this provision. Each section: summary, key takeaways, and what it means for you in practice.
Section 2.2Software as a product — web apps and websites
Software is a product with digital elements only where it is supplied to the user and executes on the user's system. Web applications accessed exclusively through a browser and purely informational websites are not themselves products — they fall within scope only as remote data processing where they support a function of a product.
Key takeaways
- Locally installed applications are products — including browser extensions and desktop apps built with web technologies but supplied for local execution.
- Web apps and progressive web apps accessed exclusively through a browser are not products with digital elements (recitals 11 and 12).
- A locally installed client plus the data processing at a distance it relies on for its functions together constitute the product.
In practice
Sort your portfolio into three buckets: (1) runs locally on the user's device (app, desktop client, browser extension) → a product under the CRA; (2) browser-only web app or informational website → not a product; (3) a back-end supporting a product function → assess as remote data processing (Chapter 8 of the guidance).
Section 8.1What counts as a remote data processing solution (RDPS)?
Remote data processing is part of the product where three criteria are cumulatively met: processing 'at a distance', functional necessity (without it the product could not perform one of its functions), and development by or under the responsibility of the manufacturer. The guidance turns this into two test questions with a decision flowchart.
Key takeaways
- 'Who operates it' is irrelevant: on-premises or private-cloud solutions can qualify as RDPS just like public-cloud solutions.
- 'Functions' means more than core functionality: onboarding, file sync, configuration, automated update distribution and identity/access management all count.
- Telemetry purely for statistics or future product development is not RDPS — but the risks of such remote components still belong in the risk assessment.
- IaaS/PaaS: where the manufacturer's own (or commissioned) software runs on third-party infrastructure, it can be RDPS; standard third-party SaaS is not RDPS but must be treated like a third-party component (mitigate risks + due diligence).
- 'Under the manufacturer's responsibility' = tailor-made for the manufacturer to its designs/specifications — not merely licensing an existing service.
- Internal systems (HR, CRM, CI/CD pipelines, update distribution to edge locations, pentest/red-team infrastructure) are not RDPS.
- Websites only where they support a function: an authentication portal issuing tokens for the product can be RDPS — an informational website is not, even if the product links to it.
In practice
Answer two questions per cloud/back-end service: (1) would a product function fail without it (including onboarding, sync, updates, login)? (2) was the software developed by us or to our specifications? Two yeses → part of your product, belongs in the risk and conformity assessment. Only question 1 yes (e.g. standard SaaS) → treat as a third-party component: mitigate risks plus due diligence.
Section 8.2RDPS in documentation, risk assessment and conformity assessment
RDPS must be covered in the product's risk assessment, technical documentation and conformity assessment — limited to the software modules responsible for the product's functionality and the interfaces those modules use. Downstream back-end systems the product does not directly interact with are not RDPS, but remain external dependencies whose risks must be mitigated at product level.
Key takeaways
- An RDPS serving several products must be declared in each product's technical documentation — the RDPS documentation may be reused across conformity assessments.
- Reusable assurance artefacts for third-party services: NIS 2 evidence (IR (EU) 2024/2690), DORA evidence, certificates under EU cybersecurity certification schemes, ISO/IEC 27001/27017.
- Major changes to third-party services are not a substantial modification of the product — but manufacturers should secure information and security guarantees contractually (SLAs) and revise the risk assessment accordingly.
In practice
Create a central RDPS dossier — affected software modules, interfaces, providers used with evidence (ISO 27001/27017, NIS 2 or DORA evidence, EUCC certificates) — and reference it from every product's documentation. Anchor in provider SLAs that you are informed about major changes: they do not trigger a new conformity assessment, but they do require updating your risk assessment.
Section 8.3Five RDPS use cases: banking app, thermostat, e-reader, robot, cellular network
Five worked cases illustrate the boundary: for a mobile banking app, the self-developed banking interface is RDPS, downstream ledger/account systems are not, and the third-party SaaS support chat is a third-party component. Smart thermostat and industrial robot: the manufacturer's own cloud software on third-party IaaS is RDPS. E-reader: third-party SaaS storage is not RDPS but must be treated as a component. The cellular network is a mere communication channel — no RDPS, no due diligence required.
Key takeaways
- The CRA covers only the parts of the system the product directly interacts with — risks from systems behind them (e.g. a compromised ledger) must be mitigated at product level (strong back-end authentication, integrity protection, secure channels).
- With third-party IaaS: document the RDPS and the IaaS reliance in the technical documentation; obtain e.g. NIS 2 evidence from the provider.
- Network infrastructure (5G, ethernet, Wi-Fi, routers) is a communication enabler, not data processing whose absence would prevent a product function.
In practice
Map your own setup to the closest of the Commission's five use cases (banking app, smart thermostat, e-reader, industrial robot, cellular network) and adopt its logic: what interacts directly with the product and was developed by you is RDPS; systems behind it are external dependencies; pure network infrastructure is neither. In most cases this replaces an expensive bespoke legal opinion.
EU Commission Guidance (C(2026) 5252 final) — The guidance reflects the European Commission's interpretation and is not legally binding. An authoritative interpretation of the EU CRA may only be given by the Court of Justice of the European Union.
Related Articles
(1)This text is reproduced from Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024. It is provided for informational purposes only and does not constitute legal advice. Only the text published in the Official Journal of the European Union is legally binding. Original text on EUR-Lex