---
title: "CRA 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: "CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking."
published_at: "2026-03-10"
updated_at: "2026-03-10"
keywords:
  - "CRA module A FAQ"
  - "CRA internal control"
  - "CRA self-assessment"
  - "CRA module A eligibility"
  - "CRA class I module A"
  - "CRA Article 32 module A"
  - "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 Module A FAQ

CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking.

*FAQ* *EU* *Cyber Resilience Act*

## EU Cyber Resilience Act FAQ Module A

Use this CRA FAQ to understand the internal-control route under module A, when it is available, what evidence it still requires, and how it interacts with harmonised standards, FOSS exceptions, and later modifications.

Built for product, engineering, certification, and compliance teams using the CRA self-assessment route.

Module A is the CRA's internal-control conformity-assessment route, but it is not a shortcut around real compliance work. This FAQ focuses on who can use module A, when Article 32 blocks it, what documentation and evidence it still requires, and how it behaves for FOSS, updates, and later substantial modifications.

## What is module A under the CRA?

Module A is the internal control conformity-assessment procedure.

Under this route, the manufacturer itself ensures and declares, on its sole responsibility, that the product satisfies the essential cybersecurity requirements in Part I of Annex I and that the manufacturer meets the vulnerability-handling requirements in Part II of Annex I.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1)(a), Annex VIII Part I point 1
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.1

## Is a notified body involved in module A?

No.

Module A is the CRA's self-assessment route. The Commission FAQ states expressly that no notified body participates in this procedure.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part I
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.1

## Is module A the default CRA conformity-assessment route?

Yes, for products that are not pushed by Article 32 into a stricter route.

Article 32(1) lists module A as one of the CRA's general conformity-assessment procedures. In practice, it is the route available unless the product falls into the specific cases where Article 32(2), 32(3), or 32(4) require another procedure.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1)-(4)

## Which CRA products can use module A?

Module A is available for:

- products that are not important products or critical products

- important products of class I where Article 32(2) does not force a third-party route

- important products of class I or II that qualify as free and open-source software, if the technical documentation is made public at the time of placing on the market

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1), Article 32(2), Article 32(5)
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.1

## Can a manufacturer choose module A even when module B+C or module H would also be available?

Yes, where Article 32 does not make a stricter route mandatory.

For products covered by Article 32(1), the manufacturer may demonstrate conformity by using module A, module B+C, module H, or, where available and applicable, a qualifying European cybersecurity certification scheme.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1)

## When is module A no longer enough for an important product of class I?

Module A is no longer enough for the essential cybersecurity requirements for which the manufacturer has not applied, or has only partly applied, the relevant harmonised standards, common specifications, or qualifying European cybersecurity certification schemes, or where those tools do not exist.

In that situation, Article 32(2) requires module B+C or module H for those requirements.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(2)

## If a class I product uses harmonised standards only in part, can module A still be used for the rest?

Only in a limited sense.

Inference from Article 32(2): where a class I product relies only partly on the relevant harmonised standards, common specifications, or qualifying certification schemes, the remaining essential cybersecurity requirements must go through module B+C or module H. Article 32(2) is framed requirement-by-requirement, not as an automatic all-or-nothing ban on all use of module A.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(2)

## Can an important product of class II use module A?

Not as a general rule.

Important products of class II must use the procedures listed in Article 32(3), unless the product qualifies 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(3), Article 32(5)

## Can a critical product use module A?

No.

Critical products listed in Annex IV must use the procedures in Article 32(4), which do not include module A.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(4)

## What is special about the Article 32(5) free and open-source software exception for module A?

It is a narrow exception for products qualifying as free and open-source software that fall under Annex III.

Article 32(5) allows those products to use one of the procedures listed in Article 32(1), including module A, provided that the technical documentation under Article 31 is made available to the public at the time the product is placed on the market.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(5)
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1 and 6.6

## Does module A still require technical documentation?

Yes.

Under Annex VIII Part I point 2, the manufacturer must draw up the technical documentation described in Annex VII. More broadly, Article 31 requires technical documentation that shows how the product and the manufacturer's processes comply with Annex I.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31, Annex VII, Annex VIII Part I point 2
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.6

## Does module A still require testing or other evidence?

Yes.

Module A is not a paperwork-only route. The manufacturer still has to verify that the product complies with the relevant essential cybersecurity requirements and be able to demonstrate that through technical documentation and supporting evidence.

The CRA does not mandate a single evaluation methodology. The Commission FAQ says manufacturers may verify conformity through testing or other mechanisms.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Article 31(1), Annex VII point 5, Annex VIII Part I point 1
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1 and 6.5

## Can the manufacturer use internal or external laboratories under module A?

Yes.

The Commission FAQ says the manufacturer may perform the relevant tests in its own laboratories, if available, or in external laboratories. Under module A, the manufacturer still remains solely responsible for the conformity assessment.

Sources for this answer:

- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.5
- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part I point 1

## Does module A cover only design, or also production and vulnerability handling?

It covers design, development, production, and vulnerability handling.

Annex VIII Part I point 3 is broader than a design-only check. It requires the manufacturer to take all measures necessary so that the relevant processes, and their monitoring, ensure compliance of both the product and the manufacturer's processes with Annex I.

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

## Does module A require the manufacturer to control serial production consistency?

Yes.

The Commission FAQ explains that, under module A, the manufacturer must ensure that production of the different units does not alter compliance with the CRA essential cybersecurity requirements.

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
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.1

## What has to happen before the manufacturer can affix the CE marking under module A?

