Annex III, Class I ยท Regulation (EU) 2024/2847

Is an operating system an important product under the CRA?

Verified against the Official Journal text on

Important product, Class I (Annex III Class I (11), Art. 7(1))

Yes, most likely. The CRA lists "operating systems" as important products (Annex III, Class I, item 11). A product whose core functionality is an operating system carries the full manufacturer obligations and a restricted conformity route: self-assessment stays available only where harmonised standards, common specifications, or eligible certification are applied in full. This reaches desktop, server, mobile, embedded, and real-time operating systems, and a commercial Linux distribution you place on the market. Free and open-source operating systems have specific reliefs.

Basis: Annex III Class I (11), Art. 7(1), Art. 32(1)-(2)

Judgment call: Whether a product "has the core functionality of" an operating system is a classification judgment the technical descriptions in Implementing Regulation (EU) 2025/2392 control.

How broad the category is Annex III Class I (11), Art. 7(1), Art. 7(4)

Item 11 of Class I names "operating systems" without qualification, so the technical description in the implementing act does the defining. On the ordinary meaning the category reaches desktop and server operating systems, mobile operating systems, embedded operating systems, and real-time operating systems (RTOS) shipped in devices.

A commercial Linux distribution is an operating system product for these purposes where you place it on the market in the course of a commercial activity, for example a paid or supported enterprise distribution. Being built on open-source components does not remove it from the category; what it may change is the applicable relief, covered below.

Free and open-source operating systems Art. 3(22), Recital 18, Art. 32(5)

Two distinct reliefs can matter for an open-source operating system. First, free and open-source software supplied outside a commercial activity is not "made available on the market" at all, so the CRA does not bite; paid editions, paid support or hosting, or dual licensing change that. See our open-source software guide for how that line is drawn.

Second, where an open-source operating system is in scope, Article 32(5) lets its manufacturer use the ordinary Article 32(1) procedures, including internal control, despite the Class I listing, provided the technical documentation is made available to the public when the product is placed on the market. That relief is specific to free and open-source Annex III products.

What Class I changes: your conformity route Art. 32(1), Art. 32(2), Art. 32(5), Annex VIII

For a default-category product a manufacturer may self-assess under internal control (module A). For a Class I important product that choice narrows: internal control remains available only where you apply harmonised standards, common specifications, or a European cybersecurity certification scheme at assurance level at least "substantial", in full, to the relevant essential requirements.

Where you do not, or where no such standard yet exists, the product must go through EU-type examination plus conformity to type (modules B and C) or full quality assurance (module H), both involving a notified body, unless the Article 32(5) open-source relief applies. Plan for that lead time well before 11 December 2027.

Everything else is the ordinary manufacturer programme Art. 13, Art. 14, Annex I

Class I status changes the conformity route, not the substance. The essential cybersecurity requirements, vulnerability handling including a coordinated vulnerability disclosure policy, technical documentation, CE marking, and the reporting duties for actively exploited vulnerabilities and severe incidents apply to an operating system as they do to any product in scope. For an operating system, secure defaults and a working update mechanism are central.

What you must do

  • Design, develop, and produce the operating system in line with the essential cybersecurity requirements. (Art. 13(1), Annex I Part I)
  • Handle vulnerabilities during the support period, including putting in place and enforcing a coordinated vulnerability disclosure policy. (Art. 13(8), Annex I Part II (5))
  • Draw up technical documentation and carry out the Class I conformity assessment: internal control only with harmonised standards, common specifications, or eligible certification applied in full (or under the Article 32(5) open-source relief), otherwise modules B and C or module H via a notified body. Then affix the CE marking. (Art. 13(12), Art. 32(2), Art. 32(5), Annex VIII)
  • Report actively exploited vulnerabilities and severe incidents once reporting duties start. (Art. 14)

The dates that decide your planning

11 September 2026
Reporting duties start. Actively exploited vulnerabilities and severe incidents must be reported via the single reporting platform: early warning within 24 hours, notification within 72 hours, then a final report (within 14 days after a corrective measure is available for vulnerabilities, within one month after the notification for severe incidents). (Art. 14, Art. 16, Art. 71(2))
11 December 2027
The full obligations apply: essential cybersecurity requirements, technical documentation, conformity assessment, and CE marking. (Art. 71(2))

Frequently asked

Does an embedded or real-time operating system count?

Yes. Item 11 names operating systems without qualification, so embedded operating systems and RTOS builds you place on the market fall in the category on the ordinary meaning, with the technical description settling any doubt. (Annex III Class I (11), Art. 7(4))

Is a commercial Linux distribution in scope?

A distribution placed on the market in the course of a commercial activity is an operating system product. Being open-source based does not remove it; where it qualifies as free and open-source, the Article 32(5) relief may let you keep internal control if you publish the technical documentation. (Annex III Class I (11), Art. 32(5))

Can I still self-assess as a Class I product?

Only where you apply harmonised standards, common specifications, or eligible certification in full, or where the Article 32(5) open-source relief applies. Otherwise a notified body route applies (modules B and C, or module H). (Art. 32(2), Art. 32(5))

When does this start applying?

Reporting duties start 11 September 2026. The full obligations, including the Class I conformity route, apply from 11 December 2027. (Art. 71(2))

Check where your product lands, free

The Vexwatch Scope Checker walks the same cited decision tree in about three minutes: whether you are in scope, in which role, in which category, and which obligations hit on which date.

Check your scope, free See the Blueprint

This page is general information about Regulation (EU) 2024/2847, the EU Cyber Resilience Act. It is compliance tooling, not legal advice, and creates no client relationship. It may not reflect your specific circumstances or the most recent regulatory guidance. Verify conclusions against the regulation or qualified counsel before relying on them.