EU Cyber Resilience Act Product Classification: Categories and Conformity Routes

Julian Meroi · Published 13 October 2026 · Last reviewed 13 October 2026

Your product’s Cyber Resilience Act classification determines which conformity assessment procedures are available before placing it on the EU market. The assessment starts with the product’s core functionality and the categories in Annexes III and IV. Every in-scope product still needs an assessment of its cybersecurity risks and the applicable essential requirements. Article 7, Article 8, Article 13(2)-(3), Article 32.

This guide explains the rules, then shows how they played out when we classified a portfolio of industrial software offerings.

The CRA’s main requirements apply from December 11, 2027. Article 14 reporting obligations apply from September 11, 2026. Classification does not postpone reporting until the main application date. See Article 71 and our Cyber Resilience Act reporting requirements guide.

Establish which product you are classifying

First confirm that the product falls within the CRA’s scope, including the exclusions in Article 2 and any delegated act adopted under Article 2(5). Delegated Regulation (EU) 2025/1535, for example, excludes products within the scope of Regulation (EU) No 168/2013 on two- or three-wheel vehicles and quadricycles, except L1e category vehicles designed to pedal. A product that is outside scope should not be assigned the default category.

Identify the hardware or software being placed on the market, its intended purpose, and the functions supplied with it. Include any remote data processing solution meeting Article 3(2): processing at a distance for which the software is designed and developed by the manufacturer, or under its responsibility, and whose absence would prevent the product from performing one of its functions. A cloud connection alone does not settle this question. Article 3(1)-(2) and (23).

Check whether modules are also supplied separately. The Commission guidance explains that modules offered for separate purchase, licensing or subscription are products in their own right and need classification by their respective core functionalities. For modules supplied solely within an integrated product, the assessment concerns that integrated product. Commission guidance, paragraph 145 and example 61.

The Cyber Resilience Act product categories

Consult the complete Annex III and Annex IV lists. The examples above are abbreviated category labels, not classifications of every product sold under those names. The Commission explains the default category in guidance paragraph 137 and footnote 22. Commission guidance.

Match the product against Implementing Regulation (EU) 2025/2392 as well as the CRA annexes. Its Annex I describes important products; its Annex II describes critical products. These annex numbers differ from the corresponding CRA annex numbers. Implementing Regulation, Article 2.

An internal low, medium or high risk rating does not assign the statutory category. Two products with the same core functionality can have different operational risks. Those risks affect the security measures and evidence required. The Commission FAQ illustrates this with VPNs intended for residential use and critical infrastructure. Article 7, Article 8, Article 13(2)-(3), Commission FAQ, section 3.3.

Determine the product’s core functionality

The Commission guidance describes core functionality through the main features and technical capabilities needed for the product’s intended purpose. Examine the actual design together with instructions, sales material and technical documentation. The guidance warns against descriptions that misrepresent a product’s capabilities to avoid the applicable procedure. Commission guidance, paragraphs 139 and 142-144.

For a practical assessment:

1. Describe the intended purpose and the capabilities needed to fulfill it.
2. Compare those capabilities with the relevant technical descriptions in Regulation 2025/2392.
3. Explain the role of additional functions and integrated components.
4. Check whether separately supplied modules require their own assessments.
5. Record the conclusion, supporting evidence and unresolved facts.

This is an example of an implementation approach based on Commission guidance paragraphs 139-145 and CRA Annex VII. The CRA does not mandate this five-step format.

Integrated components and additional functions

Article 7(1) expressly states that integrating an important product does not in itself subject the complete product to that component’s conformity assessment procedure. The Commission guidance applies the same reasoning to critical components. It gives the example of a smartphone incorporating an operating system: the operating system’s presence alone does not classify the smartphone as an operating system. The whole product’s security must still be assessed. Article 7(1), Commission guidance, paragraphs 140-141 and 147.

Additional features also do not automatically remove a product from a listed category. The guidance’s router example includes an ancillary firewall function while retaining routing as the product’s core functionality. That example depends on the stated facts; it does not establish that every multifunction network appliance is Class I. Commission guidance, paragraph 152 and example 63.

