Are Hypervisors and Container Runtimes Class II Under the CRA?

Short answer: hypervisors and container runtime systems are important products of Class II under the Cyber Resilience Act (Regulation (EU) 2024/2847, Annex III, Class II, point 1). A Class II product cannot be self-assessed: it needs a notified body or a European cybersecurity certificate. The one exception is open-source software that publishes its technical documentation.

What counts as a hypervisor or container runtime under the CRA

The category is described in Commission Implementing Regulation (EU) 2025/2392:

• Hypervisors abstract or allocate computing resources and enable the execution, management and orchestration of virtual machines logically separated from each other or from the hardware. They may run on bare metal, on top of an operating system, or inside another virtual machine. The description names type 1, type 2 and hybrid hypervisors.
• Container runtime systems manage the execution and lifecycle of containers on a single host operating system as isolated processes, allocating resources and allowing the management and orchestration of individual containers.

Both halves share the reason for Class II: they are what keeps workloads apart. A flaw in the separation layer exposes everything running on top of it.

What stays out of the category

The CRA classifies by core functionality (Article 7(1)), and that cuts both ways:

• Devices that use a hypervisor inside. An industrial controller, a gateway or an infotainment unit that separates its software with an embedded hypervisor is classified by what it does. Recital 3 of the implementing regulation states that integrating a component that meets a category does not in itself bring the whole product into it. The hypervisor supplier, if it sells the hypervisor on its own, is the one in Class II.
• Operating systems with virtualisation built in. Recital 4 of the implementing regulation says that a product keeps its core functionality when it integrates functions of another category, with the example of an operating system integrating a browser. By the same logic, an operating system that includes a hypervisor module is usually classified as an operating system, which is Class I.
• Cluster orchestration. The description of container runtimes speaks of containers on a single host. Software whose core function is scheduling workloads across a cluster is not described by that wording, but many distributions ship a runtime as well, so the core function has to be argued in the technical documentation.
• Hypervisors that are not placed on the market. A cloud provider that runs its own hypervisor to deliver a service, without supplying it to anyone, is providing a service. That falls under NIS2, not the CRA.

What Class II means for conformity assessment

For Class II, Article 32(3) leaves three routes, and internal control is not one of them, even with harmonised standards applied in full:

• EU-type examination (module B) followed by conformity to type based on internal production control (module C);
• Full quality assurance (module H); or
• where available and applicable, a European cybersecurity certification scheme at assurance level at least "substantial".

The rules on notified bodies have applied since 11 June 2026 and the first bodies are only now being designated. If your product is Class II, finding one and getting through module B is the longest lead time in the project. See notified body requirements and Class I and Class II.

The open-source route

Open-source software developed outside a commercial activity is not covered by the CRA, and open-source stewards have lighter obligations of their own (steward obligations). Where free and open-source software in an Annex III category is placed on the market, Article 32(5) lets the manufacturer use internal control (module A), provided the technical documentation is made public when the product is placed on the market. For a commercial hypervisor or runtime built on open source, that is the only path to Class II conformity without a third party.

Dates that matter for hypervisor and runtime vendors

• 11 September 2026: the reporting obligations of Article 14 apply, including to versions already on the market. An actively exploited vulnerability, such as a guest-to-host escape seen in the wild, has to be notified within 24 hours.
• 11 December 2027: the essential requirements and the conformity assessment apply to every product placed on the market from that day.

Whatever the route, write the classification down: the core function, the technical description it meets, and, if you are on the edge, why your product is or is not a hypervisor or a runtime.

Frequently asked questions

Are hypervisors Class II under the CRA?

Yes. Hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments are listed in Annex III, Class II, point 1. Implementing Regulation (EU) 2025/2392 names type 1 (bare metal), type 2 (hosted) and hybrid hypervisors.

Can a Class II product be self-assessed?

No. Article 32(3) leaves three routes: EU-type examination (module B) followed by module C, full quality assurance (module H), or a European cybersecurity certification scheme at assurance level at least substantial where one is available. Applying harmonised standards does not open internal control for Class II.

Is an embedded device that uses a hypervisor internally a Class II product?

Not because of the hypervisor. The device is classified by its own core function (Article 7(1)), and recital 3 of Implementing Regulation (EU) 2025/2392 says integrating a component that meets a category does not in itself move the whole product into it. The supplier of the hypervisor, if it sells it on its own, is in Class II.

Does the CRA apply to a hypervisor run by a cloud provider?

Only to what is placed on the market. A hypervisor that a cloud provider runs for its own service and does not supply to anyone is part of a service, which falls under NIS2 rather than the CRA.

What about open-source hypervisors and container runtimes?

Open-source software developed outside a commercial activity is outside the CRA. Where open-source software in an Annex III category is placed on the market, Article 32(5) allows internal control (module A) provided the technical documentation is made public when the product is placed on the market.