Use this CRA FAQ to understand when similar variants can share one CRA assessment and documentation set, when differences force updates, and how family reuse interacts with placing on the market and conformity duties.
Built for product, certification, engineering, and compliance teams managing variants and family-wide CRA evidence.
Structured answer sets in this page tree.
Cited legal and guidance references.
The CRA does not define "product family" in the regulation text, but the draft guidance explains when similar variants can share one risk assessment, documentation set, and conformity assessment. This FAQ focuses on the limits of family-wide reuse, representative testing, later variants, and the continued obligation to keep each series product in conformity.
Not expressly in the regulation text.
The CRA itself requires manufacturers to document and assess the conformity of the relevant product with digital elements. The more specific idea that similar variants, models, or configurations can in some cases be handled together as a product family is explained in the Commission's March 2026 draft guidance.
Article 13(2), Article 31, Annex VII, Annex VIII
section 7.4, points 158 to 161
Research Copilot can turn EU Cyber Resilience Act FAQ Product Families into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ.
Start from EU Cyber Resilience Act FAQ Product Families and move to source-backed decisions and evidence workflows.
Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ.
Where the variants are similar in the ways that matter for cybersecurity.
The draft guidance says reuse is possible where products in the same family share the same architecture, security-relevant design, and intended purpose, and are exposed to the same cybersecurity risks. In that case, the manufacturer may rely on a single cybersecurity risk assessment, a single set of technical documentation, and a single conformity assessment, as long as all variants are adequately covered.
points 158 to 159
Article 13(2), Article 31
The decisive test is whether the differences between the variants are relevant to cybersecurity.
The guidance makes clear that commercial similarity alone is not enough. The question is whether the differences affect cybersecurity properties, exposure to threats, or the way the essential cybersecurity requirements are implemented.
points 160 to 161
Differences that do not affect cybersecurity properties usually do not require separate risk assessments or separate conformity assessments.
The draft guidance gives examples such as:
- physical housing
- colour
- form factor
- memory size
- other characteristics that are not security-relevant
Differences that change the cybersecurity profile usually do.
The draft guidance gives examples such as different communication interfaces, software stacks, update mechanisms, or remote connectivity. Those differences can affect threat exposure or the implementation of the essential requirements, so they must be reflected in the risk assessment and, where necessary, in the conformity assessment and technical documentation.
points 160 to 161
Article 13(2), Article 31(2)
Yes, where the variants are based on the same design and share the same risk profile.
The March 2026 draft guidance says manufacturers are not expected to provide test evidence for every variant in that situation. It gives that clarification especially for products designed before the CRA applies, but the logic is tied to the shared design and shared risk profile rather than to a purely commercial grouping.
points 34 to 35, Example 6, points 158 to 161
Article 13(12), Annex VII point 6, Annex VIII
No.
Even where documentation is reused across a family, the CRA still requires product identification and traceability. Annex VII requires information enabling unique identification, Annex V requires the declaration's object to identify the product, and Annex VIII requires the declaration to identify the relevant product or product model. The Commission FAQ also says technical documentation must reflect redesigns, changes, and how versions can be identified.
Annex V point 4, Annex VII point 1, Annex VIII Part I point 4.2, Annex VIII Part IV point 5.2
section 4.1.8 and section 6.8
section 4.3
No.
Where a new variant introduces new cybersecurity risks or changes how the essential cybersecurity requirements are implemented, the existing risk assessment and conformity documentation must be updated. The CRA itself also requires the technical documentation to be kept up to date.
point 161
Article 31(2)
Yes, but the RDPS still needs to be declared in each affected product's technical documentation.
The March 2026 draft guidance says documentation concerning the same RDPS can be reused across product conformity assessments, but each product's documentation must still indicate that the product has RDPS or relies on relevant third-party cloud solutions and must describe them.
points 188 to 190
Article 31, Annex VII
No.
The family concept is about reusing assessment and documentation where that is justified. Product-law concepts like placing on the market still apply to each individual product. The CRA and the Blue Guide both treat placing on the market and compliance timing at the level of the individual product, not just the type or family.
Recital 38, Article 3(21), Article 6
section 2.3
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).
section 5.1
Article 13(8)
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.
points 158 to 161
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.
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.
points 158 to 161
Article 31(2)
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.
Article 13(14)
section 3.1 and section 4.4
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.
points 128 and 158 to 161
Annex VII points 1 and 4, Article 32