Search every question across sub-FAQs

The Commission's March 2026 draft CRA 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 draft 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 draft 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 draft guidance also treats RDPS as the software elements of remote data processing, not the underlying hardware infrastructure.

For conformity assessment, the draft guidance points to the parts of the system where data needed for product functions is stored or processed. Other backend systems can still create risks that the manufacturer must assess, but they are not automatically part of the product scope as RDPS.

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 draft 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. By contrast, the March 2026 Commission guidance is still a draft and indicates that a general-purpose SaaS product is not RDPS merely because the manufacturer configures or integrates it. The final classification still depends on the Article 3(2) facts and any later adopted Commission guidance.

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 draft 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 draft 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 draft 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 draft 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.

The manufacturer should still avoid over-scoping. The draft guidance says conformity assessment should focus on the parts of the remote system where data necessary for product functions is stored or processed, while risks from surrounding infrastructure and third-party cloud services should be assessed and mitigated 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 draft 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 draft 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.