Improve wording of TODOs and remove some extra line breaks

# 3 Definition of terms, symbols and abbreviations

**_Editor's Note_: _This Section Needs To Be Updated_**

**Editor's Note:** This Section Needs To Be Updated

## 3.1 Terms

**Operating System (OS)** is defined in European Commission Implementing Act 2025/2392.

_Editor's Note_: _The definition of Operating System is copied below for reference._

**Editor's Note:** _The definition of Operating System is copied below for reference._

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

> This category includes but is not limited to real-time operating systems, general-purpose and special-purpose operating systems.

## 4.7 Use Cases

**EDITORS NOTE:** The following list of use cases is an illustrative set of possible use cases selected to demonstrate the mechanics of this standard and provide clear guidance for the most common product categories.

**Editor's Note:** The following list of use cases is an illustrative set of possible use cases selected to demonstrate the mechanics of this standard and provide clear guidance for the most common product categories.

**EDITORS NOTE:** Considering that Operating Systems provide an essential functionality for all Digital Products, it is not feasible to list in detail either all extant or all potential use cases for operating systems.

**Editor's Note:** Considering that Operating Systems provide an essential functionality for all Digital Products, it is not feasible to list in detail either all extant or all potential use cases for operating systems.

**EDITORS NOTE:** We anticipate that future revisions of this document may include additional use cases, such as for the following product scenarios: embedded devides, baseband management controllers, network interface cards, graphics cards, real-time applications, and special purpose operating systems.

**Editor's Note:** We anticipate that future revisions of this document may include additional use cases, such as for the following product scenarios: embedded devides, baseband management controllers, network interface cards, graphics cards, real-time applications, and special purpose operating systems.

### 4.7.1 **UC-LR** Operating system for learning and research

  * is not used for any purpose beyond learning and research

## 5.1 Notes on the structure of the Requirements

**EDITOR'S NOTE:** The CRA requires the manufacturer to keep all the documentation necessary to show that the tests were conducted. In Article 13 Rec. 22, MSA's are granted the right to request "all the information and documentation, in paper or electronic form, necessary to demonstrate the conformity of the product with digital elements and of the processes put in place by the manufacturer with the essential cybersecurity requirements set out in Annex I." The objective of these requirements is to provide manufacturers with sufficient guidance to consistently satisfy such requests from the market authorities. 

**Editor's Note:** The CRA requires the manufacturer to keep all the documentation necessary to show that the tests were conducted. In Article 13 Rec. 22, MSA's are granted the right to request "all the information and documentation, in paper or electronic form, necessary to demonstrate the conformity of the product with digital elements and of the processes put in place by the manufacturer with the essential cybersecurity requirements set out in Annex I." The objective of these requirements is to provide manufacturers with sufficient guidance to consistently satisfy such requests from the market authorities. 

### 5.1.1 Necessity of Requirements

  * Verdict: No undocumented interfaces are found and no interfaces can be accessed without authorization other than those documented as necessary and the instructions to the user are sufficient => PASS, otherwise => FAIL

  * Evidence: List of interfaces, log of attempts to access

### 5.2.X TR-SCUD: Secure updates

### 5.2.9 TR-SCUD: Secure updates

#### 5.2.X.x Requirement

#### 5.2.9.1 Requirement

The product shall be securely updateable by the user.

> TODO: Waiting on completion of ETSI membership process to include detailed secure update text from an ETSI delegate. The following text is for update by the operational environment (other OS, human process, etc.).

#### 5.2.X.x MI-SCHL: Low security updates provided by operational environment

#### 5.2.9.2 MI-SCHL: Low security updates provided by operational environment

The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the "Low" security level for the product supplying it.

  * Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL

  * Evidence: Documentation and analysis of completeness

#### 5.2.X.x MI-SCHM: Medium security updates provided by operational environment

#### 5.2.9.3 MI-SCHM: Medium security updates provided by operational environment

The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the "Medium" security level for the product supplying it.

  * Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL

  * Evidence: Documentation and analysis of completeness

#### 5.2.X.x MI-SCHH: High security updates provided by operational environment

#### 5.2.9.4 MI-SCHH: High security updates provided by operational environment

The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the "High" security level for the product supplying it.

  * Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL

  * Evidence: Documentation and analysis of completeness

#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

#### 5.2.9.5 TODO

See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.

**Editor's Note:** We are waiting on an anticipated submission of additions to this section from an ETSI member who has unexpectedly become unavailable.

### 5.2.7 TR-AUTH: Authentication and access control

> TODO: Manufacturers need to contribute state-of-the-art authentication requirements. This section should reference authentication and access control standards when they exist.

**Editor's Note:** We anticipate that future revisions of this document will include state-of-the-art authentication requirements. This section should reference authentication and access control standards.

