CRA Important Products Class I Explained

Class I Is an Annex III Legal Category

Class I is not a general label for any product with a moderate cybersecurity risk. It is a defined part of Annex III to the Cyber Resilience Act. A product is treated as a Class I important product when its core functionality matches one of the Class I categories and the relevant technical description. That distinction matters because the CRA's default product category can ordinarily use internal control, while Class I introduces additional conditions around the conformity route. The classification analysis should therefore begin with the exact product supplied to the market and its core functionality. Manufacturers should avoid classifying by company type, customer sector or broad security reputation. The product category and technical description are the legal anchor.

• Class I is set out in Annex III.
• It applies to products whose core functionality matches a listed Class I category.
• It is not a company-level or customer-sector label.
• The result affects Article 32 conformity planning.

Annex III Contains a Broad Range of Class I Categories

The Class I list covers a broad range of products. These include identity management systems and privileged access management software and hardware, standalone and embedded browsers, password managers, antimalware software, VPN products, network management systems, SIEM systems, boot managers, public key infrastructure and digital certificate issuance software, physical and virtual network interfaces, operating systems, routers, internet modems and switches, specified microprocessors and microcontrollers with security-related functionalities, smart-home general-purpose virtual assistants, specified smart-home products with security functionalities, specified internet-connected toys and specified personal wearable products. The list is detailed because Class I classification has direct conformity consequences. A portfolio inventory should therefore map each product against the exact category rather than use a single broad cybersecurity-product flag.

• Identity and access technologies are represented.
• Endpoint and network security technologies are represented.
• Operating-system and network infrastructure categories are represented.
• Specified chips and connected consumer products are also represented.

The 2025 Technical Descriptions Narrow the Classification Question

Commission Implementing Regulation (EU) 2025/2392 provides technical descriptions for the Class I categories. Those descriptions are particularly important where an Annex III label is broad. The implementing regulation describes what counts as identity management, password management, VPN functionality and other listed categories in functional terms. It also includes examples for certain categories, but the examples are illustrative and not exhaustive. The manufacturer should therefore read the Annex III label and the corresponding technical description together. A product name alone may be too broad or too narrow. The classification record should reference the relevant technical description and explain how the product's core functionality matches or falls outside it.

• Use Annex III and Implementing Regulation 2025/2392 together.
• Focus on functional characteristics.
• Do not treat illustrative examples as a closed product list.
• Keep the comparison in the product evidence record.

Core Functionality Prevents Incidental Features From Driving Classification

The core-functionality test is especially important for Class I because many modern products contain features that resemble Annex III categories. A business platform can include a password vault, a device can include a browser, a connected product can contain a network interface, and an appliance can embed VPN or authentication functionality. Article 7 makes clear that integration of a listed product does not by itself make the larger product subject to the important-product conformity procedures. The manufacturer should identify whether the Class I function defines the product as supplied or is simply one supporting capability inside a different product. Architecture diagrams, intended-purpose documentation, feature descriptions and product packaging can all help support that analysis.

Class I Does Not Always Require a Notified Body

A key distinction between Class I and Class II is that Class I can retain an internal-control route under specified conditions. Article 32 addresses the situation where the manufacturer has not applied, or has applied only in part, relevant harmonised standards, common specifications or an applicable European cybersecurity certification scheme at assurance level at least substantial, or where those tools do not exist. In that situation, the product and the manufacturer's processes must be submitted to one of the stricter procedures identified by Article 32. Conversely, where the Article 32 conditions supporting internal control are satisfied, Class I does not automatically require notified-body assessment. The practical question is therefore not simply whether the product is Class I, but also how conformity with the applicable Annex I requirements is being demonstrated.

• Class I is stricter than the default category.
• Third-party assessment is not automatic in every Class I case.
• The use and availability of standards, specifications or certification matter.
• Document the basis for the chosen conformity route.

If the Class I Conditions Are Not Met, Article 32 Requires a Stricter Route

Where the Class I conditions for internal control are not satisfied, Article 32 directs the manufacturer to a stricter conformity procedure. The available routes include EU-type examination under module B followed by conformity to EU-type based on internal production control under module C, or conformity assessment based on full quality assurance under module H. These procedures are described in Annex VIII. The choice affects the form of evidence, quality-system expectations, external review and project timing. A manufacturer that discovers late that its Class I product cannot rely on the internal-control route may face avoidable launch pressure. Classification and standards mapping should therefore be completed early enough to reserve notified-body capacity and close evidence gaps before formal assessment.

• Module B plus Module C is one available route.
• Module H full quality assurance is another available route.
• Annex VIII describes the procedures.
• Early classification reduces assessment scheduling risk.

Class I and Class II Should Not Be Treated as the Same Bucket

Both classes are important products under Article 7, but the conformity logic differs. Class II products are subject to the stricter Article 32 routes without the same conditional internal-control pathway available to Class I. The Class II list is also narrower, covering hypervisors and qualifying container runtime systems, firewalls and intrusion detection or prevention systems, tamper-resistant microprocessors and tamper-resistant microcontrollers. This distinction is why a classification worksheet should record the exact Annex III class rather than merely mark the product as important. A future delegated act can also amend Annex III, including moving categories between classes, so the class conclusion should remain reviewable over the product lifecycle.

• Class I and Class II are both Annex III important products.
• Their Article 32 conformity routes differ.
• The exact class should be recorded in the technical compliance record.
• Monitor Annex III changes over time.

A Class I Readiness Record Should Connect Classification to Evidence

For each suspected Class I product, create a record that begins with the product boundary and core functionality, identifies the exact Annex III category and 2025/2392 technical description, and then maps the result to the chosen Article 32 route. The record should identify which harmonised standards, common specifications or certification schemes are being relied on and which Annex I requirements they cover. Any gaps should be visible because partial application can affect whether internal control remains available for the relevant requirements. The same record can point to the cybersecurity risk assessment, technical documentation, test evidence and release decision. This turns Class I classification from a legal label into an operational conformity plan that engineering and compliance teams can maintain together.

• Record the Annex III Class I category.
• Record the matching technical description.
• Record standards, specifications or certification relied on.
• Map coverage to applicable Annex I requirements.
• Record the selected Article 32 procedure.
• Link the result to product evidence and release control.