← Commission worked examplesClassification

How does core functionality decide a product's CRA classification?

9 worked examples from Commission guidance C(2026) 5252 final, reproduced word for word.

Also asked

Is my product an important product under Annex III of the CRA?
Does adding a firewall to a router change its CRA classification?
Is SOAR software classified as a SIEM under the CRA?
Can I still self-assess an important product with extra features?
What does presumption of conformity actually cover?

Classification follows core functionality, judged against the technical descriptions in Implementing Regulation (EU) 2025/2392. A product that merely integrates an operating system does not take on the core functionality of one. SOAR software generally exceeds the SIEM category and log viewers fall short of it. Modules offered on separate subscriptions are separate products, each classified on its own. Extra functions do not push a product into a stricter conformity route, and the presumption of conformity covers only what the harmonised standard covers.

The harmonised standards under the CRA are not yet cited in the Official Journal, so the presumption of conformity described in Examples 64 and 65 is not yet available in practice.

At a glance

Classification basis: Core functionality, per Annexes III and IV and Implementing Regulation (EU) 2025/2392
Integrating an OS: Does not give the host product the core functionality of an OS (Example 58)
SOAR: Generally not a SIEM. It exceeds the category (Example 59)
Bundled modules: Separate subscriptions mean separate products, classified individually (Example 61)
Extra functions: Do not remove access to internal control (Examples 62 and 63)

Last reviewed 27 July 2026

Verified against The Annex to Commission Communication C(2026) 5252 final of 27 July 2026, Implementing Regulation (EU) 2025/2392, and Regulation (EU) 2024/2847 as published in OJ L, 20.11.2024, read at EUR-Lex on 27 July 2026

Examples 64 and 65 describe a presumption of conformity that is not yet available, because no harmonised standard under the CRA has been cited in the Official Journal. Review this record when the first citation is published.

Core functionality is what the product is for, not what it contains

Example 57 walks through the positive case. A product providing an abstraction layer over hardware, managing process and memory, handling input-output, scheduling, resource allocation and exposing system APIs has the core functionality of an operating system as described in Annex I, point 11, to Implementing Regulation (EU) 2025/2392.^[2]

Example 58 is the one that saves manufacturers from over-classifying. A smartphone integrates an operating system, and the smartphone as a whole still has a different core functionality. Mere integration does not transfer the category.

Examples 59 and 60 show the category boundary cutting in both directions for SIEM. SOAR software is generally not a SIEM, because its core functionality substantially exceeds the category and includes incident response. Log collection and visualisation tools are generally not SIEM either, because they do not correlate data or provide actionable security insights. Falling short and overshooting both put a product outside.

CRA referenceArticle 7, Annex III, Annex IV

Bundled suites are classified module by module where the modules are sold separately

Example 61 handles the unified security suite. Where a manufacturer offers a SIEM, an intrusion detection system and an analytics module on separate subscriptions, each is a distinct product classified on its own core functionality.

The outcome in that example spans all three regimes at once. The SIEM module is important class I. The intrusion detection system is important class II, under the firewalls, intrusion detection and prevention systems category. The analytics module is a default product. One suite, three conformity assessment routes.^[1]

CRA referenceArticle 7, Annex III

Extra functions do not change the route, and the presumption follows the standard

Examples 62 and 63 confirm that a product is assessed as a whole against its core functionality. Antivirus software with disk-cleaning and anti-tracking functions, and a router that integrates a firewall component, may both use the internal control procedure covering the product in its entirety. The manufacturer assesses the whole product and may apply an additional harmonised standard, such as the firewall standard, to cover the extra functions.

Examples 64 and 65 separate the conformity route from the presumption of conformity, which is where the practical exposure sits. Applying the harmonised standard for the core functionality earns a presumption for the risks associated with that core functionality only. Risks from the additional functions carry no presumption until the standard is updated to cover them, and Example 65 shows the presumption widening one function at a time as that happens.^[4]

CRA referenceArticles 27, 28 and 32, Annex VIII

The Commission’s examples, word for word

9 examples, reproduced exactly as published. Each carries the section, guidance point and page it comes from. The bold line above each quotation is our summary of the outcome and is not part of the source.

Example 57

Section 6.1 Core functionality, point 139, page 49

Core functionality of an operating system, per Annex I point 11 to Implementing Regulation (EU) 2025/2392