The guidance states that a product has one core functionality for determining its conformity assessment regime. Where two categories appear plausible, examine the actual intended purpose and capabilities further. Do not select a category solely because it offers a preferred assessment route. Commission guidance, paragraphs 143-145.

Conformity assessment and when a notified body is needed

A default-category product does not need a notified body: internal control (module A) is available. An important Class I product can use internal control only where it applies harmonized standards, common specifications or European cybersecurity certification schemes at assurance level at least substantial in full. Otherwise a notified body is involved through module B+C or H for the requirements they do not cover. A Class II product needs module B+C or H, or certification under an available and applicable European cybersecurity certification scheme pursuant to Article 27(9), at assurance level at least substantial. A critical product uses European cybersecurity certification where the conditions of Article 8(1) are met, and otherwise the Class II procedures. Article 32, Article 8(1).

Our CRA conformity assessment guide explains each procedure, the evidence to prepare and the steps to the EU declaration of conformity and CE marking.

The following summarizes Article 32. The free and open-source software provision below can change the available procedures for Annex III products.

The European Health Data Space Regulation also introduces a specific rule for products classified as electronic health record (EHR) systems under that regulation. Article 104(3) of Regulation (EU) 2025/327 inserts CRA Article 32(5a), which refers their CRA conformity assessment to the relevant procedure in Chapter III of Regulation (EU) 2025/327. Check this rule alongside the phased application dates in Article 105 of that regulation and Article 71 of the CRA when planning an EHR system assessment. Our reader shows the CRA as originally published, without this amendment.

Module A is the manufacturer’s internal control procedure. B+C combines EU-type examination by a notified body with conformity to the approved type based on internal production control. Module H is conformity based on full quality assurance, involving notified-body assessment and surveillance of the quality system. The procedures cover the product and the manufacturer’s relevant processes. Article 32, Annex VIII.

Class I: check standards coverage and additional functions

For the harmonized-standard route, Commission guidance paragraph 149 says that all applicable requirements of a relevant cited standard must be applied and its scope must cover at least all cybersecurity risks associated with the product’s core functionality. Paragraphs 150-152 explain that additional functions can require further measures while the product remains eligible for internal control. The manufacturer must demonstrate conformity for the whole product. Footnote 25 extends the guidance to the relevant common specifications and certification schemes, subject to the specified Commission acts. Commission guidance, paragraphs 148-152 and footnote 25.

Presumption of conformity covers the essential requirements addressed by the cited standards or relevant specifications. It does not automatically extend to additional functions whose risks are outside that coverage. Record the applicable reference, scope and any additional measures. Article 27, Commission guidance, paragraphs 153-155.

Publication of a standard by a standards organization and publication of its reference in the Official Journal are separate steps. Verify the applicable CRA reference before relying on presumption of conformity. Existing IEC 62443 work can support the technical assessment, but its CRA legal effect needs this separate check. Our IEC 62443 and Cyber Resilience Act guide explains the relationship. Article 27(1) and (6).

Critical products and EU cybersecurity certification

An Annex IV classification does not by itself establish a universal requirement for EUCC certification at a particular level. Article 8(1) provides for Commission delegated acts specifying the products and required assurance level under an available adopted scheme. Article 32(4) provides the alternative where those conditions are not met. Verify the applicable acts and coverage when selecting the route. Article 8(1), Article 27(9), Article 32(3)-(4).

Free and open-source software

For software qualifying as free and open-source software in an Annex III category, Article 32(5) permits the Article 32(1) procedures if its Article 31 technical documentation is made public at the time the product is placed on the market. This provision covers important Class I and II software. It does not extend to Annex IV critical products and does not remove the essential cybersecurity requirements. Article 32(5).

What a portfolio classification showed

We recently assessed the scope and classification of several dozen software offerings for an industrial software manufacturer. The portfolio covered production monitoring and analytics, manufacturing and business-system add-ons, operator training, inspection and remote support. The assessment worked from the client’s product information and public material, so several conclusions depend on facts the client still had to confirm.

On the available facts, more than half of the offerings were default-category products. About a third were either default-category products or outside the CRA, depending on how they are supplied. A few were human support services outside the CRA, and a few could move into an important category once open functional questions are answered. None was critical.

