"this standard" -> "the present document"

# Introduction

The present document is a European harmonised standard that defines cybersecurity requirements for products whose primary purpose is providing an operating system. Demonstrating compliance with this standard is not necessary, but doing so provides a presumption of conformity with Regulation (EU) 2024/2847, the Cyber Resilience Act.

The present document is a European harmonised standard that defines cybersecurity requirements for products whose primary purpose is providing an operating system. Demonstrating compliance with the present document is not necessary, but doing so provides a presumption of conformity with Regulation (EU) 2024/2847, the Cyber Resilience Act.

This standard does not apply to products that contain an operating system or are part of an operating system if the core purpose of the product is not that of an operating system. However, it may be useful as one part of the process of demonstrating compliance for a product containing or interacting with an operating system.

The present document does not apply to products that contain an operating system or are part of an operating system if the core purpose of the product is not that of an operating system. However, it may be useful as one part of the process of demonstrating compliance for a product containing or interacting with an operating system.

# 1 Scope

## 1.3 Products not in scope

This standard does not cover parts of the operating system that are not security-relevant.

The present document does not cover parts of the operating system that are not security-relevant.

This standard does not cover:

The present document does not cover:

* Hypervisors or containers

* Boot managers or boot loaders

Containers are a set of process isolation features provided by operating systems. They are an operating system feature, not an operating system.

Usermode "operating systems" are applications simulating an operating system in an application, implemented on top of another operating system's user API. These applications are often used to learn about, develop, or emulate the parts of operating systems that do not directly interface with underlying hardware. They do not and cannot provide the core functions of an operating system as defined for the purposes of this standard.

Usermode "operating systems" are applications simulating an operating system in an application, implemented on top of another operating system's user API. These applications are often used to learn about, develop, or emulate the parts of operating systems that do not directly interface with underlying hardware. They do not and cannot provide the core functions of an operating system as defined for the purposes of the present document.

Boot managers have the primary purpose of initializing the hardware after power on or reset with the goal of choosing, loading, and/or transferring execution to an operating system or other program. While many boot managers provide some or all of the services of an operating system (or are literally operating systems adapted for use as a boot manager), they are designed and intended primarily to transfer control to an operating system or other program, rather than continuously operate and provide services.

> For the convenience of the developers of these standards, the following list is temporarily included and will be removed before publication:

>

> The types of product with digital elements listed in the section do not fall within the scope of the Regulation (EU) 2024/2847 (Cyber Resilience Act) <a href="#_ref_i.1">[i.1]</a>, and are not covered by this standard:

> The types of product with digital elements listed in the section do not fall within the scope of the Regulation (EU) 2024/2847 (Cyber Resilience Act) <a href="#_ref_i.1">[i.1]</a>, and are not covered by the present document:

>

> 1. Services, except for the remote data processing solutions for a covered product as defined in CRA recitals 11-12; article 3, 2 <a href="#_ref_i.1">[i.1]</a>

> 1. Products specifically designed or procured for national security and defence purpose as defined in CRA recitals 14 and 26; article 2, 7-8 <a href="#_ref_i.1">[i.1]</a>

> 1. Spare and used parts as defined in CRA recital 29; article 2, 6 <a href="#_ref_i.1">[i.1]</a>

> 1. Refurbished, repaired, and upgraded products that have not been substantially modifiedas defined in recitals 39 - 42 <a href="#_ref_i.1">[i.1]</a>

>

> The following types of products have reduced or varied requirements under Regulation (EU) 2024/2847 (Cyber Resilience Act) <a href="#_ref_i.1">[i.1]</a> and can only be partially covered by this standard:

> The following types of products have reduced or varied requirements under Regulation (EU) 2024/2847 (Cyber Resilience Act) <a href="#_ref_i.1">[i.1]</a> and can only be partially covered by the present document:

>

> 1. High Risk AI as defined in CRA recital 51; article 12 <a href="#_ref_i.1">[i.1]</a>

> 1. Testing and unfinished versions as defined in recital 37; Article 4, 2-3 <a href="#_ref_i.1">[i.1]</a>

> 1. Products Placed on the Market Prior to December 11, 2027 as defined in CRA article 69 <a href="#_ref_i.1">[i.1]</a>

Out of scope use cases and environments include those explicitly carved out by the Regulation (EU) 2024/2847 (Cyber Resilience Act) <a href="#_ref_i.1">[i.1]</a>, and are not covered by this standard.

Out of scope use cases and environments include those explicitly carved out by the Regulation (EU) 2024/2847 (Cyber Resilience Act) <a href="#_ref_i.1">[i.1]</a>, and are not covered by the present document.

## 4.3 Product overview and architecture

>

> An analysis in terms of likelihood and magnitude of a product’s threats is required to be able to determine the product’s risks.

> NOTE 1 This document does not require a specific methodology for a cybersecurity risk analysis as long as the cybersecurity risk estimation is based on the likelihood of occurrence and magnitude of loss or disruption of cybersecurity risks. Thus, different approaches and models such as the fishbone model, event tree analysis or fault tree models can be used within the analysis of cybersecurity risks.

> NOTE 1 The present document does not require a specific methodology for a cybersecurity risk analysis as long as the cybersecurity risk estimation is based on the likelihood of occurrence and magnitude of loss or disruption of cybersecurity risks. Thus, different approaches and models such as the fishbone model, event tree analysis or fault tree models can be used within the analysis of cybersecurity risks.

> NOTE 2 A qualitative estimation of the cybersecurity risks can be performed using risk matrices that map qualitative categories of the likelihood of occurrence and qualitative categories of magnitude of loss or disruption to cybersecurity risk categories.