How the CRA Treats Operating Systems

Operating Systems Are Annex III Class I Products

Operating systems are expressly listed in Annex III Class I category 11. A manufacturer should first determine that the supplied software or hardware product is within CRA scope and then ask whether operating-system functionality is the product's core functionality. The category is not limited to desktop or server operating systems familiar to general users. Commission Implementing Regulation (EU) 2025/2392 describes the product functionally and expressly includes real-time, general-purpose and special-purpose operating systems. This makes the category relevant to consumer, enterprise, embedded and specialised computing environments. A larger product that contains an operating system still requires its own classification because integration of a listed product does not automatically transfer the operating system's Class I classification to the complete host product.

• Operating systems are Annex III Class I.
• The category is not limited to desktop operating systems.
• Real-time and specialised operating systems can be included.
• The host product requires its own core-functionality analysis.

The Technical Description Begins With Hardware Abstraction

Commission Implementing Regulation (EU) 2025/2392 describes operating systems as software products with digital elements that provide an abstract interface of the underlying hardware. This abstraction enables applications and other software to use computing resources without interacting directly with every hardware detail. The operating system can mediate access to processors, memory, storage devices, network interfaces and peripherals through defined services and interfaces. A manufacturer should therefore look at the role the software plays between applications and the underlying computing environment. Software that merely runs on an operating system is not itself an operating system because it uses system services rather than providing the foundational abstraction and control layer described by the category.

• Hardware abstraction is central to the technical description.
• Operating systems sit between software and underlying hardware.
• Applications that use OS services are not automatically operating systems.
• The product architecture should show the abstraction layer.

Controlling Software Execution Is Another Defining Function

The technical description also states that an operating system controls the execution of software. This can include loading processes, managing execution environments, controlling access to resources and coordinating interactions between applications and hardware. The precise mechanisms differ considerably between operating systems, especially across desktop, mobile, embedded and real-time environments. The CRA classification does not depend on one particular architecture or kernel design. The manufacturer should instead determine whether controlling software execution is part of the product's defining role. A runtime environment or application platform may also manage software execution in some sense, but that does not automatically make it an operating system if it does not provide the broader hardware abstraction and system-level functions in the technical description.

• Operating systems control software execution.
• The CRA does not prescribe one kernel architecture.
• Execution control should be assessed together with hardware abstraction.
• Application runtimes are not automatically operating systems.

Resource Management and Scheduling Can Be Part of the Operating System

The implementing regulation identifies computing resource management, configuration and scheduling among the services an operating system may provide. These functions can include allocation of processor time, memory management, storage access, device resources and coordination between software processes. In real-time operating systems, scheduling behaviour may be especially important because software tasks can have timing constraints and deterministic execution requirements. In general-purpose operating systems, resource management can serve a much broader range of workloads. These differences do not create separate CRA classes. Where the product meets the operating-system technical description, it remains within Annex III Class I category 11.

Input-Output Control and Peripheral Interfaces Are Relevant

Operating systems may also provide input-output control, manage data and supply interfaces through which applications interact with system resources and peripherals. These functions can involve device drivers, storage interfaces, networking, file systems or APIs that mediate access to hardware capabilities. The technical description therefore recognises the operating system as a central control layer rather than merely a bootable software package. Manufacturers of specialised systems should document which services the operating system exposes to applications and how those services control access to the device's resources. This evidence helps distinguish the operating system from application software, firmware utilities and other components that use those services.

• Input-output control can be an OS service.
• Data management can be an OS service.
• Applications can interact with resources through operating-system interfaces.
• Peripheral control helps distinguish the operating-system layer.

Real-Time Operating Systems Are Expressly Included

Real-time operating systems are expressly included in the non-exhaustive examples in Commission Implementing Regulation (EU) 2025/2392. This is important for embedded, industrial, automotive-adjacent, telecommunications and other specialised environments where an RTOS may control software execution on constrained or dedicated hardware. CRA coverage still needs to be established for the supplied product, and other exclusions or specialised Union rules must be considered where applicable. However, an RTOS is not outside the important-product classification merely because it is not a general-purpose desktop or server operating system. Where it is separately placed on the market and has operating-system core functionality, the Class I category can directly apply.

• Real-time operating systems are expressly included.
• Embedded deployment does not by itself remove the category.
• Separately supplied RTOS products can be Class I.
• CRA scope should still be checked before classification.

General-Purpose and Special-Purpose Operating Systems Are Also Included

The technical description also expressly includes general-purpose and special-purpose operating systems. General-purpose systems are designed to support many applications and workloads, while special-purpose systems can be designed for a narrower technical environment or dedicated device class. The CRA does not classify one of these types more strictly than another merely because of its deployment context. Both remain within the Class I operating-system category where the technical description is met. The cybersecurity risk assessment, however, should reflect the actual intended use, attack surface, privileges and potential impact of compromise for the specific product rather than relying on a generic operating-system risk profile.

• General-purpose operating systems are included.
• Special-purpose operating systems are included.
• Deployment context does not create a separate CRA class.
• Risk assessment should remain product specific.

Operating Systems and Hypervisors Have Different CRA Classes

Operating systems and hypervisors can both control fundamental computing resources, but the CRA places them in different categories. Operating systems are Annex III Class I. Hypervisors and qualifying container runtime systems are Annex III Class II. An operating system provides the abstract hardware interface and controls software execution within its environment, while a hypervisor abstracts or allocates computing resources to enable and manage logically separated virtual machines. Some architectures contain both layers. The manufacturer should classify the actual supplied product according to its own core functionality rather than assume that all foundational system software receives the same CRA class.

• Operating systems are Class I.
• Hypervisors are Class II.
• The products have different technical descriptions.
• Architecture should identify which layer is actually being supplied.

Class I Conformity Rules Apply to Operating Systems

Operating systems within Annex III category 11 use the Class I conformity framework in Article 32(2). Internal control can remain available where the applicable conditions involving harmonised standards, common specifications or an applicable European cybersecurity certification scheme are satisfied. Where the required conditions are not met, a stricter conformity procedure is necessary. The European Commission identifies operating systems among important products for which notified-body involvement can become necessary. Manufacturers should therefore complete classification and standards mapping early enough to determine the conformity route before release planning is finalised.

• Operating systems use the Class I conformity framework.
• Internal control is conditional.
• Standards coverage can affect the route.
• Third-party assessment may become necessary.

Document the Operating-System Boundary

A classification record should identify the exact operating-system product and version, supported hardware environment, hardware-abstraction role, software-execution functions, resource management, scheduling, input-output services and application interfaces. It should also identify related boot managers, hypervisors, container runtimes and device firmware where those components could create product-boundary questions. The record should reference Annex III category 11 and Commission Implementing Regulation (EU) 2025/2392 and state the selected Article 32 procedure. Material architectural changes, changes to the supplied product boundary or changes between operating-system and virtualisation functions should trigger review.

• Record the OS product and version.
• Record hardware-abstraction and execution-control functions.
• Identify adjacent boot and virtualisation components.
• Record the Article 32 route.
• Connect the conclusion to technical documentation.
• Review after material architecture changes.