EU Cyber Resilience Act FAQ Product Families

No. "Product family" is not a defined CRA term.

The CRA instead refers to the product with digital elements, its intended purpose, versions of software affecting compliance, technical documentation, and the EU declaration of conformity. The Commission's July 2026 guidance is the source for the more practical idea that similar variants may sometimes share evidence, but that guidance is not a substitute for the regulation's product-level duties.

Only where the variants are similar in the ways that matter for cybersecurity.

A family file should show that the grouped variants share the same architecture, security-relevant design, intended purpose, update path, remote processing boundary, and cybersecurity risk profile. If those conditions are met, one risk assessment and one technical documentation set can be practical, but the file still has to identify each covered model or version and explain why the shared evidence covers it. The same guidance permits one conformity assessment and one EU declaration of conformity for the group when the shared evidence covers all relevant risks and requirements and the declaration clearly identifies every covered variant.

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 are listed below.

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. A changed variant does not always need a separate public product page or 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.

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.