### 5.2.7 TR-CDST: Confidentiality of data stored on the product

#### 5.2.7.2 MI-CDST: Protect confidentiality of data stored on the product

> TODO: This is a blanket mitigation that is too vague and high-level. Manufacturers need to contribute more detailed and specific mitigations.

**Editor's Note:** We have included only a high-level mitigation, and anticipate that more detailed and specific mitigations will be added later.

The product shall protect data stored on the product from unauthorized access.

#### 5.2.8.2 MI-CDTX: Protect confidentiality of data transmitted by product

> TODO: This is a blanket mitigation that is too vague and high-level. Manufacturers need to contribute more detailed and specific mitigations.

**Editor's Note:** We have included only a high-level mitigation, and anticipate that more detailed and specific mitigations will be added later.

The product shall protect data transmitted by the product from unauthorized access.

### 5.2.9 TR-CRYP: Encryption

> TODO: Fill in very limited encryption requirements that are not performance-related (this is probably remote management and self-update). Need to specify any necessary encryption algorithms that are not already included in the Agreed Cryptographic Mechanism and CRA Addendum.

**Editor's Note:** We anticipate that future revisions of this document will include state-of-the-art encryption requirements, including references to appropriate encryption standards not already included in the Agreed Cryptographic Mechanism and CRA Addendum.

### 5.2.10 TR-IDST: Integrity of data stored on the product

#### 5.2.10.2 MI-IDST: Protect integrity of data stored on the product

> TODO: This is a blanket mitigation that is too vague and high-level. Manufacturers need to contribute more detailed and specific mitigations.

**Editor's Note:** We have included only a high-level mitigation, and anticipate that more detailed and specific mitigations will be added later.

The product shall protect the integrity of data stored on the product from unauthorized modification.

#### 5.2.10.3 MI-DCST: Detect corruption of data stored

> TODO: This is a blanket mitigation that is too vague and high-level. Manufacturers need to contribute more detailed and specific mitigations.

**Editor's Note:** We have included only a high-level mitigation, and anticipate that more detailed and specific mitigations will be added later.

The product shall detect corruption of the data stored on the product.

#### 5.2.11.2 MI-DCTX: Detect corruption of data transmitted by the product

> TODO: This is a blanket mitigation that is too vague and high-level. Manufacturers need to contribute more detailed and specific mitigations.

**Editor's Note:** We have included only a high-level mitigation, and anticipate that more detailed and specific mitigations will be added later.

The product shall detect corruption of the data transmitted by the product.

  * Reference: TR-IDTX

  * Objective: Integrity of data

  * Preparation: List all types of data that may be transmitted by the product whose corruption should be detected and what methods of detecting corruption are appropriate for each type

  * Activities: For each type of data and method of detecting corruption, corrupt the data in a way that the method will detect

  * Verdict: If all methods of detecting corruption match the type of the data transmitted, and all the corruptions of data are detected => PASS, otherwise => FAIL

  * Evidence: Logs of determination of type of data and corruptions of data

#### 5.2.11.3 Mapping of mitigations to risk factors and security profiles

All sources of data processed by the product in its secure-by-default configuration shall be documented. All sources of data processed shall have a documented rationale for why its processing is necessary for the functioning of the product in its secure-by-default configuration.

  * Reference: TR-DMIN

  * Objective: Minimize data processed

  * Preparation: List all potential sources of data for the product. For each source of data, identify a method to detect whether the product is processing data from that source.

  * Activities: Using the list of sources of data, and the method to detect whether the product is processing data from that source, list all sources of data processed. Compare to the documented list.

  * Verdict: All sources of processed data are documented, including rationale => PASS, otherwise => FAIL

  * Evidence: List of sources of data, documentation of each source of data, list of sources of data processed, connection between each discovered source of processed data to its documentation

#### 5.2.12.3 Mapping of mitigations to risk factors and security profiles

All exposed interfaces on the product in any state that is part of its reasonably foreseeable use or misuse in its secure-by-default configuration shall be documented. Every interface shall have a documented rationale for why its exposure is necessary for the functioning of the product in its secure-by-default configuration.

  * Reference: TR-LMAS

  * Objective: Limit attack surface

  * Preparation: List all types of interfaces on the product that may be exposed to an attacker, whether enabled or disabled. For each type of interface, identify a method to list all exposed interfaces of that type. List all states of the product with different exposed interfaces of the product in its secure-by-default configuration, including but not limited to initial configuration, startup, in use, idle, shutdown, and reset, if applicable. For each distinct exposed interface in each state, describe the interface and why it has to be enabled by default.

  * Activities: Using the list of types of interfaces, the list of states of the product, and the method to list all exposed interfaces of that type, list all exposed interfaces in each state. Compare to the documented list.

  * Verdict: All discovered interfaces are documented, including rationale => PASS, otherwise => FAIL

  * Evidence: List of types of interfaces, list of product states, documentation of each exposed interface, output of methods to list all exposed interfaces, connection between each discovered interface to its documentation

