Section -> Clause, some minor formatting

## 1.1 General

The present document describes how to demonstrate the compliance of operating systems with the requirements in the EU Regulation 2024/2847, within the context described in section 4, Product Context.

The present document describes how to demonstrate the compliance of operating systems with the requirements in the EU Regulation 2024/2847, within the context described in clause 4, Product Context.

## 1.2 Products in scope

## 3.1 Terms

This section provides terms and definitions based on CEN/CLC JTC13 WG09's work on terms and definitions, terms and definitions provided by ETSI EN 303 645/TS 103 701 and by CEN/CLC EN 18031 series, and informed by terms used in the Common Criteria and the NIAP Operating System Protection Plan guide.

This clause provides terms and definitions based on CEN/CLC JTC13 WG09's work on terms and definitions, terms and definitions provided by ETSI EN 303 645/TS 103 701 and by CEN/CLC EN 18031 series, and informed by terms used in the Common Criteria and the NIAP Operating System Protection Plan guide.

For the purposes of the present document, the following terms apply:

## 4.1 General

> NOTE: This section's structure is built upon CEN/CLC JTC13 PT01's deliverable and might require restructuring based on its progress.

> NOTE: This clause's structure is built upon CEN/CLC JTC13 PT01's deliverable and might require restructuring based on its progress.

## 4.2 Out of scope use/environments

> 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 the present document:

> The types of product with digital elements listed in this clause 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>

* Real time applications

* Other use cases for special purpose operating systems

FIXME prune this down to the most common use cases

> FIXME: prune this down to the most common use cases

## 4.5 Risk factors

### 4.5.1 List of risk factors

Risk factors determine which mitigation(s) satisfy each of the technical requirements in Section 5.2. The manufacturer determines the level of each risk factor via the development of a threat model and risk profile based on the intended and foreseeable use and misuse of the operating system.

Risk factors determine which mitigation(s) satisfy each of the technical requirements in clause 5.2. The manufacturer determines the level of each risk factor via the development of a threat model and risk profile based on the intended and foreseeable use and misuse of the operating system.

Risk factors may increase the likelihood of an incident, increase the impact of an incident, or both. As a result, different mitigation strategies may be more or less relevant to different risk factors.

The overall risk related to each use case should be considered as a result of combining risk factors affecting both likelihood and impact of an incident.

FIXME reference guidance on risk assessment when it exists.

> FIXME: reference guidance on risk assessment when it exists.

#### 4.5.1.x Number of User Accounts

### 4.5.2 Mapping of Use Cases to Risk Factors

**NOTE:** The "TOTAL" field is referenced by but does not define the Risk Tolerance assignments table in Section 6.3. It is primarily a consistency check to see if the risk factors sufficiently distinguish the differences in risk tolerance between use cases.

**NOTE:** The "TOTAL" field is referenced by but does not define the Risk Tolerance assignments table in clause 6.3. It is primarily a consistency check to see if the risk factors sufficiently distinguish the differences in risk tolerance between use cases.

FIXME needs updates

### 5.2.1 General

This section is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. The following section will define which mitigations will be required, depending on a risk factor, the overall risk tolerance, and/or a use case in the following section.

This clause is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. The following clause will define which mitigations will be required, depending on a risk factor, the overall risk tolerance, and/or a use case in the following clause.

Some risks may be transferred partially or fully to other components of the system or the user of the product. When that is the case, migitations that transfer the risk will be included as an option to fulfill a technical requirement, depending on the use case and risk factors.

### 5.1.2 Notes on Mitigations

Specific technical mitigations should be articulated in relation to specific Risk Factors (Section 4.5).

Specific technical mitigations should be articulated in relation to specific Risk Factors (clause 4.5).

This 1-to-1 mapping enables clear identification of appropriate mitigations for each Use Case based on the mapping of risk factors to use cases.

### 5.2.1 General

This section is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. The following section will define which mitigations will be required, depending on a risk factor, the overall risk tolerance, and/or a use case in the following section.

This clause is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. The following clause will define which mitigations will be required, depending on a risk factor, the overall risk tolerance, and/or a use case in the following clause.

Some risks may be transferred partially or fully to other components of the system or the user of the product. When that is the case, migitations that transfer the risk will be included as an option to fulfill a technical requirement, depending on the use case and risk factors.

## 5.3 Risk Mitigation Sets

> **TODO**: Connect the technical security requirements in Section 5.2 to specific Risk Factors, and define these as sets of Risk Mitigations that will be referenced in section 6.

> **TODO**: Connect the technical security requirements in clause 5.2 to specific Risk Factors, and define these as sets of Risk Mitigations that will be referenced in clause 6.

# 6 Security Profiles

## 6.1 General

Security Profiles are mapped one-to-one to each Use Case (defined in Section 4.4).

Security Profiles are mapped one-to-one to each Use Case (defined in clause 4.4).

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

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

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

FIXME should be Annex ZA

> Table mapping technical security requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical security requirements.

> Table mapping technical security requirements from clause 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical security requirements.

| CRA requirement                                 | Technical security requirements(s) |

|-------------------------------------------------|------------------------------------|

### C.1.2 Product functions

> See the functions in Section 4.7.

> See the functions in clause 4.7.

## C.2 Threats

> - Use for intended purpose or reasonably foreseeable use

> - When integrated into another product

> Example threats can be found in the same documents suggested in the section on security requirements.

**[TH-USDA]:** An attacker may read or modify security-relevant data without proper authorization while stored or in transmission.

**[TH-DATA]:** An attacker may read or modify data without proper authorization while being processed, stored, or transmitted by the operating system.

# Annex E: Notes

> **NOTE: This section is a temporary storage place for notes, will be deleted.

> **NOTE: This clause is a temporary storage place for notes, will be deleted.

> FIXME include the relation graphic between verticals in the architecture overview to explain the outside relationship.