How the CRA Treats Hypervisors

Hypervisors Are Annex III Class II Products

Hypervisors appear in Annex III Class II category 1 together with container runtime systems that support virtualised execution of operating systems and similar environments. A manufacturer should first determine that the product falls within CRA scope and then determine whether hypervisor functionality is the product's core functionality. Class II matters because the ordinary conditional Class I internal-control route is not available. Hypervisors are foundational software capable of controlling or isolating computing environments, so compromise can affect multiple virtual systems that depend on the same virtualisation layer. The manufacturer should classify the exact hypervisor product rather than treating every software component associated with virtual machines as a hypervisor.

• Hypervisors are Class II.
• They share category 1 with qualifying container runtime systems.
• Core functionality determines classification.
• Class II leads to the stricter Article 32(3) framework.

The Technical Description Focuses on Computing Resource Abstraction

Commission Implementing Regulation (EU) 2025/2392 describes hypervisors as software products with digital elements that abstract and/or allocate computing resources. Those resources can include processor capacity, memory, storage and network interfaces. By controlling how those resources are exposed or allocated, the hypervisor creates logical computing environments for virtual machines. This distinguishes the hypervisor from an application simply running inside a virtual machine. The manufacturer should document what computing resources the product abstracts, how those resources are allocated and the security boundary between virtualised environments and the physical hardware.

• Hypervisors abstract or allocate computing resources.
• CPU, memory, storage and network resources can be relevant.
• Resource isolation is central to virtualisation architecture.
• Applications inside a VM are not themselves hypervisors.

Hypervisors Enable Execution and Management of Virtual Machines

The technical description states that hypervisors enable the execution, management and orchestration of virtual machines that are logically separated from one another and/or from the physical hardware. The implementing regulation describes a virtual machine as a software-defined logical separation of a computing environment containing a virtualised set of hardware resources and typically its own operating system. This distinction is important for CRA classification. The virtual machine is the environment created or managed through the virtualisation layer, while the hypervisor is the software product providing that layer. A virtual-machine image or guest operating system should therefore not be treated as the hypervisor merely because it participates in the same architecture.

• Hypervisors execute and manage virtual machines.
• Virtual machines are logically separated computing environments.
• A VM normally has virtualised hardware resources.
• The VM and hypervisor are different product concepts.

Type 1 Bare-Metal Hypervisors Are Expressly Included

Type 1 hypervisors, commonly described as bare-metal hypervisors, are expressly included in the category. These hypervisors run directly on hardware rather than relying on a conventional host operating system beneath the virtualisation layer. Their direct control over hardware resources makes their security particularly important because a vulnerability at the hypervisor layer can affect multiple guest environments. The CRA does not create a separate classification class for type 1 architecture. It remains within Class II category 1. Manufacturers should document boot trust, management interfaces, isolation mechanisms, update architecture and other security-sensitive functions as part of the product's cybersecurity risk assessment and technical documentation.

Type 2 Hosted Hypervisors Are Also Included

The implementing regulation also expressly includes type 2 hypervisors hosted on an operating system. Running on top of an operating system does not move the hypervisor into the Class I operating-system category. The host operating system and hypervisor are separate functional layers and can have different CRA classifications where they are separate products. The hypervisor remains Class II where its core functionality meets the category 1 technical description. Manufacturers should therefore distinguish vulnerabilities and responsibilities associated with the host operating system from those associated with the hypervisor product itself, while still considering dependencies between the two in the cybersecurity risk assessment.

• Hosted hypervisors are expressly included.
• The host operating system and hypervisor are different functional layers.
• A hosted architecture does not reduce the hypervisor to Class I.
• Dependencies between host and hypervisor should be documented.

Nested Virtualisation Is Recognised by the Technical Description

Commission Implementing Regulation (EU) 2025/2392 also recognises that hypervisors can run within another virtual machine, which is commonly described as nested virtualisation. The fact that a hypervisor is not running directly on physical hardware or on a conventional operating system therefore does not exclude it from the category. The manufacturer should identify what layer of the virtualisation stack is actually being supplied as the product and what resources it abstracts or allocates. Nested architectures can create complex dependency chains, so the cybersecurity risk assessment should consider how compromise or failure in an underlying virtualisation layer affects the supplied hypervisor and its virtual machines.