#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

The product shall reset to its secure-by-default state after a power cycle or reset command.

  * Applicability: Product has the capability for the user to write data and/or settings

  * Reference: TR-SCDL

  * Objective: Secure deletion

  * Preparation: Document every kind of stored data or setting that may be changed by the user on the product, how to store it on the product, and how to read it from the product

  * Activities: For each kind of user data or setting that may be stored and changed by the user on the product, write an instance of the data or setting stored on the product that is different from the default and read it from the product; once all kinds of data have been written and read, power cycle or reset the product, and read each kind of data again

  * Verdict: If any data or setting is the same for both of the reads => FAIL, otherwise => PASS

  * Evidence: Record of each type of data or setting, what data or setting was written, what data or setting was returned by the first read, and what data or setting was returned by the second read, comparison of each one

#### 5.2.16.3 MI-INST: Secure deletion via reinstallation

The product shall reset to its secure-by-default state after a reinstallation that securely deletes all previous user data or settings.

  * Applicability: Product has the capability for the user to write data and/or settings

  * Reference: TR-SCDL

  * Objective: Secure deletion

  * Preparation: Document every kind of data or setting that may be stored and changed by the user on the product, how to store it on the product, and how to read it from the product

  * Activities: For each kind of user data or setting that may be stored and changed by the user on the product, write an instance of the data or setting stored on the product that is different from the default and read it from the product; once all kinds of data have been written and read, reinstall the product with the secure delete option, and read the data or settings again

  * Verdict: If any data or setting is the same for both of the reads => FAIL, otherwise => PASS

  * Evidence: Record of each type of data or setting, what data or setting was written, what data or setting was returned by the first read, and what data or setting was returned by the second read, comparison of each one

#### 5.2.16.4 MI-DELE: Secure deletion via secure deletion function

The product shall reset to its secure-by-default state after the secure deletion function is used.

> TODO: Make the method of deletion depend on sensitivity of data stored.

**Editor's Note:** this section should be clarified so that the method of deletion depends upon the sensitivity of data stored.

  * Applicability: Product has the capability for the user to write data and/or settings

  * Reference: TR-SCDL

  * Objective: Secure deletion

  * Preparation: Document every kind of data or setting that may be stored and changed by the user on the product, how to store it on the product, and how to read it from the product

  * Activities: For each kind of user data or setting that may be stored and changed by the user on the product, write an instance of the data or setting stored on the product that is different from the default and read it from the product; once all kinds of data have been written and read, activate the secure deletion function, and read the data or settings again

  * Verdict: If any data or setting is the same for both of the reads => FAIL, otherwise => PASS

  * Evidence: Record of each type of data or setting, what data or setting was written, what data or setting was returned by the first read, and what data or setting was returned by the second read, comparison of each one

#### 5.2.16.5 Mapping of mitigations to risk factors and security profiles

The product shall provide a method by which an authorized user can securely read all data and settings from the product.

  * Applicability: Product has the capability for the user to write data and/or settings

  * Reference: TR-SDTR

  * Objective: Secure data read

  * Preparation: List all data and settings

  * Activities: For each kind of data or setting, read the data or setting as an authorized user, then attempt read the data or setting as an unauthorized user, if any exists

  * Verdict: All data and settings can be read by the authorized user, and no data or setting can be read by an unauthorized user => PASS, otherwise FAIL

  * Evidence: List of data and settings, log message showing success or failure of each read by the authorized user and, if applicable, the unauthorized user

#### 5.2.17.3 MI-SDTR: Secure data transfer to another product

If the product provides a method to transfer data and settings to another product, it shall do so securely.

  * Applicability: Product has the capability for the user to write data and/or settings and to transfer them to another product.

  * Reference: TR-SDTR

  * Objective: Secure data transfer

  * Preparation: Prepare methods by which an unauthorized user could read the data during transfer as outlined in the risk assessment

  * Activities: Read the data or settings, initiate the data transfer, attempt to read or alter the transferred data and settings as an unauthorized user, read the new data and settings on the target product

  * Verdict: No data or settings could be read or altered by an an unauthorized user, and the data and settings read from the original product and target product are the same wherever technically possible => PASS, otherwise FAIL

  * Evidence: List of data and settings, log messages from the attempts to read or alter data as the unauthorized user, data and settings as read from the source product and as read from the target product, comparison explaining technical reasons for any differences in the two versions

#### 5.2.17.4 Mapping of mitigations to risk factors and security profiles