CRA product classification determines which conformity-assessment route a manufacturer may use for a product with digital elements. The key question is not whether the product contains a browser, firewall, operating system or other security-relevant component. The manufacturer must identify the core functionality of the product as a whole and compare it with the official technical descriptions for important Class I, important Class II and critical products.
For most in-scope products, none of those listed categories applies. These products are commonly described by the European Commission as the default category and can generally use the CRA's ordinary conformity-assessment route. If the product's core functionality matches a category in Annex III or Annex IV, stricter assessment rules apply.
The classification model in one view
The CRA creates four practical classification outcomes:
| Classification | Legal basis | What identifies it | | --- | --- | --- | | Default category | General CRA rules | The product is in CRA scope but its core functionality does not match an Annex III or Annex IV category | | Important Class I | Article 7 and Annex III Class I | Core functionality matches one of the Class I categories | | Important Class II | Article 7 and Annex III Class II | Core functionality matches one of the Class II categories | | Critical | Article 8 and Annex IV | Core functionality matches one of the critical product categories |
"Default category" is useful operational shorthand, not a separate annex in the Regulation. The Commission uses the term to describe ordinary in-scope products for which the stricter important- or critical-product procedures do not apply.
Classification does not remove the underlying CRA obligations. Manufacturers of default, important and critical products still need to perform the cybersecurity risk assessment, meet the applicable essential cybersecurity requirements, maintain technical documentation and operate the required vulnerability-handling processes. Classification mainly changes the route by which conformity with those requirements must be demonstrated.
Start with the product as a whole
Article 7 states that a product is important when it has the core functionality of a category listed in Annex III. Article 8 applies the same core-functionality concept to categories in Annex IV.
Commission Implementing Regulation (EU) 2025/2392 makes this distinction operational. It explains that integrating a component that itself performs the function of an important or critical category does not automatically reclassify the larger product.
The implementing regulation gives two useful examples:
- a news application that embeds a browser does not become an important product merely because the embedded component performs browser functions; and
- a smartphone does not normally become an operating system or password manager merely because it includes those functions as components.
The reverse point also matters. A product can perform additional or ancillary functions and still belong to a listed category if the listed function remains its core functionality. An operating system does not stop being an operating system because it also includes utilities, and a router does not stop being a router because it includes firewall functionality.
A classification review should therefore begin with a product-level statement such as:
What is the primary function customers obtain this product to perform, and which technical capabilities are essential to that function?
The answer should be based on actual product architecture, intended purpose, marketed functionality and reasonably foreseeable use rather than on the name chosen by the vendor.
Default category: the normal outcome for many products
A product with digital elements can be fully in scope of the CRA without being important or critical. If its core functionality does not match the technical description of a category in Annex III or IV, it remains in the ordinary or default classification.
The Commission gives examples such as mobile applications, smart speakers, computer games and memory chips as products that may fall into the default category, depending on their actual functionality and scope.
That does not mean the product is "low security" or exempt from engineering work. The manufacturer still has to apply the CRA's risk-based cybersecurity requirements. The practical classification consequence is that the ordinary conformity-assessment procedure remains available rather than the stricter route attached to important or critical categories.
Evidence for a default classification should therefore include the negative comparison: which potentially relevant Annex III or IV descriptions were reviewed, and why the product's core functionality does not meet them.
Important Class I products
Annex III Class I contains a broad set of products whose functions are particularly relevant to cybersecurity, infrastructure or connected-product security. The 2025 implementing regulation supplies the binding technical descriptions used to decide whether a product matches one of those categories.
Class I currently includes:
- identity-management and privileged-access-management systems, including authentication and access-control readers;
- standalone and embedded browsers;
- password managers;
- antivirus and other software whose core function is finding, removing or quarantining malicious software;
- virtual private network products;
- network-management systems;
- security information and event management systems;
- boot managers;
- public-key-infrastructure and digital-certificate issuance software;
- physical and virtual network interfaces;
- operating systems;
- routers, internet-connection modems and switches;
- microprocessors with security-related functionality;
- microcontrollers with security-related functionality;
- ASICs and FPGAs with security-related functionality;
- general-purpose smart-home virtual assistants;
- smart-home products with security functionality, including smart locks, security cameras, baby monitors and alarm systems;
- certain internet-connected toys with social-interaction or location-tracking functionality; and
- certain health-monitoring wearables outside the medical-device regimes, plus personal wearables intended for children.
The category name alone is not enough. For example, the implementing regulation describes an operating system through its function of abstracting underlying hardware and controlling software execution. A manufacturer should compare the actual product with the technical description, not simply search for matching words in marketing material.
Important Class II products
Class II is much shorter and is reserved for categories for which the CRA requires a stricter conformity-assessment route than Class I.
The four Class II categories are:
- hypervisors and container runtime systems that support virtualised execution of operating systems or similar environments;
- firewalls and intrusion-detection or intrusion-prevention systems;
- tamper-resistant microprocessors; and
- tamper-resistant microcontrollers.
The implementing regulation adds important technical detail to the hardware categories. Tamper-resistant microprocessors and microcontrollers are not simply chips with a generic security feature. They build on the corresponding Class I security-related processor categories and are designed for a specified level of resistance to exploitation under the Common Criteria and Common Evaluation Methodology framework.
For software, the same core-functionality test applies. A platform that happens to include a firewall or container component is not automatically a Class II product. The manufacturer needs to determine whether firewalling, intrusion prevention, hypervisor operation or container runtime operation is the core functionality of the product being placed on the market.
Critical products
Annex IV currently contains three critical categories:
- hardware devices with security boxes;
- smart-meter gateways and certain other 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 boundary. For example, hardware devices with security boxes are described as multi-component hardware products that securely store, process or manage sensitive data or cryptographic operations and use a physical envelope providing tamper evidence, resistance or response. The regulation lists products such as qualifying hardware security modules and payment terminals as examples rather than an exhaustive catalogue.
For secure elements and similar devices, the implementing regulation uses Common Criteria resistance levels to distinguish the critical category from the lower classes of security-related processors.
Article 8 also allows the Commission, subject to the conditions in the CRA, to require products in Annex IV categories to obtain a European cybersecurity certificate under an applicable European certification scheme. Where that condition is not met, Annex IV products use the third-party conformity-assessment routes referenced by Article 32.
Classification is about core functionality, not component inheritance
One of the most important rules for product teams is that classification is not automatically inherited upward from every component.
Consider three simplified examples:
Product A: industrial control application with an embedded browser
The application uses an embedded browser to display its user interface. If the product's core function is industrial process control rather than browsing web content, the browser component does not by itself make the complete product an important Class I browser.
The browser still matters to the product's cybersecurity risk assessment, SBOM, vulnerability handling and security testing. Classification and component security are separate questions.
Product B: dedicated managed network switch
If the product's core function is providing managed packet forwarding and network connectivity in the manner described by the implementing regulation, it can match the Class I category for routers, internet-connection modems and switches. Additional monitoring or security features do not necessarily change that result.
Product C: security appliance whose principal function is firewalling
If the product's core functionality is monitoring and restricting network traffic to protect connected networks or systems, the Class II firewall description is directly relevant. Calling the device an "edge gateway" rather than a firewall does not avoid the functional test.
A practical classification workflow
A repeatable CRA classification review can be organised into seven steps.
1. Confirm CRA scope first
Classification comes after the scope decision. Record why the item is a product with digital elements within the CRA and identify the legal manufacturer responsible for it.
Do not use the Annex III or IV lists as a substitute for the general scope analysis. A product can be in scope without appearing in either annex.
2. Define the exact product boundary
Identify the product, variant, release family and remote data-processing functions that form the product being placed on the market. Distinguish the complete product from separately marketed components.
An unclear boundary makes the core-functionality decision unstable.
3. Describe core functionality in neutral technical language
Write a short product-function statement without copying the commercial product category from the website or datasheet. Describe what the product principally enables the user or connected system to do.
Useful evidence includes architecture documentation, product requirements, interface descriptions, intended-purpose statements and user documentation.
4. Screen Annex III Class I and Class II
Compare that core-function statement with the categories and technical descriptions in Annex I of Implementing Regulation (EU) 2025/2392.
Do not stop at the category title. Review the technical description and examples, and record both positive and negative matches that required judgement.
5. Screen Annex IV
Repeat the comparison against the critical-product descriptions in Annex II of the implementing regulation. For hardware security products, pay particular attention to the technical resistance and physical-security characteristics used to distinguish the categories.
6. Record the classification and rationale
The decision record should state:
- the exact product and version family assessed;
- intended purpose and core-functionality statement;
- potentially relevant Annex III or IV categories;
- technical descriptions reviewed;
- why each candidate category matches or does not match;
- supporting product and architecture evidence;
- resulting classification; and
- reviewer, approval and date.
If classification affects the planned conformity-assessment route, link the classification record to that downstream decision without turning the classification analysis itself into a conformity-assessment document.
7. Define change triggers
Classification should be revisited when the product's core functionality or product boundary changes materially. Examples include adding a new principal use case, splitting a component into a separately marketed product, combining products into a new offering, or changing hardware so that a security function becomes the defining function of the product.
A routine patch that does not change core functionality should not require the team to rediscover the classification from zero, but the retained record should make that conclusion easy to verify.
Evidence to retain for classification
A concise classification record is more useful than an unexplained label in a spreadsheet. At minimum, retain:
| Record | Why it matters | | --- | --- | | Product identity and boundary | Shows exactly what was classified | | Intended purpose | Anchors the functional analysis | | Core-functionality statement | Explains the primary technical function | | Annex III/IV candidates | Shows which categories were considered | | Implementing-regulation references | Connects the decision to the binding technical descriptions | | Architecture or requirements evidence | Substantiates what the product actually does | | Positive or negative rationale | Explains why a category applies or does not apply | | Classification result | Default, important Class I, important Class II or critical | | Decision owner and date | Makes the judgement attributable | | Review trigger | Defines when the classification must be reconsidered |
Common classification mistakes
Several shortcuts can produce unreliable results:
- Classifying by product name. A product called a "security gateway" is not automatically a firewall; the technical function controls.
- Promoting the whole product because of one component. An embedded browser, password manager or operating system does not automatically transfer its category to the parent product.
- Ignoring separately marketed components. A component placed on the market separately may require its own classification even if an integrated instance does not reclassify the parent product.
- Treating default as exempt. Default products remain subject to the CRA's essential cybersecurity and lifecycle obligations.
- Using Annex III without the implementing regulation. The legal category list and the binding technical descriptions need to be read together.
- Mixing classification with risk scoring. A high internal risk score does not by itself move a product into Class I, Class II or Annex IV. Classification follows the statutory categories and core-functionality test.
- Never revisiting the decision. Product evolution can change the function being placed on the market, so the original reasoning needs explicit review triggers.
Keep classification separate from conformity assessment
Classification answers what category the product belongs to. Conformity assessment answers which procedure the manufacturer uses to demonstrate conformity with the CRA's essential cybersecurity requirements.
The two decisions are connected, but they should remain separate records. For example, Class I status can make third-party assessment necessary unless the conditions for the CRA's alternative route are met, while Class II and critical products use stricter procedures. Those procedure details deserve their own assessment after the classification has been established.
Keeping the classification rationale connected to the product boundary, requirements, evidence and later conformity decisions prevents the reasoning from being lost as a product evolves. AA-sec is designed around traceability between requirements, security evidence, assessments, decisions and exact product or lifecycle context. It does not determine the product's legal CRA classification or make the manufacturer's conformity decision.
Key takeaway
CRA product classification is a functional legal test, not a naming exercise. First establish the exact product boundary and its core functionality. Then compare that function with the technical descriptions in Commission Implementing Regulation (EU) 2025/2392 for Annex III Class I, Annex III Class II and Annex IV critical categories.
If no listed category matches the product's core functionality, the product normally remains in the default category while still carrying the CRA's general cybersecurity obligations. If a category does match, retain the evidence and rationale behind that conclusion because the classification determines which conformity-assessment options are available downstream.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Commission Implementing Regulation (EU) 2025/2392 — Technical description of important and critical products with digital elements — EUR-Lex
- The Cyber Resilience Act - Summary of the legislative text — European Commission
- Cyber Resilience Act - Conformity assessment — European Commission