Search every question across sub-FAQs

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 draft 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 draft 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.

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 draft guidance says similar domain, purpose, or deployment context does not prove shared core functionality.

A 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 draft 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 draft 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 draft 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 it covers 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 draft 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 draft 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.

No. The CRA definition of substantial modification focuses on changes made after placing on the market that affect compliance with the essential cybersecurity requirements or change the intended purpose for which the product was assessed.

Recital 42 says refurbishment, maintenance, and repair do not necessarily lead to substantial modification, for example where intended purpose, functionality, and risk level remain unaffected. A manufacturer-led upgrade can be different if it changes the product's design, development, intended purpose, or CRA compliance position.

Assess the repair case by case against the product's original CRA assessment. A physical repair is not substantial merely because hardware was opened, a component was replaced, or an old part was exchanged for a newer one.

The practical test is whether the repair changes the intended purpose, changes essential functionality, increases cybersecurity risk, or affects compliance with Annex I Part I in a way not covered by the existing cybersecurity risk assessment.