--- title: "CRA Product Families FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/product-families" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/product-families" author: "Sorena AI" description: "CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA product families FAQ" - "CRA variants family file" - "CRA representative testing" - "CRA shared risk assessment variants" - "CRA product family conformity" - "CRA later variants" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Product Families FAQ CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Product Families 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. 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. ## Does the CRA itself define a "product family"? 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. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2), Article 31, Annex VII, Annex VIII - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 7.4, points 158 to 161 ## When can one CRA assessment cover more than one product variant? 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. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 158 to 159 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2), Article 31 ## What is the decisive CRA test for deciding whether variants belong in the same product family? 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. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 160 to 161 ## What kinds of differences usually do not require separate CRA family treatment? 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 Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 160 ## What kinds of differences usually do require separate assessment or documentation updates? 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. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 160 to 161 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2), Article 31(2) ## Can a manufacturer use representative test evidence for a product family instead of testing every variant separately? 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. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 34 to 35, Example 6, points 158 to 161 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Annex VII point 6, Annex VIII ## Does a product family approach remove the need to identify the relevant model or version in the documentation? 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. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex V point 4, Annex VII point 1, Annex VIII Part I point 4.2, Annex VIII Part IV point 5.2 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 and section 6.8 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.3 ## If a new variant changes the cybersecurity profile, can the manufacturer keep relying on the old family file without updates? 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. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 161 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(2) ## If the same remote data processing solution supports several products, can the RDPS documentation be reused? 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. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 188 to 190 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31, Annex VII ## Does calling several variants a product family mean they count as one product for placing on the market? 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. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 38, Article 3(21), Article 6 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## 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). Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.1 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - 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. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 158 to 161 ## 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. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 159 ## 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. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 158 to 161 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(2) ## 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. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(14) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 3.1 and section 4.4 ## 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. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 128 and 158 to 161 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII points 1 and 4, Article 32 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Product Families as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Product Families into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Product Families and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/product-families