Search every question across sub-FAQs

The manufacturer must take those changes into account for continuing conformity.

CRA Article 13(14) requires procedures for series production to remain in conformity and specifically mentions changes in harmonised standards, common specifications, and certification schemes by reference to which conformity is declared or verified. The Blue Guide adds that revised harmonised standards may have OJEU coexistence periods, after which only the revised standard gives presumption for new conformity assessments.

Yes. OJ publication creates the legal effect, but that legal effect can be restricted, prevented, or withdrawn.

The Blue Guide explains that the Commission may publish a reference with restrictions or later maintain, restrict, or withdraw the reference. Under the CRA safeguard process, if non-compliance is attributed to shortcomings in harmonised standards, common specifications, or certification schemes, the Commission may trigger the relevant standardisation objection or amendment process.

Record the exact version, OJ reference status where relevant, requirements covered, parts applied, product functions covered, processes covered, tests or assessments performed, and remaining risks or requirements handled by other means.

Coverage limits the evidence. A standard, common specification, certificate, or EU statement of conformity supports only the CRA requirements it covers. Technical documentation should map each applicable Annex I requirement to the applied conformity tool or to another documented solution, rather than treating a standard name or certificate as blanket proof.

Important products are products with digital elements whose core functionality matches a product category in CRA Annex III.

Annex III is split into class I and class II. The class matters because it changes the conformity assessment route under Article 32. Class I can sometimes use internal control, while class II must use one of the stricter Article 32(3) routes.

Critical products are products with digital elements whose core functionality matches a product category in CRA Annex IV.

Annex IV is narrower than Annex III. It currently identifies critical categories such as hardware devices with security boxes, smart meter gateways and other advanced-security devices, and smartcards or similar devices including secure elements. For classification work, teams should still use the official Annex IV text and the technical descriptions in Commission Implementing Regulation (EU) 2025/2392 rather than relying on product labels alone.

Start with the product's core functionality: the main features and technical capabilities without which the product would not meet its intended purpose.

Then compare those features and capabilities with the CRA Annex III or Annex IV category and the corresponding technical description in Implementing Regulation (EU) 2025/2392. Marketing category names, deployment environment, and partial feature overlap are not enough on their own.

No. The CRA says that integrating a product with the core functionality of an Annex III category does not by itself make the larger product subject to the important-product conformity routes.

The Commission FAQ applies the same practical logic to integrated important or critical components. A news app with an embedded browser, a laptop with a secure element, or a product that integrates an operating system still has to be classified by the core functionality of the product as a whole.

Yes. Additional or ancillary functions do not stop a product from being important or critical if the product's core functionality still matches a listed Annex III or Annex IV category.

The Commission FAQ gives examples: operating systems may include simple ancillary applications, and routers may integrate firewall functionality, without losing their operating-system or router core functionality. The reverse is also true: a product that can perform some SIEM-like functions is not automatically a SIEM if its actual core functionality is different.

An important product of class I can use the Article 32(1) procedures, including internal control based on module A, only when the Article 32(2) trigger is not met.

If the manufacturer has not applied, has applied only in part, or cannot use relevant harmonised standards, common specifications, or applicable European cybersecurity certification schemes at assurance level at least substantial for the relevant essential requirements, Article 32(2) requires either module B plus C or module H.

A manufacturer of important products of class II must use one of the Article 32(3) routes.

Those routes are module B plus C, module H, or, where available and applicable, a European cybersecurity certification scheme under Article 27(9) at assurance level at least substantial. Module A is not the ordinary route for class II, except for the separate free-and-open-source software rule in Article 32(5).

Critical products follow Article 32(4). The first route is a European cybersecurity certification scheme in accordance with Article 8(1), if the Article 8(1) conditions are met.

If those conditions are not met, the critical product uses one of the Article 32(3) procedures: module B plus C, module H, or an available and applicable European cybersecurity certification scheme under Article 27(9) at assurance level at least substantial.

No. Important or critical status mainly changes the conformity assessment route before placing the product on the market.

The substantive CRA cybersecurity obligations still come from the essential cybersecurity requirements, the manufacturer's risk assessment, vulnerability handling obligations, technical documentation, and related manufacturer duties. Important and critical products do not get a separate Annex I; they get stricter assurance paths where the CRA requires them.

No. Core functionality determines the product class and route, but the conformity assessment still covers the product as a whole.

The draft Commission guidance explains that additional or ancillary functions can create additional cybersecurity risks. A manufacturer may be allowed to use internal control for a class I product where a harmonised standard covers the core functionality, but the manufacturer still has to address risks outside that standard's coverage.

Not by itself. Classification turns on core functionality against Annex III or Annex IV, not only on whether a particular customer deploys the product in a sensitive environment.

Deployment risk still matters. The Commission FAQ gives a VPN example where one VPN version intended for critical infrastructure may require stronger risk treatment than another version intended for residential use. That affects the cybersecurity risk assessment and implementation of essential requirements, but it does not by itself rewrite the Annex III or Annex IV classification.

Article 32(5) gives a special route for products qualifying as free and open-source software that fall under Annex III.

If the product qualifies and the technical documentation is made public when the product is placed on the market, the manufacturer may use one of the Article 32(1) procedures. The text is limited to Annex III categories, so it does not create the same route for Annex IV critical products.