CRA Operations

Classification

Can commercial open-source software use CRA internal control?

A specific route exists for qualifying free and open-source products, with conditions including public technical documentation. Being open source is not enough by itself.

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

The situation

A commercially supplied open-source security product is assessed as Class II. One release has a documented plan to satisfy the public-technical-documentation condition; another keeps that documentation private. The route decision must reflect that difference without changing the underlying product class.

Facts that change the answer

  • Does the product qualify for the relevant free-and-open-source route?
  • Will the required technical documentation be made public?
  • Has the whole-product risk coverage been documented?

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.

Class II FOSS with the public-documentation condition met

Hypothetical example 1

Assessment resultmodule a available for qualifying foss
Key facts in this example
Annex category and technical-description reference
Hypothetical Class II FOSS product meeting Article 32(5) conditions.
Commercial free and open-source software route
qualifies and technical documentation will be public
All recorded assumptions (7)
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
important class ii
Annex category and technical-description reference
Hypothetical Class II FOSS product meeting Article 32(5) conditions.
Commercial free and open-source software route
qualifies and technical documentation will be public
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

Public-documentation condition not met

Hypothetical example 2

Assessment resultroute selection inconsistent

The selected route does not match the recorded classification or supporting conditions. Obtain a product-specific conformity assessment review.(CRA Article 32)

Key facts in this example
Annex category and technical-description reference
Hypothetical Class II FOSS product without the public-documentation condition.
Commercial free and open-source software route
qualifies but public documentation condition not met
All recorded assumptions (7)
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
important class ii
Annex category and technical-description reference
Hypothetical Class II FOSS product without the public-documentation condition.
Commercial free and open-source software route
qualifies but public documentation condition not met
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

  • Qualification rationale under Article 32
  • Publication plan and references for technical documentation
  • Selected conformity procedure and complete risk coverage

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

Your next step

Confirm each condition before relying on the special route. If it is unavailable, assess the ordinary procedure for the documented class.

Start this assessmentSign in to your workspace

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

Which CRA conformity route applies to a router?

First match the core routing function to the legal category. For a Class I example, the available internal-control route depends on the applicable conformity basis and its coverage.

Does a CRA firewall assessment require a third party?

A documented Class II firewall example normally requires a qualifying third-party route. Merely selecting internal control does not make that route available.

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.

What evidence supports CRA secure-by-default readiness?

The readiness record should demonstrate the shipped configuration and its security behaviour. A policy saying that defaults are secure is not evidence that the release implements them.