---
title: "Cyber Resilience Act Module A FAQ"
canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/module-a"
source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/module-a"
author: "Sorena AI"
description: "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."
published_at: "2026-03-10"
updated_at: "2026-03-10"
keywords:
  - "CRA Module A"
  - "Cyber Resilience Act internal production control"
  - "CRA self assessment"
  - "CRA technical documentation"
  - "CRA harmonised standards"
  - "Cyber Resilience Act"
  - "CRA FAQ"
  - "Internal production control"
---
**[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)

---

# Cyber Resilience Act Module A FAQ

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.

*FAQ* *EU* *Cyber Resilience Act*

## Cyber Resilience Act FAQ Module A

Module A is the CRA internal production control route. It can avoid notified-body involvement, but it still requires the manufacturer to prove conformity through risk assessment, technical documentation, testing or equivalent verification, production controls, vulnerability-handling controls, CE marking, and an EU declaration of conformity.

This FAQ helps check when Module A is available, when Article 32 requires module B+C or module H, and what evidence a self-assessment file needs to contain.

Module A under the Cyber Resilience Act is a self-assessment route, not a low-evidence route. The manufacturer remains responsible for the product and for the vulnerability-handling processes, including design, development, production, monitoring, technical documentation, CE marking, and the declaration of conformity.

## What is Module A under the Cyber Resilience Act?

Module A is the CRA conformity assessment procedure based on internal production control.

