How to Determine a Product's CRA Classification

Step 1: Confirm CRA Scope Before Classifying the Product

Classification should not begin with Annex III. The first question is whether the supplied product is a product with digital elements within the CRA framework and whether any relevant exclusion or special interaction changes the analysis. A product that is outside the Regulation does not become subject to the CRA merely because it resembles an Annex III or Annex IV category. The manufacturer should identify what is being made available on the Union market, how software and hardware form the supplied product, whether remote data processing is part of the product where relevant, and which economic operator is acting as manufacturer. This creates the legal and technical object that will then be classified. Separating scope from classification also prevents teams from using high-risk category lists as a substitute for the broader product-scope analysis.

• Identify the supplied product.
• Confirm CRA scope.
• Check exclusions or special product regimes.
• Identify the manufacturer before classification.

Step 2: Define the Product Boundary

A classification can change depending on what is treated as the product. A platform may include several applications, security modules, cloud-connected functions and third-party components. A hardware appliance may contain an operating system, firewall, network interfaces and a secure element. The CRA does not require every internal component to dictate the classification of the complete product. Article 7 expressly states that integration of a product having the core functionality of an Annex III category does not by itself make the larger product subject to the important-product conformity procedures. The manufacturer should therefore document the product boundary, separately supplied components, integrated components and functions that define the commercial product. Architecture diagrams, product specifications, packaging and licensing models can help support that boundary.

• Identify what is supplied as one product.
• Separate integrated components from separately marketed products.
• Map software, hardware and remote dependencies.
• Preserve evidence supporting the selected boundary.

Step 3: Identify the Product's Core Functionality

Core functionality is the central bridge between the product and the CRA category lists. The manufacturer should identify the functions that define why the product exists and what users principally rely on it to do. Secondary capabilities, optional modules and embedded security controls should be distinguished from those defining functions. Marketing terms can help describe the product but should not control the legal conclusion. A platform described as a security suite may perform several functions, while a router can include firewall functionality without necessarily becoming a Class II firewall product. The analysis should explain which functions are fundamental to the supplied product and why. This functional description then becomes the basis for screening Annex III and Annex IV.

• Describe the principal product functions.
• Separate defining functions from ancillary features.
• Avoid relying only on product names.
• Use architecture and intended-purpose evidence.

Step 4: Screen Annex III Class I

The first important-product screen is Annex III Class I. The current Class I list covers categories such as identity management, browsers, password managers, antimalware software, VPN products, network management systems, SIEM systems, boot managers, public key infrastructure software, network interfaces, operating systems, routers and specified semiconductor and connected-consumer categories. A match should not be decided from the category heading alone. Commission Implementing Regulation (EU) 2025/2392 supplies the technical descriptions. Where the product's core functionality matches the Class I category, the manufacturer should record the category and then analyse the conditions in Article 32(2) that determine whether internal control remains available or a stricter procedure is required.

• Screen every plausible Class I category.
• Use the corresponding technical description.
• Record why each plausible category matches or does not match.
• Map a Class I result to Article 32(2).

Step 5: Screen Annex III Class II

The Class II screen is shorter but particularly important because Class II removes the ordinary conditional internal-control pathway. Annex III currently contains four Class II categories: qualifying hypervisors and container runtime systems, firewalls and intrusion detection or prevention systems, tamper-resistant microprocessors, and tamper-resistant microcontrollers. If the product's core functionality matches one of those categories under the applicable technical description, Article 32(3) governs the conformity route. The manufacturer should not downgrade a Class II match to Class I simply because a similar broader category appears elsewhere in Annex III. For example, security-related microprocessors appear in Class I, while tamper-resistant microprocessors have their own Class II category. The technical characteristics matter.

Step 6: Screen Annex IV Critical Products

After Annex III, the manufacturer should screen Annex IV where the product could have critical-product functionality. Annex IV currently contains hardware devices with security boxes, smart meter gateways and other specified devices for advanced security purposes including secure cryptoprocessing, and smartcards or similar devices including secure elements. Commission Implementing Regulation (EU) 2025/2392 again provides the technical descriptions. A critical-product match should be recorded separately from Class II because Article 8 creates a distinct certification mechanism. The manufacturer then needs to check whether a current Article 8 delegated act and available European cybersecurity certification scheme apply to that category and determine the resulting Article 32(4) route.

• Screen all plausible Annex IV categories.
• Use the Annex II descriptions in Implementing Regulation 2025/2392.
• Do not combine critical and Class II into one classification.
• Check current Article 8 certification requirements.

Step 7: Test Integrated Components Separately

Integrated components create one of the most common classification traps. A product can contain a browser, operating system, network interface, firewall, microcontroller or secure element without the complete product necessarily taking the classification of that component. The manufacturer should first classify any separately supplied component where appropriate, then assess the host product's own core functionality. The component still matters to cybersecurity risk assessment, dependency management and technical documentation even where it does not control the host-product classification. Keeping these conclusions separate also improves supplier management because the manufacturer can preserve the component's CRA evidence without mischaracterising the larger product. The product record should identify both the component classification and the host-product conclusion where the distinction is relevant.

• Classify separately supplied components where required.
• Assess the host product independently.
• Document why an integrated component does or does not control the host classification.
• Preserve component evidence for the product risk assessment.

Step 8: Map the Classification to Article 32

Classification is useful because it determines the conformity-assessment decision. Products outside the important and critical categories generally have access to the default internal-control framework. Class I products can retain internal control only under the conditions established by Article 32(2); otherwise they move to a stricter route. Class II products use the procedures in Article 32(3): module B followed by module C, module H, or an applicable European cybersecurity certification scheme at assurance level at least substantial. Critical products follow Article 32(4), which connects them to Article 8 certification or, where the Article 8 conditions are not met, to the Class II procedures. The classification record should state this consequence directly so that engineering evidence and assessment planning follow the correct path.

• Default category: identify the ordinary conformity route.
• Class I: test the Article 32(2) conditions.
• Class II: use an Article 32(3) procedure.
• Critical: apply Article 32(4) and Article 8.

Step 9: Document the Decision and Set Review Triggers

A classification decision should be reproducible by someone who was not present when it was made. Record the product name and version, product boundary, intended purpose, principal functions, candidate categories, relevant technical descriptions, conclusion and conformity route. Include the reasoning for rejected categories when they were genuinely plausible. The record should also identify changes that require re-review. These can include significant new functions, architecture changes, product-family variants, a shift in intended purpose, changes to separately marketed components, amendments to Annex III or Annex IV, revisions to Commission Implementing Regulation (EU) 2025/2392, new Article 8 delegated acts or changes in available certification schemes. This turns classification into maintained compliance data rather than a one-time launch exercise.

• Record product and version.
• Record product boundary and core functionality.
• Record candidate and selected categories.
• Reference the technical descriptions used.
• Record the Article 32 route.
• Define legal and product-change review triggers.