Use this CRA FAQ to understand how core functionality determines whether a product is in the default category, an important-product category, or a critical-product category.
Built for compliance, product, certification, legal, and engineering teams deciding CRA classification and conformity routes.
Structured answer sets in this page tree.
Cited legal and guidance references.
Core functionality is the classification hinge for CRA conformity assessment. This FAQ focuses on how manufacturers should determine what a product mainly is, how to distinguish core functionality from ancillary functions, and how to avoid category mistakes that change the applicable route under Article 32.
The CRA does not define the term expressly in the regulation itself, but the draft Commission guidance explains it as the product's main features and technical capabilities, without which it would not be able to meet its intended purpose.
points 123 and 124
Research Copilot can turn EU Cyber Resilience Act FAQ Core Functionality into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ.
Start from EU Cyber Resilience Act FAQ Core Functionality and move to source-backed decisions and evidence workflows.
Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ.
It determines whether the product is in the default category, is an important product of class I or class II, or is a critical product, and therefore which conformity assessment regime applies.
Article 7(1), Article 8(1) and Article 32
section 3.1
points 122 and 123
The draft Commission guidance says the manufacturer should assess the product's main features and technical capabilities in light of its intended purpose, specific context and conditions of use.
The guidance also says that this assessment can be supported by the instructions for use, promotional or sales materials, manufacturer statements and the technical documentation. That aligns with the CRA definitions of intended purpose and reasonably foreseeable use.
point 124
Article 3(23), Article 3(24) and Annex VII
It is about the product as a whole.
The CRA and the Commission FAQ make clear that the integration of a product or component with important or critical functionality does not by itself determine the classification of the finished product. The key question is the core functionality of the finished product itself.
Article 7(1)
sections 3.1 and 3.2
points 123 and 136
Yes.
The draft Commission guidance says a product may not have more than one core functionality for the purpose of determining the applicable conformity assessment regime, even if it has many additional or ancillary features.
points 125 and 128
No.
The Commission FAQ and the draft guidance both explain that the presence of additional functions does not by itself mean that the product loses the core functionality of a listed category or moves into another category.
section 3.4
points 125 and 131
No.
The draft Commission guidance says a product may be capable of performing functions associated with an important or critical category and still have a different core functionality. The assessment should focus on what the product mainly is, not on whether one feature overlaps with a listed category.
section 3.4
points 126 and 127
No.
The Commission FAQ gives concrete examples: integrating an embedded browser into a news app does not make the app a browser for CRA classification, and integrating a secure element into a laptop does not make the laptop a secure element product. The same logic applies more broadly to other integrated listed components.
Article 7(1)
sections 3.2 and 3.4
points 126 and 136
Yes.
The Commission FAQ and the draft guidance use SOAR software as an example. Even though a SOAR tool may perform SIEM-like functions, it is generally not treated as having the core functionality of a SIEM if its own core functionality is different.
section 3.4
point 127 and Example 50
Yes.
The draft Commission guidance gives the example of security-related tools that collect and visualise logs but do not perform the full analytical and actionable functions associated with SIEM systems. Partial overlap is not enough by itself.
point 127 and Example 51
No.
The draft Commission guidance says the assessment should focus on the product's actual features and technical capabilities, as reflected in its intended purpose, rather than on vague product groupings, shared market context or partially overlapping functions.
Yes.
The draft Commission guidance says the product's core functionality should be clearly identified so that the applicable conformity assessment regime can be determined and checked. That fits with the CRA's broader documentation framework, including the need to describe the product's intended purpose and the conformity assessment procedure followed.
point 128
Annex VII and Annex V
No.
The draft Commission guidance says a manufacturer may not misrepresent its product's core functionality in order to avoid the applicable conformity assessment regime. Clear inconsistencies between promotional materials, instructions for use and technical documentation can indicate that kind of misrepresentation.
It determines the route, but the whole product still has to comply.
The draft Commission guidance explains that core functionality is the classification tool. It does not limit the product's broader compliance obligations. The conformity assessment and the manufacturer's risk assessment still have to address the product as a whole.
Article 13(2) to Article 13(4) and Article 32
points 131 and 134 to 136
No.
The draft Commission guidance explains that a harmonised standard may support the use of internal control for an important class I product where it covers the core functionality, but the presumption of conformity extends only to the parts whose risks are actually covered by that standard. Additional functions and additional risks may still need to be addressed through other means.
Article 27(1), Article 27(5) and Article 32(2)
points 133 to 139
The Commission FAQ says the technical descriptions of the important and critical product categories are laid down in Commission Implementing Regulation (EU) 2025/2392, and the draft Commission guidance also relies on those descriptions.
So in practice, manufacturers should not classify products only by label or market intuition. They should compare the product's real features and technical capabilities against the category descriptions referred to in the CRA materials.
sections 3.1 and 3.4
footnote 15 and Examples 48 to 53
Then it falls into the default category.
The CRA does not use the term "default category" in the legal text itself, but the draft Commission guidance uses it for products whose core functionality does not match a category in Annex III or Annex IV. Those products follow the general conformity-assessment regime in Article 32(1), rather than the special routes for important or critical products.
Article 7(1), Article 8(1) and Article 32(1)
sections 3.1 and 6.1
point 122 and footnote 16
No.
The relevant question is whether the product's actual features and technical capabilities match the technical description of a listed category. Marketing and sales materials do matter as evidence of intended purpose and context of use, but they do not replace the underlying feature and capability analysis. If those materials conflict with the instructions for use or the technical documentation, the draft guidance treats that as a warning sign that the manufacturer may be misrepresenting the product's core functionality.
sections 3.1 and 3.4
Article 3(23) and Annex VII
points 124, 127 and 129
No.
Classification turns on core functionality, not on deployment environment alone. A product's operating context can still matter greatly for the cybersecurity risk assessment and for the measures the manufacturer must implement, but it does not by itself change a product into an important or critical category if the product's own core functionality does not match one of the listed categories.
sections 3.1 and 3.3
point 127
Yes.
The Commission FAQ gives this directly with two different VPN products. Both may have the same core functionality and therefore the same CRA category, but the manufacturer still has to perform a product-specific cybersecurity risk assessment. A VPN intended for critical infrastructure may require more demanding measures than a VPN intended only for residential use, even though both remain VPN products for classification purposes.
Article 13(2) and Article 13(3)
section 3.3
The draft Commission guidance gives a positive example for operating systems.
A software product that provides an abstraction layer over hardware, manages the execution of software components, handles process and memory management, input-output control, scheduling, resource allocation, and exposes system services and APIs so that applications can reliably run on the platform is treated in the guidance as having the core functionality of an operating system.
point 124 and Example 48