--- title: "CRA Technical Documentation FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/technical-documentation" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/technical-documentation" author: "Sorena AI" description: "CRA FAQ explaining Annex VII technical documentation, risk assessment evidence, conformity assessment files, vulnerability handling records, product families, RDPS, language, and authority access." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA technical documentation" - "CRA Annex VII" - "Cyber Resilience Act technical file" - "CRA cybersecurity risk assessment evidence" - "CRA vulnerability handling documentation" - "Cyber Resilience Act" - "CRA FAQ" - "Annex VII" - "Technical documentation" --- **[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 Technical Documentation FAQ CRA FAQ explaining Annex VII technical documentation, risk assessment evidence, conformity assessment files, vulnerability handling records, product families, RDPS, language, and authority access. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Technical Documentation Understand what the CRA technical file has to prove: Annex VII content, risk assessment decisions, vulnerability handling processes, conformity assessment evidence, support-period records, and authority access. For product, engineering, security, legal, and certification teams preparing a CRA evidence package before placing a product with digital elements on the EU market. CRA technical documentation is the manufacturer's evidence package for a product with digital elements. It is not just a filing exercise: Annex VII ties the file to product design, cybersecurity risk assessment, vulnerability handling, support-period decisions, test reports, conformity assessment, and records that market surveillance authorities or notified bodies may need to assess compliance. ## What is CRA technical documentation? CRA technical documentation is the product-level evidence file that shows how the manufacturer ensured conformity with the applicable essential cybersecurity requirements. Article 31 requires the file to contain all relevant data or details of the means used by the manufacturer to ensure conformity. Annex VII then sets the minimum content, where applicable, for the relevant product with digital elements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(1) establishes the technical-documentation obligation and Annex VII lists the minimum content. - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Section 6.6 explains that technical documentation must be comprehensive and clear enough to demonstrate CRA conformity. ## When does the technical documentation have to exist? The manufacturer must draw up the technical documentation before placing the product with digital elements on the market. After placing on the market, Article 31 requires the file to be continuously updated, where appropriate, at least during the support period. The Commission FAQ also treats the file as something that must be available when the product is placed on the market, regardless of where the records are physically stored. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12) requires the file before market placement; Article 31(2) requires updating during the support period where appropriate. - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Section 4.1.8 links the risk assessment evidence to the technical documentation kept for market surveillance authorities. ## What must Annex VII documentation contain? Annex VII requires, as applicable, a general product description, intended purpose, software versions affecting compliance, relevant hardware images or illustrations, and the user information and instructions from Annex II. It also requires design, development, production, and vulnerability handling information; the cybersecurity risk assessment; support-period determination information; standards, common specifications, certification schemes, or alternative technical solutions used; test reports; the EU declaration of conformity; and, where applicable, the software bill of materials for authority checks. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII points 1-8 define the minimum technical-documentation content. ## What evidence should the file keep for the cybersecurity risk assessment? The record should show the product's intended purpose and reasonably foreseeable use, the risks assessed across design, development, production, delivery, and maintenance, and how those risks informed the implementation of Annex I Part I requirements. Where a product-property requirement is treated as not applicable, Article 13(4) requires a clear justification in the cybersecurity risk assessment included in the technical documentation. That means the record should preserve the applicability decision, the reason for excluding the requirement, and any risk treatment used instead. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(4) and Annex VII point 3 require the cybersecurity risk assessment and applicability reasoning. - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Section 4.1 explains that the assessment covers risk identification, treatment, and implementation through the product lifecycle. ## Does the file need vulnerability handling and support evidence? Yes. Annex VII expressly requires information and specifications for the manufacturer's vulnerability handling processes. Useful CRA evidence includes the SBOM where applicable, the coordinated vulnerability disclosure policy, proof that a contact address exists for vulnerability reports, secure update distribution design, test reports for vulnerability handling processes, and the information used to determine the support period under Article 13(8). Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII points 2(b), 4, 6, and 8 cover vulnerability handling, support-period evidence, test reports, and SBOM treatment. - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Section 4.5.1 says the technical documentation should include information considered when determining the support period. ## How does the technical file connect to CRA conformity assessment? For module A, the manufacturer relies on internal control, verifies conformity, draws up the technical documentation, affixes CE marking, and declares conformity on its own responsibility. For module B+C, the manufacturer draws up the technical documentation and a notified body assesses the design based on that documentation and a specimen or sample. For module H, the manufacturer operates a full quality system and draws up technical documentation through that system while the notified body assesses the quality system. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Parts I-IV set the module A, B+C, and H conformity assessment procedures and their technical-documentation requirements. - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Sections 6.1-6.3 summarise how technical documentation is used in module A, module B+C, and module H. ## Can the file use harmonised standards, common specifications, or certification evidence? Yes, but the file must be explicit. Annex VII requires the list of harmonised standards, common specifications, or European cybersecurity certification schemes applied in full or in part. If the manufacturer did not use them, the documentation must describe the alternative solutions used to meet Annex I requirements and list other relevant technical specifications. If a standard, common specification, or scheme was applied only partly, the file must say which parts were applied. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII point 5 sets the documentation rules for standards, common specifications, certification schemes, and alternative solutions. ## Can one technical-documentation set cover several EU product laws? Yes, where the product is also subject to other Union legal acts requiring technical documentation. Article 31(3) allows one technical-documentation set if it contains the information required by the CRA and the information required by those other Union acts. The practical limit is completeness: the combined dossier must still let each applicable law's conformity case be assessed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(3) permits a single technical-documentation set for overlapping Union legal acts that require such documentation. ## Can module H technical documentation be part of the quality-system documentation? Yes. The Commission FAQ says technical documentation may form part of the quality-system documentation where a manufacturer uses a quality-system-based route such as module H. Under CRA Annex VIII Part IV, the quality system covers design, development, final product inspection and testing, and vulnerability handling. The application to the notified body includes technical documentation for one model of each product category intended to be manufactured or developed. Sources for this answer: - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Sections 6.3 and 6.6 explain the module H quality-system route and its link to technical documentation. - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV points 2 and 3.1(b) require quality-system documentation and technical documentation for module H. ## In what language can the technical documentation be written? For conformity assessment, Article 31(4) requires the technical documentation and related correspondence to be in an official language of the Member State where the notified body is established or in a language acceptable to that body. For market surveillance, the separate practical rule is authority comprehension: Article 13(22) and Article 53 require information, documentation, or data to be provided in a language easily understood by the requesting authority. The Commission FAQ says the file can be written in any language, but must be provided in an authority-understandable language when requested. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(4) covers notified-body language; Articles 13(22) and 53 cover market-surveillance access in an easily understood language. - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Section 6.6 distinguishes the file's internal language from the language needed for market-surveillance requests. ## Does the CRA technical documentation have to be public? Generally, no. The Commission FAQ states that there is no general obligation to make technical documentation available to customers or the public. The important exception is Article 32(5): manufacturers of qualifying free and open-source software in Annex III class I or II can use the CRA self-assessment route only if the technical documentation is made available to the public. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(5) creates the public-documentation condition for qualifying free and open-source software using self-assessment. - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Section 6.6 states the general non-public rule and the Article 32(5) exception. ## What can market surveillance authorities request beyond the Annex VII file? Authorities are not limited to a neat front-office dossier. On a reasoned request, manufacturers must provide the information and documentation necessary to demonstrate conformity. Article 53 allows market surveillance authorities, where necessary to assess conformity, to access data needed to assess product design, development, production, and vulnerability handling, including related internal documentation. For SBOMs, Annex VII includes them where applicable and further to a reasoned authority request when necessary to check compliance with Annex I. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(22), Article 53, and Annex VII point 8 define authority access to conformity documentation, evidence records, and SBOMs where necessary. - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Section 6.6 warns that technical documentation may be requested by market surveillance authorities and should be comprehensive and clear. ## Does the technical documentation have to be updated when the product changes? Yes, where the change affects the conformity case. Article 31(2) requires continuous updating where appropriate, at least during the support period. The CRA draft guidance applies the Blue Guide approach: technical documentation has to be updated to the extent the modification affects applicable requirements, while unaffected aspects do not need to be retested or redocumented. Security updates that do not amount to substantial modifications can still require the file to remain accurate and complete. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(2) requires appropriate updates to technical documentation during the support period. - [Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - Section 2.1 explains the New Legislative Framework approach to updating documentation after relevant product changes. - [Draft Commission guidance on the CRA](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 106 and 109-110 apply the Blue Guide change logic to CRA software updates and documentation. ## Do older product types need historic design records recreated? Not automatically. The CRA draft guidance says manufacturers should not be read as having to recreate original design and development test evidence for products designed before CRA application where doing so would not improve the product's security. That does not remove the current conformity burden. The manufacturer still needs a current CRA technical file that demonstrates conformity, including the cybersecurity risk assessment, test reports or other verification evidence, and Annex VII content that is available for conformity assessment and market surveillance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Article 31, and Annex VII point 6 require technical documentation and test-report evidence for CRA conformity. - [Draft Commission guidance on the CRA](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-35 address products designed before CRA application and the limits of recreating historic evidence. ## Is there a simplified technical-documentation format for smaller companies? Yes, but only in the way Article 33(5) provides. Microenterprises and small enterprises may provide the Annex VII elements using a simplified format once the Commission specifies that form by implementing act. Notified bodies must accept that simplified form for conformity assessment purposes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 33(5) establishes the simplified-format rule for microenterprises and small enterprises. ## Does the CRA impose one mandatory technical-file template? No. The CRA specifies the information that must be present, not one filing structure. A manufacturer can organise the file across tools, repositories, suppliers, and quality-system records, but the assembled evidence still has to be complete, clear, versioned, and producible when a notified body or market surveillance authority needs to assess conformity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31 and Annex VII define content requirements without prescribing one mandatory template. - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Section 6.6 focuses on comprehensive, clear documentation rather than a fixed filing format. ## How should the file handle versions, redesigns, and product families? The technical file should make clear which product version, software version, model, variant, or redesign each conformity record supports. The draft CRA guidance allows reuse of one cybersecurity risk assessment, one technical-documentation set, and one conformity assessment for variants in a product family only where the products share the same architecture, security-relevant design, intended purpose, and cybersecurity risks. Differences that affect cybersecurity, such as communication interfaces, software stacks, update mechanisms, or remote connectivity, must be reflected in the risk assessment, technical documentation, and conformity assessment where necessary. Sources for this answer: - [Draft Commission guidance on the CRA](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-161 explain when product-family reuse is possible and when variant differences require updated evidence. - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31 and Annex VII require product-specific technical documentation that can support conformity assessment. ## How should remote data processing solutions be documented? If a product has a remote data processing solution (RDPS) or relies on relevant third-party cloud solutions, the technical documentation should identify and describe those solutions. The draft CRA guidance says the same RDPS documentation may be reused across product conformity assessments, but the RDPS must still be declared in each product's technical documentation. The risk assessment should also cover RDPS risks, third-party cloud-service risks treated similarly to third-party components, and relevant product-environment risks. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1)-(2), Article 13(2), and Annex VII connect RDPS to product scope, risk assessment, and technical documentation. - [Draft Commission guidance on the CRA](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 162-192 explain RDPS scope, third-party cloud reliance, risk assessment, and reuse of RDPS documentation. ## Can a manufacturer keep the technical documentation split across internal systems and suppliers? Yes, in principle, but the responsibility remains with the manufacturer. The CRA requires the documentation to be drawn up, contain the required Annex VII content, be available before placing on the market, be kept up to date where appropriate, and be provided to authorities on reasoned request. The statute does not require one physical folder, but fragmented storage is risky if it prevents the manufacturer from producing a coherent, complete, authority-readable file. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Article 13(22), Article 31, and Article 53 define the manufacturer's responsibility to create, maintain, and provide documentation. - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Sections 4.1.8 and 6.6 support the need for available, comprehensive, clear documentation for market-surveillance use. ## Primary sources - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Official Cyber Resilience Act legal text supporting this FAQ and its article-level compliance conclusions. ## Topic Guides - [CRA Applicability Test for Products With Digital Elements](/artifacts/eu/cyber-resilience-act/applicability-test.md): Check whether the EU Cyber Resilience Act applies to a hardware, software, firmware, open-source, or connected product before conformity planning. - [CRA Article 14 Reporting Obligations for Vulnerabilities and Incidents](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Article 14 guide to CRA reports for actively exploited vulnerabilities and severe product-security incidents, including deadlines, CSIRT routing, users, and evidence. - [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 explaining Blue Guide market-access concepts for products with digital elements: placing on the market, making available, imports, CE marking, operator roles, online sales, stock, and testing exceptions. - [CRA CE Marking FAQ | Conformity Assessment, EU Declaration, Evidence](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): Practical CRA CE marking answers for products with digital elements: conformity assessment, EU declaration, technical documentation, standards, software placement, and launch evidence. - [CRA Component Due Diligence FAQ | Third-Party Software, FOSS, SBOMs](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): Cyber Resilience Act FAQ on manufacturer due diligence for integrated components, third-party software, FOSS dependencies, SBOMs, vulnerability handling, and evidence records. - [CRA Conformity Assessment and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): How to choose a Cyber Resilience Act conformity route, prepare technical documentation, issue the EU declaration of conformity, and affix CE marking. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Important and Critical Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): Cyber Resilience Act FAQ on when manufacturers can use module A, when module B+C or module H is required, and how important and critical products affect the route. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Annex I, Updates](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on Article 13 cybersecurity risk assessments, Annex I applicability, intended purpose, foreseeable use, technical documentation, and update evidence. - [CRA deadlines and compliance calendar | EU Cyber Resilience Act](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the Cyber Resilience Act entry into force, staged application dates, Article 14 reporting deadlines, transitional rules, and review dates. - [CRA Declaration of Conformity FAQ | Annex V, Simplified Declaration, CE Marking](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): FAQ on the Cyber Resilience Act EU Declaration of Conformity: Annex V contents, simplified Annex VI wording, CE marking link, technical documentation, retention, updates, and operator duties. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic-operator roles: manufacturers, importers, distributors, authorised representatives, substantial modification, traceability, and evidence controls. - [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 Annex I product cybersecurity requirements, vulnerability handling, secure-by-default design, risk assessment, documentation, lifecycle duties, and user information. - [CRA Essential Cybersecurity Requirements in Annex I](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): An official source guide to the Cyber Resilience Act Annex I requirements for product security, vulnerability handling, secure-by-design controls, documentation, and evidence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Components, RDPS](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): FAQ on Cyber Resilience Act hardware and software boundaries: combined products, standalone software, source code, components, remote data processing, SaaS and market-placement changes. - [CRA Harmonised Standards FAQ | Presumption of Conformity, Common Specifications](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): Cyber Resilience Act FAQ on how harmonised standards, common specifications, certification schemes, and OJ publication affect CRA conformity evidence. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Conformity Assessment](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): FAQ on CRA important and critical products, Annex III and Annex IV classification, core functionality, and conformity assessment consequences. - [CRA Integrated Components and Dependencies FAQ | Third-Party Software and SBOM Evidence](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): Cyber Resilience Act FAQ on integrated components, third-party software, remote data processing, SBOM-style evidence, upstream fixes, FOSS dependencies, and manufacturer responsibility. - [CRA Interplay With EU Product Laws FAQ | RED, Machinery, Data Act](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): Official source CRA FAQ on overlap with the Radio Equipment Directive, Machinery Regulation, GPSR, Data Act, exclusions, declarations, documentation, and existing certificates. - [CRA Known Exploitable Vulnerabilities at Launch FAQ](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): FAQ for Cyber Resilience Act launch decisions: known exploitable vulnerabilities, CVEs, component flaws, secure-by-default settings, release gates, Article 14 reporting, and evidence. - [CRA Legacy Products FAQ | Pre-11 December 2027 Products](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): Cyber Resilience Act FAQ on products placed on the market before 11 December 2027, Article 14 reporting, substantial modification, distributor stock, spare parts, and records. - [CRA Manufacturer Obligations FAQ | Article 13, Annex I, CE Marking](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): FAQ for Cyber Resilience Act manufacturers covering Article 13 duties, risk assessment, Annex I, vulnerability handling, support periods, documentation, conformity assessment, reporting, CE marking, and evidence controls. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Corrective Action, Safeguards](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): Cyber Resilience Act FAQ on market-surveillance authorities, investigations, corrective action, withdrawal, recall, safeguards, sweeps, documentation access, and penalties. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA Module B+C FAQ explaining EU-type examination, conformity to type, notified-body evidence, production control, CE marking, declarations, and certificate changes. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA Module H FAQ explaining the full-quality-assurance route, notified-body assessment, quality-system scope, technical documentation, CE marking, declarations, and records. - [CRA Notified Bodies FAQ | Scope, Modules B+C and H, Certificates](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): Practical CRA FAQ on when notified bodies are needed, how CRA bodies are designated, what their notified scope means, and how Module B+C and Module H assessments work. - [CRA Open-Source Software FAQ | FOSS Scope, Stewards, Manufacturers](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): Cyber Resilience Act FAQ for free and open-source software: commercial activity, steward duties, manufacturer due diligence, vulnerability handling, public documentation, and user obligations. - [CRA Over-the-Air Updates FAQ](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): Cyber Resilience Act FAQ on OTA updates, automatic security updates, secure update distribution, support-period evidence, and offline update paths. - [CRA penalties and fines FAQ | Article 64 fine caps](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): FAQ on EU Cyber Resilience Act Article 64 penalties: maximum fine tiers, turnover caps, national enforcement, economic operators, reporting duties, and open-source steward carve-outs. - [CRA Penalties and Fines: Article 64 Caps and Enforcement Context](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Article 64 of the EU Cyber Resilience Act sets administrative fine ceilings for Annex I, manufacturer, reporting, economic-operator, notified-body, and information-request breaches. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families, variant grouping, shared technical documentation, conformity evidence, and when cybersecurity-relevant differences need separate assessment. - [CRA Products with Digital Elements Scope | EU Cyber Resilience Act](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Apply the EU Cyber Resilience Act scope test for software, hardware, remote data processing, components, open-source software, exclusions, and economic-operator roles. - [CRA Products With Digital Elements Scope FAQ](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): EU Cyber Resilience Act FAQ on products with digital elements, software, firmware, remote data processing, components, exclusions, market placement, and CRA operator boundaries. - [CRA Remote Data Processing Solutions FAQ | Product Scope, Cloud and Backend Boundaries](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): FAQ on how the EU Cyber Resilience Act treats remote data processing solutions, manufacturer-controlled backends, third-party cloud services, SaaS, risk assessment, documentation, and user information. - [CRA Reporting Obligations FAQ | Article 14, CSIRTs, ENISA, User Notices](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): Cyber Resilience Act FAQ on Article 14 reporting for actively exploited vulnerabilities and severe incidents, including timing, CSIRT routing, ENISA access, user notices, and evidence. - [CRA Requirements | Annex I, Manufacturer Duties and CE Evidence](/artifacts/eu/cyber-resilience-act/requirements.md): Map Cyber Resilience Act requirements from Annex I to manufacturer duties, vulnerability handling, user information, technical documentation, declaration of conformity, and CE marking evidence. - [CRA SBOM and Vulnerability Management Template](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Build a CRA-ready SBOM and vulnerability handling record with component inventory, triage, remediation, disclosure, reporting, update, and technical documentation fields. - [CRA Secure-by-Default FAQ | Default Configuration and Annex I Controls](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): Cyber Resilience Act FAQ on secure-by-default configuration, automatic security updates, attack surface reduction, authentication, data minimisation, user information, and tailor-made products. - [CRA Security Updates vs Functionality Updates FAQ](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): Cyber Resilience Act FAQ on classifying security updates, functionality updates, support-period duties, automatic updates, user notices, and substantial-modification review. - [CRA Substantial Modification FAQ | Updates, Repairs, Manufacturer Duties](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): Cyber Resilience Act FAQ on when software updates, repairs, spare parts, and post-market changes become substantial modifications and trigger CRA manufacturer, evidence, and conformity duties. - [CRA Support Period FAQ | Expected Product Lifetime, Security Updates, User Information](/artifacts/eu/cyber-resilience-act/faq/support-period.md): Practical CRA FAQ on how manufacturers determine support periods, disclose support end dates, keep security updates available, and document support-period evidence. - [CRA Tailor-Made Products FAQ | Bespoke Products, Market Placement, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): FAQ on when a bespoke product may be treated as tailor-made under the EU Cyber Resilience Act, what the carve-out changes, and what manufacturers still need to document. - [CRA Transition Period FAQ | Entry Into Force, Application Dates, Reporting, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, 2026 reporting, 2027 application, legacy products, stock, customs timing, and software versions. - [CRA Update Availability and Software Archives FAQ](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): FAQ on CRA security-update availability, support-period notices, optional public software archives, historical versions, and Article 13(10) software-version limits. - [CRA User Information and Transparency FAQ | Annex II Instructions](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): Practical CRA FAQ on Annex II user instructions, support-period disclosure, vulnerability contacts, update notices, importer and distributor information. - [CRA vs RED Cybersecurity Delegated Act](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the EU Cyber Resilience Act with the RED cybersecurity delegated act for connected and radio equipment, including scope, timing, evidence, and transition treatment. - [CRA vs UK PSTI Act | Cyber Resilience Act Comparison](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare cited EU Cyber Resilience Act duties with UK PSTI planning points, with UK legal details clearly marked for separate source review. - [CRA Vulnerability Handling and Disclosure | Article 14 Reporting and Security Updates](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): How EU Cyber Resilience Act manufacturers should run vulnerability intake, remediation, coordinated disclosure, Article 14 reporting, secure updates, and evidence records. - [CRA Vulnerability Handling FAQ | Support Periods, Components, Reporting](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): Practical CRA FAQ on vulnerability handling: SBOMs, remediation, coordinated disclosure, component issues, security updates, support periods, Article 14 reporting, and user notices. - [Cyber Resilience Act Module A FAQ | Internal Production Control](/artifacts/eu/cyber-resilience-act/faq/module-a.md): FAQ on when CRA Module A internal production control is available, when it is blocked, and what documentation, testing, standards, and evidence it still requires. - [EU CRA Compliance Program for Manufacturers and Economic Operators](/artifacts/eu/cyber-resilience-act/compliance.md): Build a Cyber Resilience Act compliance program around product scope, Annex I security requirements, conformity assessment, technical documentation, vulnerability reporting, and market surveillance. - [EU Cyber Resilience Act Checklist for Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): A CRA checklist for products with digital elements: scope, Annex I security controls, vulnerability handling, Article 14 reporting, technical documentation, conformity assessment, CE marking, and support-period evidence. - [EU Cyber Resilience Act Core Functionality FAQ | CRA Product Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality, product boundaries, remote data processing, integrated components, ancillary functions, and software changes that affect product classification. - [EU Cyber Resilience Act FAQ](/artifacts/eu/cyber-resilience-act/faq.md): Direct CRA FAQ answers on scope, economic-operator roles, essential requirements, vulnerability reporting, conformity assessment, CE marking, support periods, and market surveillance. - [EU Cyber Resilience Act Repairs and Spare Parts FAQ](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ for repairs, spare parts, legacy products, security updates, substantial modification, and responsibility after product changes. - [EU Cyber Resilience Act Technical Documentation and Audit File](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build an audit-ready CRA technical file around Article 31 and Annex VII: product scope, risk assessment, vulnerability handling, conformity evidence, testing, and retention. *Recommended next step* *Placement: after key answers* ## Build a CRA Annex VII evidence map Map each Annex VII item to product owners, repositories, risk-assessment records, test evidence, vulnerability handling records, and authority-ready source references. - [Open CRA Research Copilot](/solutions/research-copilot.md): Turn Annex VII requirements into cited evidence questions for product, security, and certification teams. - [Talk through CRA implementation](/contact.md): Review technical-file gaps, risk-assessment coverage, vulnerability handling evidence, and conformity assessment readiness. --- [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/technical-documentation