Search every question across sub-FAQs

The decisive test is whether the variant differences are relevant to cybersecurity or to the applicable conformity route.

Commercial similarity, shared branding, or a shared enclosure is not enough. Compare the variants against the CRA risk assessment and Annex VII documentation: intended purpose, essential functions, security properties, software versions affecting compliance, remote data processing, vulnerability handling, interfaces, update mechanisms, and the evidence used to verify the essential requirements.

Differences that do not affect cybersecurity properties usually do not justify a separate CRA assessment by themselves.

Typical non-security differences can include:

- physical housing

- color

- form factor

- memory size, where it does not alter security behavior or update capacity

- packaging, labels, or accessory bundles that do not change the product with digital elements

Record the reason. The family file should say why each difference does not change the attack surface, essential functions, security properties, vulnerability handling, support-period assumptions, or the test evidence used for conformity.

Differences that change the cybersecurity profile need a documented reassessment and may require a separate conformity route.

Treat the variant as a separate assessment candidate when it changes communication interfaces, software stack, authentication model, update mechanism, remote connectivity, remote data processing, third-party components, vulnerability handling, intended purpose, security environment, or the standards and test evidence used to demonstrate conformity. The answer is not always a separate public product page or separate declaration, but the technical file must make the changed risk and evidence boundary visible.

Yes, but only if the representative evidence actually covers the variants' security behavior.

A manufacturer should be able to explain why the tested representative model exercises the highest-risk or relevant common functions, interfaces, update paths, remote dependencies, and vulnerability handling processes for the grouped variants. If an untested variant adds a new interface, different software branch, different update flow, or different remote processing dependency, the representative evidence may no longer be enough.

No.

Even where documentation is reused across a family, the CRA still requires product identification and traceability. Annex II requires user-facing information enabling unique identification, Annex V requires the declaration's object to identify the product, Annex VII requires versions of software affecting compliance, and Annex VIII requires the declaration to identify the relevant product or product model. The Commission FAQ also emphasizes that technical documentation must be comprehensive enough for market surveillance authorities.

No.

Where a new variant introduces new cybersecurity risks or changes how the essential cybersecurity requirements are implemented, the existing risk assessment, test rationale, and technical documentation must be updated before relying on the family file for that variant. If the change affects a notified-body certificate, approved type, vulnerability handling process, or quality-system scope, the relevant conformity-assessment route may also require additional approval or reassessment.

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.

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.

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.

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.

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.