A software product with digital elements provides an abstraction layer over the underlying hardware and manages the execution of software components. Its main features include hardware and peripheral initialisation, process and memory management, input – output control, scheduling, resource allocation, and the exposure of system services and application programming interfaces (APIs) through which applications interact with the device's hardware and software resources. The technical documentation indicates that the product with digital elements orchestrates computing resources, enforces system configurations, and provides standardised interfaces for software modules and connected peripherals. The manufacturer highlights these capabilities as enabling the platform to serve as the central software environment on which applications can reliably run. The product with digital elements has the core functionality of an operating system, as described in Annex I, point 11, to Implementing Regulation (EU) 2025/2392.

Example 58

Section 6.1 Core functionality, point 141, page 50

Integrating an operating system does not give the host product the core functionality of one

A smartphone integrates an operating system that provides the functionalities described in Annex I, point 11, to Implementing Regulation (EU) 2025/2392. While the operating system enables the management of hardware resources and execution of software applications, the smartphone as a whole has a different core functionality (e.g. that of enabling users to communicate and access information and services). The mere integration of an operating system does not mean that the smartphone has the core functionality of an operating system.

Example 59

Section 6.1 Core functionality, point 142, page 50

SOAR is generally not a SIEM. Its core functionality substantially exceeds the category

A security orchestration, automation and response (SOAR) software often has the ability to perform the functions of products with digital elements in the category of 'security information and event management (SIEM) systems', i.e. collect data from multiple sources, analyse and correlate that data and present it as actionable information for security-related purposes. However, the software's core functionality substantially exceeds that of a SIEM, including services such as incident response as core elements of its technical capabilities. Therefore, SOAR software is generally not considered to have the core functionality of SIEM systems.

Example 60

Section 6.1 Core functionality, point 142, page 50

Log collection and dashboards are generally not a SIEM. No correlation, no actionable security insight

Certain log collection and visualisation tools have the ability to ingest log data and present basic dashboards showing system events. While these tools can support security monitoring activities, their core functionality falls short of that of SIEM systems, as they do not perform data correlation, nor do they provide actionable security insights. Therefore, such tools are generally not to be considered to have the core functionality of SIEM systems.

Example 61

Section 6.1 Core functionality, point 145, page 52

Separately subscribable modules are separate products, each classified on its own core functionality

a manufacturer places on the market a unified security suite combining multiple modules, including a SIEM, an intrusion detection system, and an analytics module. The manufacturer also offers those modules for separate subscriptions. In this scenario, each module is a distinct product with digital elements and is classified on the basis of its own core functionality. The SIEM module is subject to the conformity assessment regime for important products with digital elements of class I, as its core functionality is that of 'Security information and event management (SIEM) systems'. The intrusion detection system is subject to the conformity assessment regime for important products with digital elements of class II, as its core functionality is that of 'Firewalls, intrusion detection and prevention systems'. The analytics module is subject to the conformity assessment regime for 'default' products with digital elements, as its core functionality is not that of an important or critical product category.

Example 62

Section 6.2 Conformity assessment for important and critical products with digital elements, point 151, page 54

Internal control remains available for the whole product, including functions outside the core category

An antivirus software has the core functionality of software that searches for, removes, or quarantines malicious software, as described in Annex I, point 4, to Implementing Regulation (EU) 2025/2392. That product with digital elements also includes additional features, namely a disk-cleaning function and an anti-tracking function protecting the user when navigating on the web. The manufacturer carries out a risk assessment covering the product with digital elements in its entirety, including the antivirus's core functionality, the disk-cleaning and the anti-tracking functions. It applies a harmonised standard covering the risks associated with the antivirus's core functionality, and additional measures to deal with risks stemming from additional functions. The manufacturer is allowed to make use of the internal control procedure for its conformity assessment, covering the product with digital elements as a whole, including the disk-cleaning and the anti-tracking functions.

Example 63

Section 6.2 Conformity assessment for important and critical products with digital elements, point 152, page 55

A router with a firewall component is still classified as a router

A hardware product with digital elements has the core functionality of a router, as described in Annex I, point 12, to Implementing Regulation (EU) 2025/2392. That product with digital elements also includes additional functionalities, including firewalling capabilities, as it integrates a firewall component. The manufacturer carries out a risk assessment covering the product with digital elements in its entirety, including the router's core functionality and the firewall functionality. It applies a harmonised standard covering the risks associated with the router's core functionality, and additional measures to deal with risks stemming from additional functions. For instance, the manufacturer may apply the harmonised standard for firewalls to cover the risks associated with the firewall functionality. The manufacturer is allowed to make use of the internal control procedure for its conformity assessment, covering the product with digital elements as a whole, including the firewall functionality.

