Fix various typos

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.

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 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.

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.

# 1 Scope

## 1.2 Products in scope

Products in scope are products whose core function and intended or reasonabily foreseeable use or misuse is as an operating system. Operating systems include software products with digital elements that provide an abstract interface of the underlying hardware and control the execution of software, and that may provide services such as computing resource management and configuration, scheduling, input-output control, managing data, and providing an interface through which applications interact with system resources and peripherals. The underlying hardware may be virtualized to some degree, as when an operating system is running on a hypervisor.

Products in scope are products whose core function and intended or reasonably foreseeable use or misuse is as an operating system. Operating systems include software products with digital elements that provide an abstract interface of the underlying hardware and control the execution of software, and that may provide services such as computing resource management and configuration, scheduling, input-output control, managing data, and providing an interface through which applications interact with system resources and peripherals. The underlying hardware may be virtualized to some degree, as when an operating system is running on a hypervisor.

This category includes but is not limited to:

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 with underlaying 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 this standard.

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 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 this standard:

>

> 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>

### 4.3.3 High-level operating system architectures

Operating systems architecure varies in many ways. Some of the most security-relevant ways include:

Operating systems architecture varies in many ways. Some of the most security-relevant ways include:

* Proportion of operating system code running in different protection domains

* Whether applications run in a separate protection domain from the operating system

**Microkernel:** The operating system kernel running at the highest processor privilege level provides a minimal set of resource allocation services, while many of the operating systems services are provided by separate executables with lower privileges.

**Hybrid kernel:** A mix of microkernel and monolithic kernel, where some operating systems services are provided in the central kerrnel and some are provided by applications. Subsystems that do not need to be high performance and are a frequent source of vulnerabilities are often moved into applications, such as printer drivers or file systems with complex features and/or low performance requirements.

**Hybrid kernel:** A mix of microkernel and monolithic kernel, where some operating systems services are provided in the central kernel and some are provided by applications. Subsystems that do not need to be high performance and are a frequent source of vulnerabilities are often moved into applications, such as printer drivers or file systems with complex features and/or low performance requirements.

**Exokernel:** The operating system does not abstract the resources of the system, it only manages resource allocation between different applications.

**[RF-LOSS]:** likelihood of loss or theft should be accounted for in the risk calculation, particularly for devices that store sensitive personal data.

* LOSS-0: foreseeable use of the operating system is limited to stationary devices or devices with other loss-prevention mechanisms

* LOSS-1: foreseeable use of the operating system is in a device with only incidental loss likelyhood

* LOSS-2: foreseeable use of the operating system is in a device with moderate loss likelyhood

* LOSS-3: foreseeable use of the operating system is in a device with a high loss likelyhood, such as devices which are common targets of theft such as mobile phones

* LOSS-1: foreseeable use of the operating system is in a device with only incidental loss likelihood

* LOSS-2: foreseeable use of the operating system is in a device with moderate loss likelihood

* LOSS-3: foreseeable use of the operating system is in a device with a high loss likelihood, such as devices which are common targets of theft such as mobile phones

#### 4.5.1.7 Hardware Modifiability by End Users

#### 4.5.1.9 Untrusted Peripheral Devices

**[RF-DVCS]:** Manufacturers of operating systems which are intended for devices that support attached peripheral devices, such as those utilizing USB or PCI conenctions, shall account for the risk posed by untrusted or compromised peripheral devices and implement appropriate safeguards.

**[RF-DVCS]:** Manufacturers of operating systems which are intended for devices that support attached peripheral devices, such as those utilizing USB or PCI connections, shall account for the risk posed by untrusted or compromised peripheral devices and implement appropriate safeguards.

* DVCS-0: foreseeable use has no accessible peripheral ports

* DVCS-1: foreseeable use includes only trusted and safe peripheral devices

## 4.6 Risk Tolerance

**NOTE:** Tolerance is inversely proportional to the product of (potential harm) x (likelyhood) of an exploited risk.

**NOTE:** Tolerance is inversely proportional to the product of (potential harm) x (likelihood) of an exploited risk.

* **[RT-C]** / **[RT-1]**: The product is suitable for use in highly sensitive or critical environments.

* **[RT-L]** / **[RT-2]**: The product is suitable for use in environments with low risk tolerances.  

* **[RT-M]** / **[RT-3]**: The product is suitable for use in environments with medium risk tolerances. Some security tradeoffs may be made to improve usability and potential harms from unmitigated risk are widely acceptable.

* **[RT-H]** / **[RT-4]**: The product is suitable for use in environments with high risk tolerances. Potential harms from unmitigated risks are low or negligible, and users are unlikely to reasonably expect security updates within the product's forseeable use. 

* **[RT-H]** / **[RT-4]**: The product is suitable for use in environments with high risk tolerances. Potential harms from unmitigated risks are low or negligible, and users are unlikely to reasonably expect security updates within the product's foreseeable use.

## 4.7 Essential functions

  * Security updates

  * Software upgrade

  * Software installation

  * Software verfication

  * Software verification

  * Firmware upgrades

  * Load kernel modules

* Logging

Each Security Profile connects one Use Case to its relevant Risk Factors (defined in Section 4.5) and necessary Risk Mitigations (defined in Section 5.3).

Risk Tolerances are applied to the forseeable risks associated to each Security Profile, relative to potential severity and likelyhood of an incident affecting users.

Risk Tolerances are applied to the foreseeable risks associated to each Security Profile, relative to potential severity and likelihood of an incident affecting users.

## 6.2 Details of Security Profiles

* Risk Analysis

  * There is no network risk since the device lacks wireless networking capabilities.

  * There is negligible risk to user data since the device does not store or process any sensitive or personal data.

  * While untrusted users may gain physical access to the device, likelyhood of tampering is lower than likelyhood of theft.

  * While untrusted users may gain physical access to the device, likelihood of tampering is lower than likelihood of theft.

  * Interception of non-network wireless signals, such as audio connections, should be considered in the threat model.

* Risk Mitigations

  * TBD - maybe none?

Special case UEFI updates triggered by the operating system: The update mechanism as provided by the firmware (UEFI capsule) is considered to be in the scope of the boot manager vertical, as is the cryptographic verification of such updates.

Special case Windows drivers delivered as part of UEFI and retrieved by Windows from UEFI during Windows installation (usually hardware enabledment like storage and network drivers). FIXME: Look up the name of that mechanism.

Special case Windows drivers delivered as part of UEFI and retrieved by Windows from UEFI during Windows installation (usually hardware enablement like storage and network drivers). FIXME: Look up the name of that mechanism.

Special case of Windows using calls into UEFI runtime services if no native Windows driver for a given peripheral (may even be the graphics card) exists. Does that make this specific UEFI driver part of the operating system?