Three lessons carry over to most software portfolios.

Scope took more work than category

For about a third of the offerings, the open question was whether a product with digital elements was supplied at all. The Commission guidance explains that software is in scope when it is provided to the user and operated on, or as part of, an electronic information system on the user’s side. Software that executes remotely and is merely accessed by the user, such as a web application used only through a browser, is not on that basis alone a product with digital elements. Commission guidance, paragraphs 20-21.

Once a supplied product exists, remote processing is part of it where the manufacturer designed and developed that software, or had it done under its responsibility, and its absence would prevent the product from performing one of its functions. For a suite with on-premises and cloud options, that test has to be applied function by function. Article 3(2), Commission guidance, section 8.

Some offerings were tools used only inside the client’s own organization. Products manufactured for one’s own use are not placed on the market, so the CRA does not apply to them unless they are also placed on the market as separate products. Where such a tool is supplied to customers or to other legal entities in the same group, that supply needs its own check. An internal tool can still form part of another supplied product’s remote data processing where the conditions of Article 3(2) are met; for one of these tools, that question was still open. Commission FAQ, section 1.5, Article 3(2).

The facts that settled scope were:

• what the customer receives: executable software, access to a remotely operated service, or content such as training material;
• the deployment options actually offered;
• which legal entity supplies the product in the EU;
• which product functions depend on remote processing, and who designed and developed that processing.

Near-miss categories were decided by core functionality

Several offerings had features that resembled a category in Annex III. In each case we compared the core functionality with the technical description in Implementing Regulation (EU) 2025/2392, Annex I. Its recital 5 states that a product able to perform the functions of a listed category, but whose core functionality differs, does not meet that category’s technical description. Implementing Regulation, recital 5 and Annex I.

Each conclusion rests on what the software does as supplied, its intended purpose and its reasonably foreseeable use. Product names and marketing labels did not decide any of them.

Suites, shared components and risk

• Integrated components. Several systems included components that might be important products if sold alone. The host product is classified by its own core functionality. A component also supplied separately requires its own classification. The risk assessment still covers the whole product, including those components. Article 7(1).
• Shared components. The same software, libraries and remote services recurred across products and business units. A shared register of components, versions, test results, vulnerabilities and support arrangements lets each product team reuse evidence, after confirming it covers that product’s version, configuration and interfaces.
• One product, one assessment. Product lists often contain the same product under more than one name. Before reusing an assessment and its technical documentation, confirm that the entries share the same product, version and legal manufacturer.
• Category is separate from risk. Many of these offerings are default-category products that support production lines where a failure has serious consequences. Their security measures follow from the cybersecurity risk assessment that Article 13(2)-(3) requires for every product, whatever its category. Our CRA risk assessment guide explains how to carry it out. Article 13(2)-(3).

Keep the conclusion with the technical documentation

Article 31 requires documentation explaining how the product and the manufacturer’s processes meet the essential requirements. Annex VII specifies information including intended purpose, architecture, risk assessment, applied standards or other solutions, and test reports. Keep the classification rationale and route decision with that evidence. A classification record per product is a practical way to organize the reasoning. It supplements the required documentation. We record:

• the manufacturer’s legal entity, product name and version;
• the intended purpose and the capabilities needed to fulfill it;
• the deployment and supply model, including separately supplied components;
• the remote processing inside the product boundary, and the external services it depends on;
• the categories compared, with the technical descriptions used;
• the conclusion, the evidence behind it and any facts still open.

This record format is our implementation practice. The CRA does not prescribe these fields. Article 31, Annex VII.

Review the record when product changes affect its basis. Article 31(2) requires the technical documentation to be continuously updated, where appropriate, at least during the support period. A revised intended purpose can also be relevant to substantial modification under Article 3(30). The consequences need assessment for the particular change. Article 31(2), Article 3(30).

Our CRA technical documentation guide covers the rest of the file: the Annex VII contents, traceability from risks to test results, and retention.

Meroi Security can help assess product scope and classification, identify the applicable conformity route, and prepare the risk assessment and technical evidence. Where a notified body is required, its formal assessment is a separate part of the procedure. Explore our Cyber Resilience Act compliance services.