What Is an Important Product With Digital Elements?

Article 7 Defines Important Products Through Annex III

Article 7 of the Cyber Resilience Act provides the legal starting point. A product with digital elements is considered important when it has the core functionality of a product category set out in Annex III. Annex III is therefore not a list of optional examples or a general risk taxonomy. It is part of the classification mechanism that determines whether the special important-product conformity procedures apply. The manufacturer should first establish that the product is within CRA scope, then identify its product boundary and principal functions. Only after that should it compare the product with Annex III. A product that is not in an Annex III category can still be fully subject to the CRA, but it follows the default conformity framework rather than the special important-product route, subject to other applicable rules.

• CRA scope and important-product classification are separate questions.
• Annex III is the legal list of important-product categories.
• The relevant test is the product's core functionality.
• A product can be CRA-covered without being an important product.

Core Functionality Is More Important Than the Product Name

Commercial terminology is not enough to decide whether a product is important. A product may be marketed as a security platform, network appliance, gateway, enterprise tool or embedded module without that label resolving the CRA classification. Article 7 focuses on core functionality. The practical task is to identify what functions define the product as supplied and why customers obtain or deploy it, then compare those functions with the applicable Annex III category and its technical description. This is especially important for multifunction products. A large platform can contain password management, VPN, firewall or identity features without each feature automatically converting the whole platform into the corresponding important-product category. The classification record should therefore describe functions and architecture rather than repeat sales language.

• Use actual functionality, not only marketing terminology.
• Document which functions are principal and which are ancillary.
• Review multifunction products at the product-boundary level.
• Compare the result with the legal technical description.

Integrating a Listed Product Does Not Automatically Reclassify the Larger Product

Article 7 contains an important anti-overclassification rule. The integration of a product with digital elements that has the core functionality of an Annex III category does not by itself make the larger product in which it is integrated subject to the important-product conformity procedures. For example, a larger product may include a browser, network interface, authentication component or another listed technology as one element of its architecture. The manufacturer still needs to assess the larger product's own core functionality. The integrated component may have its own CRA status and can remain relevant to the larger product's risk assessment, component management and evidence, but the mere presence of that component is not the legal classification test for the complete product.

• Classify the supplied product, not every feature in isolation.
• Keep component classification separate from host-product classification.
• Use architecture evidence to explain integration.
• Do not treat the presence of one Annex III component as automatic reclassification.

Important Products Are Split Into Class I and Class II

Once a product is found to match Annex III, the next question is which class contains that category. Class I contains a broad range of cybersecurity and connected-product categories. Class II contains a narrower set of categories including hypervisors and qualifying container runtime systems, firewalls and intrusion detection or prevention systems, tamper-resistant microprocessors and tamper-resistant microcontrollers. The difference matters because Article 32 gives Class I a conditional path to internal control where specified standards, common specifications or certification conditions are met, while Class II uses stricter conformity procedures. The class is therefore a legal routing mechanism rather than a simple statement that one product is good and another is bad.

The Annex III Categories Have Detailed Technical Descriptions

The CRA required the Commission to specify the technical descriptions of the important and critical product categories. Commission Implementing Regulation (EU) 2025/2392 performs that function. Its Annex I describes the Class I and Class II categories in operational terms and, for some categories, includes examples. Those examples are illustrative rather than exhaustive. This matters because a manufacturer should not conclude that a product is outside a category simply because its exact commercial form is not named in an example. The better approach is to take the Annex III category, read the corresponding 2025/2392 description, map the product's core functions against it and preserve that comparison in the technical or compliance record.

• Use Annex III and 2025/2392 together.
• Treat examples as illustrative, not exhaustive.
• Record the technical description considered.
• Keep evidence showing why the product does or does not match.

Article 7 Explains Why These Products Receive Stricter Treatment

Article 7 identifies characteristics that justify important-product treatment. The categories meet at least one of two broad criteria. One concerns products that primarily perform functions critical to the cybersecurity of other products, networks or services, including authentication and access security, intrusion prevention and detection, endpoint security or network protection. The other concerns functions that can create significant adverse effects through their intensity and ability to disrupt, control or damage many other products or affect user health, security or safety, including central system functions such as network management, configuration control, virtualisation or processing of personal data. These criteria explain the structure of Annex III, but manufacturers still classify against the listed categories and technical descriptions rather than inventing new categories from the criteria alone.

• Cybersecurity-critical functions are one basis for the Annex III list.
• High-impact central system functions are another basis.
• The criteria help explain the list.
• The current legal classification still depends on Annex III.

Important Classification Changes the Conformity Assessment Plan

The practical consequence of important-product status appears in Article 32. Class I products can use internal control only when the relevant conditions concerning harmonised standards, common specifications or applicable European cybersecurity certification are satisfied. Otherwise, stricter assessment is required. Class II products use EU-type examination followed by conformity to type, full quality assurance, or an applicable European cybersecurity certification scheme at the required assurance level. This makes classification an early product-development issue rather than a legal label added shortly before launch. Product teams need enough time to identify the route, prepare evidence, engage a notified body where required and resolve gaps before placing the product on the market under the applicable CRA framework.

• Map the classification to Article 32 immediately.
• Check the availability and coverage of relevant standards.
• Check whether a notified body is needed.
• Build assessment lead time into the release plan.

A Repeatable Classification Worksheet Reduces Portfolio Errors

For a portfolio, the most useful output is a repeatable classification worksheet rather than a single list of product names. Each record can capture the product version, product boundary, intended purpose, core functions, candidate Annex III categories, corresponding 2025/2392 descriptions, class, rationale and conformity route. It should also identify integrated components that could be confused with the core functionality of the larger product. The worksheet can then be connected to change control so that a major architecture or functionality change triggers review. Article 7 also allows the Annex III list to be amended through delegated acts, so legal-change monitoring belongs in the review process. Structured records make it easier to update a conclusion without repeating the entire scoping exercise from the beginning.

• Keep product and version identifiers.
• Record the core-functionality reasoning.
• Record the Annex III category and class.
• Record the 2025/2392 technical description used.
• Record the Article 32 route.
• Review after material functionality or legal changes.