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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
What is core functionality under the EU Cyber Resilience Act?
The CRA uses core functionality to classify products, but the regulation itself does not give a standalone definition. The March 2026 draft Commission guidance describes it as the product's main features and technical capabilities, without which the product could not meet its intended purpose.
The assessment is not just a marketing-label exercise. The guidance points to the product's specific context and conditions of use, including instructions for use, promotional and sales materials, manufacturer statements, and technical documentation.
Why does core functionality matter for CRA classification?
A product with digital elements is treated as important if it has the core functionality of a category in Annex III. Critical-product treatment is tied to the core functionality of categories in Annex IV, subject to the CRA mechanism for critical products.
That classification changes the conformity-assessment route under Article 32. Products that do not have the core functionality of an Annex III or Annex IV category are described in the draft guidance as the default category and can use the Article 32(1) internal control route, although a manufacturer may choose a more rigorous procedure.
What source should manufacturers use to match a product to a listed CRA category?
Use the technical descriptions for important and critical product categories, not only Annex labels or market intuition. The Commission FAQ states that those descriptions are laid down in Commission Implementing Regulation (EU) 2025/2392.
In practice, compare the product's real features and technical capabilities against the relevant technical description, then record why the product matches, exceeds, falls short of, or sits outside that category.
Is CRA core functionality assessed for the whole product or for one embedded component?
Assess the product as a whole. Integrating a component that itself performs an important or critical function does not automatically give the finished product that component's classification.
The Commission FAQ gives concrete examples: an embedded browser in a news app does not make the news app a browser, and a secure element in a laptop does not make the laptop a secure-element product. The draft guidance applies the same logic to a smartphone integrating an operating system.
How should teams draw the product boundary before deciding core functionality?
Start with whether there is a product with digital elements: a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately.
The boundary can include software supplied with hardware even when it is downloaded later, if the hardware and software are designed to operate together so the product can perform its intended functions. The core-functionality analysis should then be run on that product boundary, not on an isolated delivery channel.
Can a product perform many functions but still have one core functionality for CRA classification?
Yes. The draft guidance says a product may not have more than one core functionality for deciding the applicable conformity-assessment regime.
Additional functions, such as a calculator or graphics editor in an operating system, can be ancillary. Their presence does not by itself prevent the product from having the listed core functionality.
Do ancillary functions ever change the CRA conformity-assessment work?
Ancillary functions may not change the category, but they still matter for the whole-product risk assessment and conformity evidence. The manufacturer must assess the product as a whole and address risks from additional functions or integrated components.
For example, if an antivirus product has antivirus core functionality but adds disk-cleaning or anti-tracking features, the core functionality can still drive the route, while the added functions must still be covered by risk treatment and documentation.