Cyber Resilience Act FAQ Module A

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. The route applies to products placed on the Union market from 11 December 2027, subject to the Article 32 eligibility rules.

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.

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) trigger is not met. Important class II products and critical products are generally directed to stricter procedures. Article 32(5) provides a separate exception for qualifying free and open-source software in Annex III; it does not extend to Annex IV critical products.

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.

The July 2026 Commission guidance explains that Module A can cover a class I product where all applicable requirements of a relevant harmonised standard are applied and the standard covers at least all cybersecurity risks of its core functionality. Additional functions or risks outside that standard still need documented measures, but do not automatically require a separate third-party assessment. If qualifying conformity tools are absent or not fully applied for the core-functionality risks, use the Article 32(2) third-party route.

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. If the Article 8(1) conditions are met, they require the certification procedure in Article 32(4)(a). If those conditions are not met, they require module B+C, module H, or, where available and applicable, an Article 27(9) European cybersecurity certification scheme at assurance level at least substantial.

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.

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.

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.

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.

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.

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.

For an important class I product, distinguish coverage of its core-functionality risks from additional risks elsewhere in the product. The July 2026 guidance permits Module A where all applicable standard requirements are applied and core-functionality risks are covered; the file must still document measures addressing every remaining product risk. If those eligibility conditions are not met, record the Module B+C or Module H route required by Article 32(2).

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 18(2) prevents the authorised representative mandate from covering several central Article 13 manufacturer duties, including the main design, risk, conformity, and vulnerability-handling obligations.

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.

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.

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.

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.