EU Cyber Resilience Act FAQ Core Functionality

The CRA uses core functionality to classify products, but the regulation itself does not give a standalone definition. Non-binding Commission guidance adopted in July 2026 describes it as the product's main features and technical capabilities, without which the product could not meet its intended purpose.

The assessment is not just a marketing-label exercise. The guidance points to the product's specific context and conditions of use, including instructions for use, promotional and sales materials, manufacturer statements, and technical documentation.

A product with digital elements is treated as important if it has the core functionality of a category in Annex III. Critical-product treatment is tied to the core functionality of categories in Annex IV, subject to the CRA mechanism for critical products.

That classification changes the conformity-assessment route under Article 32. Products that do not have the core functionality of an Annex III or Annex IV category are described in the adopted Commission guidance as the default category and can use the Article 32(1) internal control route, although a manufacturer may choose a more rigorous procedure.

Use the binding technical descriptions for important and critical product categories in Commission Implementing Regulation (EU) 2025/2392, not only Annex labels, Commission-guidance examples, or market intuition.

Compare the product's real features and technical capabilities with the relevant technical description, then record why the product matches, exceeds, falls short of, or sits outside that category.

Assess the product as a whole. Integrating a component that itself performs an important or critical function does not automatically give the finished product that component's classification.

The Commission FAQ gives concrete examples: an embedded browser in a news app does not make the news app a browser, and a secure element in a laptop does not make the laptop a secure-element product. The adopted Commission guidance applies the same logic to a smartphone integrating an operating system.

Start with whether there is a product with digital elements: a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately.

The boundary can include software supplied with hardware even when it is downloaded later, if the hardware and software are designed to operate together so the product can perform its intended functions. The core-functionality analysis should then be run on that product boundary, not on an isolated delivery channel.

Yes. The adopted Commission guidance says a product may not have more than one core functionality for deciding the applicable conformity-assessment regime.

Additional functions, such as a calculator or graphics editor in an operating system, can be ancillary. Their presence does not by itself prevent the product from having the listed core functionality. Where modules are also offered separately for purchase, licensing or subscription, the final guidance treats those modules as distinct products that must each be classified by their own core functionality. A unified security suite and its separately sold security information and event management (SIEM) or intrusion-detection modules therefore need separate classification records.

Ancillary functions may not change the category, but they still matter for the whole-product risk assessment and conformity evidence. The manufacturer must assess the product as a whole and address risks from additional functions or integrated components.

For example, if an antivirus product has antivirus core functionality but adds disk-cleaning or anti-tracking features, the core functionality can still drive the route, while the added functions must still be covered by risk treatment and documentation.

Yes. Partial overlap is not enough. The adopted Commission guidance says similar domain, purpose, or deployment context does not prove shared core functionality.

A security orchestration, automation and response (SOAR) tool may perform SIEM-like tasks but generally has a core functionality that exceeds SIEM. A log collection and visualisation tool may fall short of SIEM if it does not correlate data or provide actionable security insights.

No. Deployment environment alone does not supersede the core-functionality test. A product used in a sensitive or critical setting still needs to match the core functionality of an important or critical category before that category applies.

The environment can still materially affect the risk assessment and security measures. The Commission FAQ uses two VPN products as an example: the classification may be the same, while a VPN intended for critical infrastructure may require stronger risk mitigations than one intended for residential use.

Remote data processing can be part of the product with digital elements, but it is not limited to the product's core functionality. The adopted Commission guidance says the remote-processing test covers functions that directly fulfil the product's intended purpose and functions that support the product's overall performance.

A remote function can therefore be in scope even when it is not the core functionality used for Annex III or Annex IV classification. Examples in the guidance include sending commands to a device, synchronising files, onboarding, configuration, updates, and identity and access management.

No. A cloud or web service is within the CRA product boundary as a remote data processing solution only when the relevant remote processing is at a distance, its absence would prevent the product from performing one of its functions, and the software was designed and developed by or under the responsibility of the manufacturer.

A website that merely provides product information is not a remote data processing solution. By contrast, a manufacturer-controlled authentication portal, command service, sync service, or update function may be in scope if it is necessary for a product function.

Marketing language is evidence, not the rule. Instructions, promotional and sales materials, manufacturer statements, and technical documentation can all help show intended purpose and context of use, but the actual features and technical capabilities must still match the technical description of the category.

The adopted Commission guidance also warns that a manufacturer may not misrepresent core functionality to avoid the applicable route. Clear inconsistency between marketing materials, instructions, and technical documentation is a warning sign.

Document the product boundary, intended purpose, reasonably foreseeable use, selected core functionality, category match or non-match, conformity-assessment route, and the evidence used to reach that view.

The adopted Commission guidance says core functionality should be clearly identified so the conformity-assessment regime can be determined and checked. Annex VII also requires technical documentation to include intended purpose, relevant software versions affecting compliance, architecture information, cybersecurity risk assessment, standards applied, and test reports.

Not automatically. A harmonised standard may support use of internal control for an important class I product where all its applicable requirements are applied and its scope covers at least all cybersecurity risks associated with the product's core functionality, but presumption of conformity extends only to the requirements and risks covered by the standard.

If the product has additional functions or risks outside the standard, the manufacturer still needs to assess those risks and document other measures used to meet the essential cybersecurity requirements.

Yes, if the change alters the product's intended purpose or affects compliance with the essential cybersecurity requirements. The CRA definition of substantial modification covers changes after placing on the market that affect Annex I Part I compliance or change the intended purpose for which the product was assessed.

The adopted Commission guidance treats new functionality as a case-by-case assessment. A later feature already covered in the original risk assessment may avoid substantial-modification treatment, while a small-looking feature can still be substantial if it introduces unassessed cybersecurity risk.

Yes. The adopted Commission guidance says security updates are generally not substantial modifications when their primary purpose is to reduce cybersecurity risk, they do not change the product's intended purpose, and they do not introduce new cybersecurity risks.

Packaging does not control the answer. A feature update provided together with a security update is still assessed by its effect on intended purpose and cybersecurity risk, not by the release label.