EU Cyber Resilience Act FAQ Remote Data Processing Solutions

Under Article 3(2), remote data processing means data processing at a distance where the software is designed and developed by the manufacturer, or under the manufacturer's responsibility, and the product would not be able to perform one of its functions without it.

Because Article 3(1) defines a product with digital elements as including its remote data processing solutions, qualifying RDPS is treated as part of the CRA product boundary. Recital 11 gives the example of a mobile application that needs a manufacturer-provided API or database service to perform a function.

Record the decision at the level of each remote software element and product function. Identify what fails when the remote element is unavailable, who specified or controlled its development, which product versions depend on it, and which interfaces and data flows enter the risk assessment. Do not classify an entire cloud account or corporate network as RDPS when only specific software elements meet Article 3(2).

The July 2026 Commission guidance frames the Article 3(2) definition around three checks: the processing is at a distance, the product cannot perform one of its functions without that processing, and the relevant software was designed and developed by the manufacturer or under its responsibility.

All three checks matter. A cloud-hosted function can be outside RDPS if the manufacturer did not design or commission the relevant software, and remote telemetry can be outside RDPS if the product still performs its functions without that processing.

No. The Commission guidance says the function test is not limited to the product's core functionality or narrow intended purpose. It can include functions that directly serve users and functions that support the product's overall performance.

Examples can include remote configuration, synchronisation, remote commands, onboarding, authentication, identity and access management, or updates if the product offers those as functions and the other RDPS criteria are met.

No. The location and hosting model do not decide the outcome by themselves. The Commission guidance says remote processing can happen over wired or wireless connections and can run in public cloud, private cloud, edge environments, or on local servers on the manufacturer's premises.

The practical question is whether the relevant software part performs data processing at a distance for a product function and falls under the manufacturer-design or manufacturer-responsibility test.

No. Recital 11 says RDPS requirements do not turn the manufacturer's network and information systems as a whole into the CRA product. The Commission guidance also treats RDPS as the software elements of remote data processing, not the underlying hardware infrastructure.

For conformity assessment, the Commission guidance limits RDPS to the software modules responsible for product functions and the interfaces they use with external services. Further back-end systems carrying out subsequent processing, with which the product does not directly interact, are outside RDPS scope; assess their risks and mitigate them through product-level controls.

Usually not if they only provide information and do not support product functionality. Recital 12 says websites that do not support the functionality of a product with digital elements do not fall within CRA scope as products with digital elements.

A website or portal can be different if it actually supports a product function and meets Article 3(2). For example, a manufacturer-controlled authentication portal, command interface, or configuration portal may need RDPS analysis, while a static instruction page normally does not.

The Commission guidance treats this as broader than in-house development but narrower than buying or licensing a standard third-party service. It covers remote processing software built for the manufacturer based on the manufacturer's designs and specifications.

Outsourced development can therefore remain under the manufacturer's responsibility. The July 2026 Commission guidance distinguishes this from licensing or slightly modifying a standard third-party SaaS offering. A general-purpose SaaS application is not RDPS merely because the manufacturer configures or integrates it; assess its security risks and exercise proportionate due diligence as an external dependency.

The cloud service model helps identify which software the manufacturer designed or controls, but it is not a substitute for the Article 3(2) test.

In the Commission guidance, the manufacturer's own software running on third-party IaaS may qualify as RDPS if the other criteria are met. On third-party PaaS, the manufacturer's application layer may qualify, while provider platform functions may not. A third-party SaaS application that the manufacturer did not design or commission is generally not RDPS, even if the product depends on it.

No. If the product needs the service for a function but the relevant software was not designed and developed by the manufacturer or under its responsibility, the Commission guidance says the service should be handled similarly to a third-party component rather than classified as RDPS.

That does not make the dependency irrelevant. The manufacturer still needs to assess the risks created by integrating or relying on that service and apply due diligence or product-level mitigations where needed.

Usually not, where the product can still perform its functions without that remote processing. The Commission guidance gives remote analysis of telemetry for statistical purposes or future product development as an example of processing that is not RDPS when it is not needed for a product function.

Internal organisational systems such as HR, payroll, CRM, CI/CD, threat-hunting, penetration-testing, or red-team tooling are also not normally RDPS for the product. They may still matter to security posture and risk assessment, but they are not automatically part of the product with digital elements.

No, not merely because the product uses connectivity. The Commission guidance's cellular-network use case treats the network as a communication channel in that scenario, not as remote data processing whose absence prevents the product from performing a function in the Article 3(2) sense.

The manufacturer still has to consider network-related risks in the product risk assessment and mitigate them through product-level controls where relevant.

When remote processing qualifies as RDPS, it is part of the product with digital elements for CRA assessment. The manufacturer's cybersecurity risk assessment must cover the whole product, including in-scope RDPS and supporting functions.

Keep the conformity boundary precise: include the modules responsible for the product's functions and their external-service interfaces. Assess risks from further back-end systems, surrounding infrastructure and third-party cloud services, then mitigate those risks at product level.

Where relevant, the technical documentation should identify whether the product has RDPS or relies on third-party cloud solutions and describe those solutions. If the same RDPS supports multiple products, it should still be declared in each product's documentation.

The documentation should connect the remote solution to the product function, explain whether it is manufacturer-designed or a third-party dependency, identify the parts of the system assessed for conformity, and record the risk assessment and mitigations for RDPS, third-party cloud reliance, and surrounding infrastructure.

Article 13(18) requires products to be accompanied by Annex II information and instructions that are clear, understandable, intelligible, legible, and sufficient for secure installation, operation, and use. If RDPS, cloud connectivity, account services, or backend assumptions are needed for secure use, the user information should make those conditions understandable.

Annex II is especially relevant where remote dependencies affect intended purpose, essential functions, security properties, significant cybersecurity risks, secure commissioning and use, security updates, support-period information, decommissioning, or secure removal of user data.

No. Contracts, SLAs, and provider assurances can support risk mitigation and due diligence, but the CRA product obligation remains with the manufacturer placing the product with digital elements on the market.

The Commission guidance says manufacturers should combine product-level security controls with verification of provider security measures. SLAs can help when they include security guarantees such as vulnerability-handling assurances and change-notification commitments from third-party cloud providers.

Not automatically. The Commission guidance says major changes in third-party cloud solutions should not by themselves qualify as substantial modification of the product where those solutions are not under the manufacturer's responsibility.

The manufacturer still has to manage resulting risk. Change notice, reassessment, updated mitigations, and documentation may be needed where the provider change affects product security, product functions, or assumptions recorded in the risk assessment.