The manufacturer must first be in a position to demonstrate that the product complies with the CRA.

After that, the manufacturer affixes the CE marking to each individual compliant product and draws up the written EU declaration of conformity.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28, Article 30, Annex VIII Part I point 4
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1, 6.7 and 6.8

## Is the declaration of conformity under module A linked to the product, not just to the route?

Yes.

Annex VIII Part I point 4.2 requires a written EU declaration of conformity for each product with digital elements, and the declaration must identify the product for which it has been drawn up.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28, Annex VIII Part I point 4.2

## What records must be kept under module A, and for how long?

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

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(13), Annex VIII Part I point 4.2

## Does module A mean the technical documentation has to be public?

No, not in general.

The Commission FAQ states that there is no general obligation to make the technical documentation public. The exception relevant here is the Article 32(5) rule for important free-and-open-source software using the Annex III exception.

Sources for this answer:

- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.6
- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(5)

## Can an authorised representative handle all module A obligations?

No.

Under Annex VIII Part I point 5, the authorised representative may fulfil only the manufacturer's obligations under point 4, on the manufacturer's behalf and under the manufacturer's responsibility, if the mandate expressly covers those obligations. That means the CE-marking and declaration steps can be mandated, but the wider manufacturer obligations that underpin module A are not generally transferred.

Article 17(2) reinforces that the obligations in Article 13(1) to (11), Article 13(12) first subparagraph, and Article 13(14) cannot form part of the authorised representative's mandate.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 17(2), Annex VIII Part I point 5

## Does module A protect the manufacturer from later market-surveillance scrutiny?

No.

Products assessed under module A remain subject to market surveillance. Authorities may request the technical documentation and related internal documentation, evaluate compliance, and act if they find non-compliance or formal non-compliance.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 53, Article 54, Article 58

## What usually makes a CRA module A file defensible in practice?

A defensible file is one that clearly shows how the manufacturer reached its compliance conclusion.

Grounded in Article 31, Annex VII, and the Commission FAQ, that usually means the documentation clearly identifies the applicable essential cybersecurity requirements, explains any justified non-applicability, records the cybersecurity risk assessment, and shows the technical means, standards, specifications, tests, or other evidence used to demonstrate conformity.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4), Article 31, Annex VII
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.8, 6.1, 6.5 and 6.6

## Can a default-category product still use module A even if no CRA harmonised standards, common specifications, or qualifying certification schemes exist yet?

Yes.

For default-category products, Article 32(1) makes module A available without conditioning it on the existence of harmonised standards, common specifications, or qualifying certification schemes. The stricter no-standard rule in Article 32(2) is specific to important products of class I. The Commission FAQ also says harmonised standards are voluntary and manufacturers may demonstrate conformity through other technical means, provided those means are documented in the technical documentation.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27, Article 32(1)-(2), Annex VII point (5)
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.7, 6.1 and 6.6

## Does choosing module A by itself give the product presumption of conformity?

No.

Module A is only a conformity-assessment route. Presumption of conformity comes from the Article 27 tools, such as harmonised standards, common specifications, or qualifying European cybersecurity certification schemes, to the extent they cover the relevant requirements. If the manufacturer does not use those means, it may still use module A where the product is eligible, but it must explain in the technical documentation how compliance is reached otherwise.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1), (5) and (8), Annex VII point (5)
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.7 and 6.6

## If the finished product integrates an important or critical component that does not follow harmonised standards, does that automatically block module A for the finished product?

No.

The Commission FAQ states that manufacturers are free to integrate important or critical components that were not designed in accordance with harmonised standards, regardless of whether such standards exist. It also explains that integrating an important or critical product into another product does not automatically render the finished product subject to the conformity-assessment procedures for that important or critical category. So the finished product's own core functionality still determines whether module A remains available.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(1), Article 32
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 3 and 7.4

## For the Article 32(5) free-and-open-source-software exception, does making the technical documentation public replace the rest of the module A work?

No.

Making the technical documentation public is an extra condition for important class I or class II products qualifying as free and open-source software to keep access to the Article 32(1) routes, including module A. It does not replace the ordinary module A activities. The manufacturer still has to perform the risk-based compliance work, verify conformity, draw up the technical documentation, and only then affix the CE marking and sign the 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), Annex VIII Part I
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1 and 6.6

## If a later software update does not qualify as a substantial modification, does the manufacturer still need to update the module A documentation?

Yes.

The March 2026 draft guidance says non-substantial updates do not trigger a new conformity assessment procedure or change the original placing-on-the-market date. But regardless of whether an update is substantial, manufacturers must keep the risk assessment and technical documentation accurate, complete, and continuously up to date. Article 31(2) also requires the technical documentation to be continuously updated where appropriate, at least during the support period.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Article 31(2)
- [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 15 and 106

## If a product is substantially modified later, can the manufacturer re-use module A?

Sometimes, yes.

The March 2026 draft guidance says a substantially modified product is treated as a new product and is newly placed on the market, so a new conformity assessment is required before that modified product is placed on the market. The same guidance also says existing documentation and tests may be re-used for unchanged parts. If the substantially modified product still falls in a category for which Article 32 allows module A, module A can be used again; if the modified product falls into a category that requires a stricter route, the applicable Article 32 route must be used instead.

Sources for this answer:

- [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1)-(4)
- [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.8
- [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 107-110

## 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 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 Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences.
- [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 Module A as a cited research workflow

Research Copilot can turn EU Cyber Resilience Act FAQ Module A 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 Module A 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/module-a