Under Annex VIII Part I, the manufacturer ensures and declares, on its sole responsibility, that the product with digital elements satisfies the applicable product cybersecurity requirements in Annex I Part I and that the manufacturer's vulnerability-handling processes satisfy Annex I Part II.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part I defines internal control and places responsibility for product and vulnerability-handling conformity on the manufacturer.
- [Blue Guide on EU product rules](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - The module table describes Module A as internal production control covering design and production, with no conformity-assessment body involvement.

## Does Module A involve a notified body?

No. Module A is the CRA self-assessment route.

The Commission CRA FAQ states that no notified body participates in Module A. A manufacturer can still use external expertise or laboratories, but that does not turn Module A into a notified-body assessment and does not move responsibility away from the manufacturer.

Sources for this answer:

- [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - FAQ section 6.1 explains Module A and confirms that notified bodies do not participate in this procedure.
- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part I sets the Module A obligations on the manufacturer rather than on a notified body.

## Which CRA products can normally use Module A?

Products with digital elements that are not listed as important or critical products can use Module A under Article 32(1). The manufacturer may also choose a stricter route, such as module B+C or module H, but Article 32(1) does not require that for default-category products.

Important class I products can use Module A only where the Article 32(2) conditions are met. Important class II products and critical products are generally directed to stricter procedures, except for the specific free and open-source software exception in Article 32(5).

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1) lists Module A for general products; Article 32(2)-(5) sets stricter routes and the FOSS exception.
- [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - FAQ section 6.1 summarises which conformity-assessment procedures apply to default, important, and critical products.

## When is Module A not enough for an important class I product?

For an important class I product, Module A is not enough for the applicable essential cybersecurity requirements where the manufacturer has not applied, has only partly applied, or cannot apply relevant harmonised standards, common specifications, or qualifying European cybersecurity certification schemes.

For those requirements, Article 32(2) requires module B+C or module H. The practical control is therefore requirement-by-requirement: identify the applicable Annex I requirements, map the harmonised standard, common specification, or certification coverage, and send uncovered or partly covered requirements through the stricter route.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(2) makes module B+C or module H mandatory for class I requirements not fully covered by the listed conformity tools.
- [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - FAQ section 6.2 lists class I products without applied harmonised standards as a case where module B+C or H is mandatory.

## Can important class II or critical products use Module A?

Important class II products cannot generally use Module A. Article 32(3) sends them to module B+C, module H, or a qualifying European cybersecurity certification scheme.

Critical products listed in Annex IV also do not use Module A under the ordinary Article 32(4) route. They require module H or, where applicable, a European cybersecurity certification scheme that reaches at least the assurance level specified by the CRA route.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(3) and Article 32(4) set the routes for important class II and critical products.
- [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - FAQ section 6.1 identifies class II and critical products as categories requiring stricter assessment routes, subject to the Article 32(5) exception.

## What is the free and open-source software exception for Module A?

Article 32(5) allows products qualifying as free and open-source software that fall within Annex III to use the Article 32(1) procedures, including Module A, if the Article 31 technical documentation is made available to the public when the product is placed on the market.

This is an access condition for the route. It does not remove the underlying Module A work: the manufacturer still needs the risk assessment, technical documentation, verification evidence, production controls, vulnerability-handling processes, CE marking, and declaration of conformity.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(5) creates the FOSS exception and requires public availability of the technical documentation for that route.
- [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - FAQ section 6.6 confirms that public technical documentation is not generally required, except for the Article 32(5) FOSS self-attestation case.

## What technical documentation is required under Module A?

Module A still requires the manufacturer to draw up the technical documentation described in Annex VII. Article 31 requires that documentation to show how the product and the manufacturer's processes comply with Annex I.

For a Module A file, the useful minimum is not just a product description. It should include intended purpose, design and development information, production and vulnerability-handling processes, the cybersecurity risk assessment, support-period information, applied harmonised standards or alternatives, test reports, and copies of user information and instructions.

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 the technical documentation content; Annex VIII Part I point 2 requires it for Module A.
- [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - FAQ section 6.6 explains that technical documentation must be comprehensive and clear because market surveillance authorities may request it.

## Does Module A require testing?

Module A requires verification evidence, but the CRA does not mandate one single evaluation methodology.

Annex VII requires reports of tests carried out to verify conformity of the product and the vulnerability-handling processes. The Commission FAQ explains that manufacturers can perform relevant tests or testing procedures in their own laboratories, if available, or in external laboratories, and that the manufacturer assumes sole responsibility for the conformity assessment.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII point 6 requires test reports for product and vulnerability-handling conformity where tests are carried out.
- [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - FAQ section 6.5 covers evaluation methodology, internal and external laboratories, and manufacturer responsibility.

## What production controls does Module A require?

Module A is not limited to design review. Annex VIII Part I requires the manufacturer to take all measures necessary so that the design, development, production, vulnerability handling, and monitoring processes ensure compliance of both the product and the manufacturer's processes with Annex I.

In practice, a Module A evidence file should connect product versions, build and release controls, component intake checks, security test results, vulnerability-handling procedures, update procedures, and production or release approvals. The point is to show that later units or releases do not drift away from the assessed compliant configuration.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part I point 3 covers design, development, production, vulnerability handling, and monitoring under Module A.
- [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - FAQ section 6.1 includes the manufacturer's duty to ensure that production of different units does not alter CRA compliance.

## Do harmonised standards create Module A eligibility by themselves?

No. Harmonised standards, common specifications, and qualifying European cybersecurity certification schemes are conformity tools. They can provide presumption of conformity for covered requirements, but they are not the same thing as the conformity-assessment route.

For default-category products, Module A can be used even where the manufacturer demonstrates conformity through other technical means. For important class I products, the coverage of harmonised standards, common specifications, or qualifying certification schemes matters because Article 32(2) can require module B+C or module H for uncovered requirements.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27 covers presumption of conformity tools; Article 32 separately governs conformity-assessment routes.
- [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - FAQ sections 4.1.7 and 6.6 explain the role of harmonised standards and the need to document other technical means.

## What should the standards coverage record show?

A standards coverage record should show which Annex I requirements are covered by each harmonised standard, common specification, or qualifying certification scheme; which parts were applied in full or in part; and which requirements were met by other technical solutions.

That record is especially important for important class I products, because it supports the decision on whether Module A can cover the requirement or whether module B+C or module H is needed for that requirement.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII point 5 requires a list of applied standards, specifications, or schemes and descriptions of other solutions where they are not applied.
- [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - FAQ section 6.6 explains that the technical documentation must show how compliance with the essential requirements is demonstrated.

## Can an authorised representative take over Module A?

Only partly. An authorised representative may fulfil the CE-marking and EU declaration obligations in Annex VIII Part I point 4 on the manufacturer's behalf and under the manufacturer's responsibility if the mandate covers that work.

The core manufacturer obligations are not generally transferred. Article 17(2) prevents the authorised representative mandate from covering several central Article 13 manufacturer duties, including the main design, risk, conformity, and vulnerability-handling obligations.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 17(2) limits the authorised representative mandate; Annex VIII Part I point 5 limits Module A representative tasks to point 4 obligations.

## When can the CE marking and declaration be completed under Module A?

Only after the manufacturer has completed the applicable Module A conformity work with a positive result.

Annex VIII Part I then requires the manufacturer to affix the CE marking to each individual compliant product and draw up a written EU declaration of conformity for each product. The declaration identifies the product and must be kept with the technical documentation for the required retention period.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28, Article 30, and Annex VIII Part I point 4 cover the CE marking and declaration steps after conformity assessment.
- [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - FAQ sections 6.7 and 6.8 explain CE marking and declaration of conformity sequencing.

## How long must Module A records be kept?

The manufacturer must keep the EU declaration of conformity together with the technical documentation at the disposal of national authorities for 10 years after the product has been placed on the market or for the support period, whichever is longer.

That record should stay usable during the support period, because Article 31 also requires technical documentation to be kept accurate, complete, and continuously updated where appropriate.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31 and Annex VIII Part I point 4.2 cover continuous technical-documentation maintenance and record retention.

## Does Module A stop market surveillance authorities from reviewing the product?

No. Module A removes notified-body involvement from the assessment route, but it does not remove market surveillance.

Market surveillance authorities can request data and documentation, evaluate products that may present a significant cybersecurity risk, and act where technical documentation is unavailable, incomplete, or formal non-compliance persists.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Articles 53, 54, and 58 cover access to documentation, national market-surveillance procedures, and formal non-compliance.

## What evidence makes a Module A self-assessment defensible?

A defensible Module A file should let a reviewer trace the compliance conclusion from product scope to requirement mapping to verification evidence.

The core evidence set is: product identity and intended purpose; classification and Article 32 route rationale; cybersecurity risk assessment; Annex I requirement mapping; standards, common-specification, or certification coverage; explanations for non-applicable or partly covered requirements; test reports or other verification records; vulnerability-handling process evidence; production or release-control records; user information; CE-marking record; EU declaration of conformity; and retention ownership.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13, Article 31, Annex VII, and Annex VIII Part I together define the manufacturer obligations and evidence needed for Module A.
- [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - FAQ sections 4.1.8, 6.1, 6.5, and 6.6 explain risk-assessment documentation, testing, technical documentation, and Module A responsibilities.

## 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 Technical Documentation FAQ | Annex VII Evidence and Technical File](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ explaining Annex VII technical documentation, risk assessment evidence, conformity assessment files, vulnerability handling records, product families, RDPS, language, and authority access.
- [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.
- [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*

## Turn Module A into a reviewable evidence file

Research Copilot helps map CRA Module A eligibility, Annex I requirements, standards coverage, technical documentation, verification evidence, and owner sign-offs into one cited file.

- [Open Research Copilot](/solutions/research-copilot.md): Build a CRA Module A route rationale, evidence checklist, and cited documentation map.
- [Talk through implementation](/contact.md): Review Module A eligibility, documentation gaps, and product evidence controls before CE marking.


---

[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/module-a