Example 64

Section 6.3 Implications for presumption of conformity, point 155, page 56

Presumption of conformity attaches to the core functionality only, not to the extra functions

An antivirus software has the core functionality of software that searches for, removes, or quarantines malicious software, and risks associated with that core functionality are covered by the harmonised standard. That product with digital elements also includes additional functionalities, namely a disk-cleaning function and an anti-tracking functionality protecting the user when navigating on the web, whose risks are not covered by the harmonised standard. If the harmonised standard is applied, the manufacturer is allowed to make use of the internal control procedure for its conformity assessment. It will benefit from presumption of conformity for the risks associated with that product's core functionality, but not for the risks associated with additional functionalities.

Example 65

Section 6.3 Implications for presumption of conformity, point 155, page 56

Presumption widens as the harmonised standard widens, function by function

In the same scenario as the previous example, the harmonised standard has now been updated to also cover risks associated with one of the additional functionalities, namely the disk-cleaning function, but not the other (i.e. the anti-tracking function). If the harmonised standard is applied, the manufacturer is allowed to make use of the internal control procedure for its conformity assessment. It will benefit from a presumption of conformity for the risks associated with that product's core functionality and for the disk-cleaning functionality, but not for the risks related to the anti-tracking functionality.

Sources

Every claim above traces to one of these. Items marked Binding are law in force. Everything else is interpretive and is labelled as such.

[1]
Commission guidance on the application of Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act)Commission guidance
European Commission · Sections 6.1 to 6.3, points 139 to 155 · C(2026) 5252 final · Final, adopted 27 July 2026
Article 26 guidance sets out the Commission's interpretation of the CRA. It does not bind economic operators, and only the Court of Justice of the European Union can give an authoritative interpretation of the Regulation.
Accessed 2026-07-27
[2]
Commission Implementing Regulation on the technical description of the important and critical product categories in Annexes III and IV to Regulation (EU) 2024/2847Binding
European Commission · Annex I, points 4, 11 and 12 · Implementing Regulation (EU) 2025/2392
Accessed 2026-07-27
[3]
Regulation (EU) 2024/2847, important products with digital elementsBinding
European Union · Article 7 and Annex III · CELEX:32024R2847
Accessed 2026-07-27
[4]
Regulation (EU) 2024/2847, presumption of conformity and conformity assessment proceduresBinding
European Union · Article 27 and Article 32 · CELEX:32024R2847
Accessed 2026-07-27

The provisions behind these examples

Article 7Important Products with Digital Elements - Annex III Classification Article 27Presumption of Conformity, Harmonised Standards, and Common Specifications Article 32Conformity Assessment Procedures: Module A vs Third-Party Assessment Annex IIIImportant Products with Digital Elements - Class I and Class II Classification

Terms used on this page

Security Information and Event Management (SIEM)SIEM (Security Information and Event Management) is a platform that aggregates, correlates, and analyses security log data from across an organisation's infrastructure to detect threats, support incident investigation, and provide audit evidence. SIEM is a core technology in SOC operations and supports CRA-related monitoring and incident detection.Important Product Class IImportant Product Class I is the lower tier of the CRA's two-tier classification for products with digital elements that present a significant cybersecurity risk. Class I products face an elevated conformity assessment pathway compared to Default Class products, but less stringent than Class II. Examples include identity management software and general-purpose browsers.Important Product Class IIImportant Product Class II is the highest risk tier under the EU Cyber Resilience Act's product classification system, covering products with digital elements whose compromise could have severe or widespread impact. Class II products - including industrial control systems, medical devices, and critical infrastructure components - face mandatory third-party conformity assessment.Harmonised StandardA Harmonised Standard is a European standard developed by a recognised standards body (CEN, CENELEC, or ETSI) under a mandate from the European Commission that confers a presumption of conformity with specific EU legislation. Manufacturers whose products comply with a published Harmonised Standard satisfy the corresponding CRA essential requirements without further proof.

Turn the guidance into an audit-ready file

Free CRA classification for your product, a vulnerability disclosure portal on your own domain, and Article 14 deadline tracking. Receiving and tracking reports is free for every manufacturer placing products with digital elements on the EU market.

Classify my product Start your free portal