Recital 12

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.

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.

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.

Only if it functions as remote data processing within the meaning of the CRA — meaning it is part of a product with digital elements. Standalone web applications without a product link remain outside. Cloud backends for IoT devices are in scope.

Data processing provided by the manufacturer that is necessary for the intended function of the product — typically smart home apps, connected industrial controllers with cloud backends, wearables with cloud sync.

Test: Does the product work without this cloud? If no (smart home app is required for device control) → CRA applies. If yes (web portal as an additional feature, product works standalone) → outside CRA.