Classification

Does an embedded operating system change a product’s CRA class?

Classification follows the core functionality of the product being supplied. The presence of an operating-system component alone does not settle the classification of the whole product.

Prepared by CRA Operations · Updated 2026-09-13 · Hypothetical worked examples

The situation

A measurement instrument includes an operating system and an access-control feature. Its principal supplied function is measurement. The team must compare the complete offering against the legal category descriptions rather than inherit a class from every component in the bill of materials.

Facts that change the answer

  • What is the principal function customers buy?
  • Is a component also supplied as a separate product?
  • Has the category comparison been documented for the complete offering?

Compare the worked results

These examples use the published assessment with the assumptions shown below. Change the facts in your own assessment before relying on its result.

Complete product assessed outside listed classes

Hypothetical example 1

Assessment resultmodule a available
Key facts in this example
The product’s main features and technical capabilities needed for its intended purpose are documented
Yes
Classification based on the product’s own core functionality
default product
All recorded assumptions (5)
Product with digital elements
Hypothetical example product
The product’s main features and technical capabilities needed for its intended purpose are documented
Yes
Classification based on the product’s own core functionality
default product
Conformity-assessment route selected for planning
module a internal control
The conformity plan covers the product as a whole, including cybersecurity risks from ancillary functions and integrated components
Yes

Core-function assessment missing

Hypothetical example 2

Assessment resultclassification review required
Key facts in this example
The product’s main features and technical capabilities needed for its intended purpose are documented
No
Classification based on the product’s own core functionality
uncertain
All recorded assumptions (5)
Product with digital elements
Hypothetical example product
The product’s main features and technical capabilities needed for its intended purpose are documented
No
Classification based on the product’s own core functionality
uncertain
Conformity-assessment route selected for planning
module a internal control
The conformity plan covers the product as a whole, including cybersecurity risks from ancillary functions and integrated components
Yes

Evaluated on 2026-09-13 using EU Cyber Resilience Act product classification and conformity route, version 2026.09.02. A completed example is not a customer Record or a declaration of conformity.

Evidence to keep

  • Product-boundary and core-function statement
  • Comparison against applicable Annex III and IV descriptions
  • Risk assessment including ancillary software and interfaces

Keep source artifacts in their controlled systems and record their references, responsible owner and review date with the decision.

Your next step

Document the core-function reasoning. An uncertain classification needs review before a conformity route is relied on.

Choose your real product or vulnerability case in the workspace. The selected assessment will be highlighted; example answers are not copied into your record.

Sources and application dates

Manufacturer reporting applies from 11 September 2026. Broader product requirements apply from 11 December 2027; these product-readiness examples support preparation. Open-source-steward obligations have their own application date.

These examples structure a decision and do not replace the Regulation, official guidance or product-specific professional advice. Not lawyer-reviewed.

Related situations