EU Cyber Resilience Act FAQ 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.

That matters because a product with digital elements includes its remote data processing solutions. Recital 11 gives a concrete example: if a mobile application needs a manufacturer-provided API or database service to perform one of its functions, that service can fall within scope as RDPS.

The March 2026 draft guidance breaks the definition into three elements:

- the data processing is at a distance

- its absence would prevent the product from performing one of its functions

- the software is designed and developed by the manufacturer, or under its responsibility

If one of those elements is missing, the solution is not RDPS within the CRA meaning.

No.

The draft guidance says the relevant "functions" are not limited to core functionality or intended purpose in a narrow sense. They can also include supporting functions that the product offers, such as onboarding, configuration, synchronisation, remote commands, updates, and identity and access management.

Yes.

The draft guidance says a manual or local alternative does not by itself take the remote processing outside Article 3(2). If remote performance is one of the functions the product offers, the related remote processing can still qualify as RDPS.

It is a case-by-case concept.

The draft guidance says remote processing can take place through wired or wireless connections, in public cloud, private cloud, edge environments, or on local servers on the manufacturer's premises. The key point is that the relevant data processing happens remotely rather than only on the user's device.

No.

The CRA covers the relevant software parts of remote data processing, not the manufacturer's network and information systems as a whole. The draft guidance also says the underlying hardware infrastructure remains outside the product scope, even though the related risks still need to be assessed.

No.

The draft guidance says only the parts of the system that directly interact with the product, and where data necessary for the product to perform one of its functions is stored or processed, fall within the relevant CRA conformity scope. In its banking-app example, the API layer can be RDPS while segregated account-management or ledger systems remain outside RDPS, even though the manufacturer still has to assess and mitigate the risks they create for the product.

Usually no.

A product redirecting users to a webpage that only provides information or instructions does not make that site RDPS. But a website or portal can fall within scope if it actually enables or supports a product function, such as an authentication function, and the Article 3(2) criteria are met.

The draft guidance treats it as broader than in-house development, but narrower than simply licensing an existing third-party service.

It refers to remote processing solutions that are tailor-made for the manufacturer, built solely on its behalf, and based on its designs and specifications. A general-purpose third-party SaaS offering normally does not meet that test.

Not decisively.

The draft guidance says the decisive issue is who designed and developed the relevant software, not who operates the environment. A manufacturer can remain responsible even where operation is outsourced.

The cloud model does not decide the outcome by itself, but it helps explain who designed and developed what.

The draft guidance says:

- on third-party IaaS, the manufacturer's own software running on that infrastructure may qualify as RDPS

- on third-party PaaS, the manufacturer's application layer may qualify as RDPS, while the provider's platform functions do not

- a third-party SaaS application that the manufacturer did not design or commission is generally not RDPS

No.

If the service is necessary for a function but was not designed and developed by the manufacturer or under its responsibility, the guidance says it should be treated more like a third-party component. The manufacturer still has to assess the resulting risks and exercise due diligence, but the service is not RDPS.

Usually no.

The draft guidance says processing of that kind is not RDPS where its absence would not prevent the product from performing one of its functions. But the manufacturer may still need to assess and mitigate any risks that the related remote communications create for the product.

Usually no.

The draft guidance says those kinds of internal or organisational systems should not be treated as RDPS for the product, even though they may matter to the manufacturer's broader security posture.

It means the manufacturer has to assess the product as a whole, including RDPS when it is in scope.

The Commission FAQ says the cybersecurity risk assessment needs to cover the entire product with digital elements, including remote data processing where relevant and any supporting functions that may form part of the product. The draft guidance adds that the conformity assessment should focus on the parts of the system where the relevant product data is stored or processed, not the whole surrounding environment.

The draft guidance says the technical documentation should indicate whether the product has RDPS or relies on third-party cloud solutions, and should describe them.

If the same RDPS supports several products, it still needs to be declared in each product's documentation, even though the underlying documentation may be reused.

The draft guidance says that, as relevant, the manufacturer may re-use certain evidence in support of its conformity assessment and/or due diligence for third-party cloud services.

The listed examples are:

- CE marking of components, if those components are still within their support period

- evidence of fulfilment of obligations under Commission Implementing Regulation (EU) 2024/2690

- evidence of fulfilment of obligations under DORA

- statements of conformity or certificates under a European cybersecurity certification scheme

- evidence of conformity with ISO/IEC 27017:2015 or ISO/IEC 27001:2022

They also matter later.

The draft guidance says RDPS must be taken into account not only for the initial conformity analysis but also for lifecycle obligations, including reporting of actively exploited vulnerabilities and severe incidents under Article 14.

No, not just because the product relies on connectivity.

The draft guidance's cellular-network example says a network is only a communication channel in that scenario, not remote data processing whose absence would prevent the product from performing its function in the Article 3(2) sense. It also says such a network should not be treated like a third-party component where no provider software is integrated into the product.

Yes, as one support tool.

The draft guidance says the manufacturer should combine product-level security controls with verification of the provider's own security measures. It adds that security guarantees in SLAs can help, including assurances about vulnerability handling, and says manufacturers are encouraged to ensure third-party providers keep them adequately informed about changes to their solutions.

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 needs to manage the resulting risks through risk assessment and due diligence.