Search every question across sub-FAQs

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.

Yes, but the exclusion is narrow. Article 2(6) excludes spare parts made available on the market to replace identical components in products with digital elements, when those spare parts are manufactured according to the same specifications as the components they replace.

That means the part has to be an identical-specification replacement. It is not enough that the part is generally compatible or performs the same business function.

Yes. Recital 29 says the spare-part exemption is intended to cover spare parts used to repair legacy products made available before the CRA's date of application, as well as spare parts for products that have already undergone CRA conformity assessment.

For legacy products, the exclusion answers whether the identical spare part itself is outside the CRA. It does not remove the separate need to check whether the repair activity substantially modifies the product.

Then Article 2(6) does not settle the matter. The non-identical spare part may need to be assessed as a product with digital elements in its own right if it is made available on the market and otherwise falls within CRA scope.

The replacement part's CRA assessment should reflect its own intended purpose, including compatibility or interoperability with the existing product. Compatibility constraints can be relevant, but they should be documented rather than used as an unsupported exemption.

No. The fact that the spare part is not covered by Article 2(6) does not automatically mean the repaired product has been substantially modified.

The repaired product still has to be assessed against the substantial-modification test: whether the change affects compliance with the essential cybersecurity requirements, changes intended purpose, or changes the cybersecurity risk profile of the product.

No. The Article 2(6) exclusion requires an identical component manufactured according to the same specifications. A replacement can keep the same function, protocols, or security mechanisms and still fall outside the exclusion if its specifications differ.

That distinction matters for repair planning: same operational role may help the substantial-modification analysis, but it does not by itself make the part an identical spare part under Article 2(6).

The manufacturer should treat the compatibility limit as a cybersecurity risk-assessment issue, not as a reason to ignore the CRA. Where a requirement is not applicable or cannot be met in the usual way because of product nature, interoperability, or compatibility, the risk assessment and technical documentation should explain why.

The manufacturer should then use appropriate alternative or compensatory measures, describe the remaining constraints and risks in the technical documentation and user information, and reassess whether those constraints can be reduced during the support period.

Yes, often. Recital 39 says a security update designed to decrease cybersecurity risk is not considered a substantial modification when it does not modify the product's intended purpose.

The Commission FAQ gives a legacy smart-TV example: a post-2027 bug-fix update that does not qualify as a substantial modification does not require bringing that pre-application product into full CRA conformity.

A software update can become substantial when it changes the product's intended purpose or changes the type or performance of the product in a way that affects cybersecurity risk. The label attached to the release is not decisive.

Feature updates deserve particular attention when they add new interfaces, new inputs, new dependencies, new data flows, or new operating modes that were not covered by the original cybersecurity risk assessment.

For products with digital elements placed on the market before 11 December 2027, Article 69(2) says the CRA requirements apply only if, from that date, those products are subject to a substantial modification.

There is an important exception: Article 69(3) applies Article 14 reporting obligations to all in-scope products placed on the market before 11 December 2027. The Commission FAQ states that reporting obligations start applying from 11 September 2026.