If the manufacturer later places more units of the same model or series on the market, can it simply rely on the old CRA support-period position?
Not automatically.
The Commission FAQ explains that units already placed on the market can continue to be made available after the support period expires, but if the manufacturer later places additional units of the same model or series on the market, it still has to set the support period for those newly placed units in accordance with Article 13(8).
Can a whole commercial range be treated as one CRA product family just because the products share branding or platform marketing?
No.
Shared branding, industrial design, or platform naming does not by itself justify one CRA family file. The relevant question remains whether the products share the same security-relevant design, intended purpose, and cybersecurity risk profile.
If variants are similar enough, is the manufacturer required to use one family-wide CRA file?
No.
The draft guidance says manufacturers may rely on a single cybersecurity risk assessment, a single set of technical documentation, and a single conformity assessment where the family conditions are met. That means reuse is permitted, not mandatory. A manufacturer can still keep separate files if it prefers.
Can a manufacturer add a later variant to an existing CRA product family instead of starting from scratch?
Sometimes, yes.
The March 2026 draft guidance allows reliance on a single risk assessment, technical documentation set, and conformity assessment where the variants share the same architecture, security-relevant design, intended purpose, and cybersecurity risks, and all variants are adequately covered. So a later variant can remain within the same family if it still fits those conditions.
But where the later variant introduces new cybersecurity risks or changes how the essential cybersecurity requirements are implemented, the existing risk assessment and conformity documentation must be updated accordingly.
Does using a product-family approach remove the manufacturer's duty to keep series production in conformity?
No.
Article 13(14) still requires manufacturers to ensure that products that are part of a series of production remain in conformity with the CRA. They must adequately take into account changes in the development and production process, in the design or characteristics of the product, and in the standards, certification schemes, or common specifications used to verify conformity.
So a family-based file does not freeze compliance. It still has to track changes that matter for products being placed on the market later.
Can variants with different intended purposes or different applicable conformity-assessment routes still be treated as one CRA product family?
Not usually.
The draft guidance makes same intended purpose one of the conditions for family reuse. Annex VII also requires the technical documentation to identify the product's intended purpose, and the draft guidance elsewhere says the product's core functionality should be clearly identified so the correct conformity-assessment regime can be determined.
Inference from those sources: if variants differ so much in intended purpose or core functionality that they lead to a different applicable CRA route, a single family-wide conformity assessment would normally not be the right approach.
What is a remote data processing solution under the CRA?
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.
Does the remote processing have to support the product's core function only?
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.
Can remote processing still be RDPS if the user can also perform the same function manually or locally?
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.
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.
Does RDPS cover the whole back-end or cloud infrastructure behind a product?
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.
Does every backend system behind a product become RDPS?
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.
Are ordinary websites or web pages remote data processing solutions?
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.
What does "under the responsibility of the manufacturer" mean for CRA RDPS?
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.
Does it matter who operates the remote solution day to day?
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.
If a product relies on third-party SaaS that is necessary for one of its functions, is that SaaS automatically 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.
If remote processing is used only for analytics, statistics, or future product development, is it usually 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.
Are internal systems like HR, payroll, CRM, CI/CD, security-update distribution to edge locations, pentesting, threat hunting, or red-team tooling usually RDPS?
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.