• Nested hypervisors are recognised.
• A hypervisor can run within another virtual machine.
• Product boundaries remain important in multi-layer virtualisation.
• Underlying virtualisation dependencies belong in the risk assessment.

Hybrid Hypervisors Are Explicitly Included

Hybrid hypervisors are another express example in the implementing regulation. Hybrid architectures can combine characteristics of bare-metal and hosted virtualisation or distribute virtualisation responsibilities across multiple layers. The CRA classification is therefore deliberately functional rather than tied to a single traditional architecture. A manufacturer should analyse what the software product actually does: whether it abstracts or allocates computing resources and enables execution, management or orchestration of logically separated virtual machines. If those functions are core, the Class II category can apply even when the product does not fit neatly into a simple type 1 or type 2 description.

• Hybrid hypervisors are expressly included.
• The classification is architecture-neutral.
• Functional behaviour is more important than marketing labels.
• Document how resources and virtual machines are controlled.

Hypervisors and Operating Systems Have Different CRA Roles

Operating systems and hypervisors both manage computing resources, but their CRA technical descriptions and classifications differ. An operating system provides an abstract interface to underlying hardware and controls execution of software within its environment. A hypervisor abstracts or allocates resources specifically to enable and manage virtual machines as logically separated computing environments. Operating systems are Class I category 11. Hypervisors are Class II category 1. Products that combine operating-system and virtualisation functions require careful product-boundary analysis, especially where different components are separately placed on the market.

• Operating systems are Class I.
• Hypervisors are Class II.
• Both can manage computing resources.
• Virtual-machine enablement distinguishes the hypervisor role.

Container Runtime Systems Share the Class II Category

Annex III Class II category 1 does not stop with hypervisors. It also includes container runtime systems that support virtualised execution of operating systems and similar environments. A container platform should not automatically be called a hypervisor, but it can still fall within the same Class II legal category where the technical description for container runtime systems is met. Manufacturers of virtualisation platforms that combine virtual machines and containers should therefore examine both parts of the category. The classification record should identify whether the supplied product is a hypervisor, container runtime system or a broader product containing both technologies and explain which functions establish its core functionality.

• Container runtime systems share Class II category 1.
• Container runtime and hypervisor are not identical concepts.
• Hybrid platforms can require analysis against both descriptions.
• Classify the supplied product by its actual core functionality.

Class II Requires a Stricter Conformity Route

Article 32(3) governs the conformity assessment of Class II products. A hypervisor manufacturer can use EU-type examination under module B followed by conformity to EU-type under module C, conformity assessment based on full quality assurance under module H, or an applicable European cybersecurity certification scheme at the required assurance level where that option is available. The ordinary Class I conditional internal-control path is not available. The European Commission identifies hypervisors among products for which third-party conformity assessment is mandatory under the CRA framework. Manufacturers should therefore plan notified-body or certification dependencies early and prepare technical evidence around the selected procedure.

• Hypervisors use Article 32(3).
• Module B plus Module C is available.
• Module H is available.
• Applicable European cybersecurity certification can provide another route.

Maintain a Hypervisor-Specific Classification Record

A hypervisor classification record should identify the exact product and version, whether it is bare-metal, hosted, nested or hybrid, which computing resources it abstracts, how virtual machines are separated and which management or orchestration functions are included. It should identify the relationship with host operating systems, guest systems, container runtimes and management products. The record should reference Annex III Class II category 1 and Commission Implementing Regulation (EU) 2025/2392 and state the selected Article 32(3) route. Changes to virtualisation architecture, isolation mechanisms or product boundaries should trigger classification and risk review.

• Record the hypervisor architecture.
• Record virtualised resources and isolation boundaries.
• Identify host and guest dependencies.
• Identify container-runtime relationships.
• Record the Article 32(3) route.
• Review after major virtualisation changes.