CRA Important Products Class II Explained

Class II Is the Stricter Important-Product Class

Article 7 divides important products with digital elements into Class I and Class II through Annex III. Class II is not a general label for products that a manufacturer considers highly secure or high risk. It applies when the product's core functionality matches one of the categories specifically placed in the Class II section of Annex III. The legal effect is important because Article 32 gives Class II a stricter conformity assessment framework than Class I. A manufacturer cannot simply select the ordinary internal-control route that can remain available in specified Class I circumstances. The classification should therefore be resolved early, before conformity evidence, certification strategy and launch scheduling have been fixed. Product architecture, intended purpose and actual supplied functionality matter more than commercial descriptions such as enterprise, secure, hardened or professional.

• Class II is part of Annex III.
• It remains an important-product category, not a critical-product category.
• Classification depends on core functionality.
• Article 32 applies stricter conformity procedures.

Annex III Currently Contains Four Class II Categories

The current Annex III Class II list contains four categories. The first covers hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments. The second covers firewalls and intrusion detection and prevention systems. The third covers tamper-resistant microprocessors. The fourth covers tamper-resistant microcontrollers. These categories are narrower than the Class I list, but each can occupy a security-critical position in systems on which other products or services depend. The list should be used together with Commission Implementing Regulation (EU) 2025/2392, which provides technical descriptions for the categories. Manufacturers should avoid expanding the list through analogy. A product that appears security-sensitive is not automatically Class II unless its core functionality fits the legal category and technical description.

• Hypervisors and qualifying container runtime systems.
• Firewalls and intrusion detection or prevention systems.
• Tamper-resistant microprocessors.
• Tamper-resistant microcontrollers.

Hypervisors and Container Runtime Systems Need Functional Analysis

The first Class II category is not every product associated with virtualisation or containers. Annex III refers to hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments. Commission Implementing Regulation (EU) 2025/2392 provides the technical description that should be used to determine whether a particular product performs the relevant core functionality. This makes product boundaries important. A management console, orchestration service, application deployed inside a container or ordinary development tool should not be placed into the Class II category merely because it interacts with a hypervisor or container environment. The manufacturer should identify whether enabling and controlling the relevant virtualised execution environment is a defining function of the product itself and preserve that analysis in the classification record.

• Do not classify by the word virtualisation alone.
• Identify the supplied product's core execution function.
• Separate runtime functionality from adjacent management tooling.
• Use the 2025/2392 technical description.

Firewalls and Intrusion Detection or Prevention Systems Are Class II

Firewalls and intrusion detection and prevention systems are explicitly placed in Class II. Recital 45 of the CRA uses these products to illustrate the core-functionality rule. A product whose core functionality is that of a firewall or intrusion detection or prevention system is subject to the Class II conformity framework. A different product that merely integrates firewall or intrusion-detection functionality does not become Class II solely because of that integration. This distinction matters for multifunction security platforms, routers, operating systems, cloud-connected appliances and other products that may include network-filtering features. The manufacturer needs to determine what the product is supplied to do as a product, rather than isolate one embedded capability and let that capability determine the entire classification.

Tamper-Resistant Chips Are Different From the Broader Class I Chip Categories

Annex III also distinguishes between broader security-related semiconductor categories in Class I and tamper-resistant semiconductor categories in Class II. Class I includes microprocessors and microcontrollers with security-related functionalities, as well as specified ASICs and FPGAs with security-related functionalities. Class II separately identifies tamper-resistant microprocessors and tamper-resistant microcontrollers. The distinction should therefore not be made simply from the fact that a chip implements encryption, secure boot or another security function. The manufacturer needs to assess the technical characteristics against the relevant 2025/2392 description and determine whether the product falls into the tamper-resistant Class II category. This is particularly important where a product family contains several variants with different physical security or resistance characteristics.

• Security-related functionality can appear in Class I.
• Tamper resistance can move the relevant processor or controller category into Class II.
• Review each product family and variant.
• Keep technical evidence supporting the classification.

Class II Does Not Use the Ordinary Internal-Control Route

Article 32(3) gives Class II manufacturers three conformity routes. The manufacturer can use EU-type examination under module B followed by conformity to EU-type based on internal production control under module C. It can use conformity assessment based on full quality assurance under module H. Where available and applicable, it can use a European cybersecurity certification scheme pursuant to Article 27(9) at assurance level at least substantial. Unlike the conditional Class I framework, Article 32(3) does not offer the ordinary module A internal-control route as a Class II option. This is the operational reason the Class I and Class II distinction must be made before conformity planning. A wrong classification can lead to the wrong assessment strategy, missing notified-body engagement and insufficient project lead time.

• Module B followed by Module C.
• Module H full quality assurance.
• Applicable European cybersecurity certification at assurance level at least substantial.
• No ordinary Class II module A internal-control option.

Class II Is Still Different From an Annex IV Critical Product

The phrase stricter assessment can make Class II and critical products sound interchangeable, but they are legally separate categories. Class II products remain important products under Article 7 and Annex III. Critical products are addressed by Article 8 and Annex IV. Where the Article 8 certification conditions are not met, Article 32 routes an Annex IV critical product to the procedures used for Class II products, but that does not convert the critical product into Class II. The legal category still matters because Article 8 creates a separate mechanism through which specified critical products can be required to obtain a European cybersecurity certificate under an applicable certification scheme. Compliance records should therefore state both the category and the assessment route instead of using assessment procedure as a substitute for classification.

• Class II belongs to Annex III.
• Critical products belong to Annex IV.
• They can use overlapping conformity procedures.
• The underlying legal classifications remain different.

Build the Class II Decision Into Product Release Planning

A Class II classification record should identify the exact product, version, intended purpose, core functionality and matching Annex III category. It should reference the relevant description in Commission Implementing Regulation (EU) 2025/2392 and explain why adjacent categories do or do not apply. The manufacturer should then record the selected Article 32 procedure, the notified body or certification dependency where applicable, the technical documentation required and the evidence owners responsible for preparation. Major functionality changes should trigger classification review because a product can move into or out of a listed functional category as architecture evolves. Annex III itself can also be amended through delegated acts. Treating classification as maintained product data therefore reduces the risk of discovering a Class II obligation only when a release is already approaching the market.

• Record the exact Class II category.
• Reference the applicable technical description.
• Select the Article 32 route early.
• Plan notified-body or certification dependencies.
• Link the classification to technical documentation.
• Review after significant product or legal changes.