Search every question across sub-FAQs

Yes, but reuse of remote data processing solution evidence does not erase the product boundary.

A remote data processing solution is part of a CRA product when it is designed and developed by or under the responsibility of the manufacturer and the product cannot perform one of its functions without it. If the same RDPS supports several products, the RDPS evidence can be reused as common evidence, but each product file should still identify the RDPS, explain why it is in scope, and show how that dependency affects the product's risk assessment, support-period assumptions, vulnerability handling, and test evidence.

No.

The family concept is about evidence reuse where justified. It does not collapse several variants into one legal object for placing on the market.

Product-law concepts such as placing on the market, CE marking, technical documentation availability, and declaration of conformity still have to work for the individual product, product type, or product model covered by the relevant route. That matters especially for later units, legacy types, changed models, and support-period records.

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). That means a family file should preserve the support-period basis used for each production or release wave, not only the first family launch.

No.

Shared branding, industrial design, SKU naming, or platform marketing does not by itself justify one CRA family file. The relevant question remains whether the products share the same security-relevant design, intended purpose, software and hardware boundary, remote dependencies, update mechanism, vulnerability handling process, and cybersecurity risk profile.

No.

The family approach is a reuse option, not a requirement. A manufacturer can keep separate files for variants that are commercially important, certified through different routes, managed by different engineering teams, or easier to explain separately to a notified body or market surveillance authority.

Separate files are often cleaner where variants use different software branches, cloud services, support periods, standards, test plans, or EU declaration scopes.

Sometimes, yes.

A later variant can remain within the same family if the existing risk assessment, technical documentation, test evidence, and declaration scope already cover the variant's security-relevant characteristics.

Do not add the variant by SKU list alone. Before release, compare intended purpose, essential functions, software versions affecting compliance, update behavior, RDPS dependencies, interfaces, components, standards, test reports, support-period rationale, and conformity route. If any of those change the cybersecurity profile, update the file and decide whether a separate assessment, notified-body interaction, or declaration update is needed.

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 should include a change log or review gate for production changes, supplier or component changes, software branch changes, standards changes, vulnerability-handling changes, and new test evidence that affects later products being placed on the market.

Not usually.

Different intended purposes or different applicable CRA categories can change both the risk assessment and the conformity-assessment route.

Annex VII requires intended purpose in the technical documentation, and Article 32 sets different conformity-assessment options depending on the product category and use of standards, common specifications, or certification schemes. If one variant falls into a different CRA route, or relies on different evidence to use that route, it should not be hidden inside a generic family file. At minimum, the file needs a clear route-by-route split.

Record every covered model and version, the shared intended purpose and architecture, security-relevant differences, remote data processing dependencies, interfaces, software branches, update mechanisms, component sets, support-period assumptions, applicable CRA category, conformity route, and representative test rationale.

The record should also define a change gate. A later variant should be compared with that baseline before release, and the risk assessment, technical documentation, test evidence, declaration scope, or notified-body approval should be updated wherever the change affects the evidence on which family reuse depends. This is a practical evidence structure, not an official CRA form.

A product is in scope when three elements are present together:

- it is a product with digital elements

- it is made available on the EU market

- its intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network

The Article 2 exclusions must then also be checked. Most CRA obligations apply from 11 December 2027. Article 14 reporting applies from 11 September 2026, including to otherwise in-scope products placed on the market before full application.

A product with digital elements is a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.

Yes.

The Commission FAQ expressly lists standalone software, such as downloadable mobile apps and programs, as examples of products with digital elements.

Yes.

Firmware falls within the CRA when it is software placed on the market, including when it is supplied separately for integration into hardware devices.

Yes.

The Commission FAQ lists integrated circuits, motherboards, and sensors as examples of hardware that can be products with digital elements when the other scope conditions are met.

Yes.

The draft guidance says the delivery channel does not decide the product boundary by itself. If a hardware device is designed to operate together with specific software so that it can perform its intended functions, the hardware and that software together constitute the product with digital elements even if the software is downloaded later through a separate channel such as a website or app store.