Removal of some FIXMEs and formatting

![~~Physical network device architecture~~](media/physical_network_interface.drawio.png)

> FIXME: mermaid chart temporarily removed to generate Word doc

A wired network interface transmits data via a specific physical medium such as Ethernet cable, fiber optic cable, coaxial cable or power lines. A wireless network interface transmits data in a manner that does not require a specific medium, such as radiofrequency waves or visible light communication through the air. A virtual network interface transmits data through software within the memory of a host system, sometimes across a software-defined network fabric.

Wireless network interfaces often have an independent real-time operating system on the network interface itself. Wireless medium access often requires real-time response to manage the radio frequency transmissions properly. The network interface must also prevent improper settings of radio frequency transmission parameters, which is often implemented by having the internal firmware set the parameters, rather than exposing them to the host. The complexity of this firmware may increase the risk of a wireless interface.

A virtual network interface emulates the device driver interface of a network interface to a host's device driver API. Instead of a physical network interface, it may send and receive packets to a hypervisor, a container, another device driver, another part of the network stack, an application, or other software.

> FIXME: add hypervisor or other software to diagram

![~~Virtual network device architecture~~](media/virtual_network_interface.drawio.png)

### 4.3.3 Device drivers for network interfaces

## 5.1 Notes on the structure of requirements

**IMPORTANT:** Not all requirements are necessary for all products. The mapping tables at the end of each requirement shows which risk factors and use cases determine which requirements are necessary for the product. See Annex C for more information.

**IMPORTANT:** Not all requirements are necessary for all products. The mapping tables at the end of each requirement shows which risk factors and use cases determine which requirements are necessary for the product.

**See Annex C for more information.**

The most important quality of a technical requirement is that it should ideally be objectively testable on an instance of the product. If it can't be tested on the product itself, it is a documentation requirement, in which the manufacturer proves that it meets the requirement by collecting documentation of the steps they took to implement the requirement (such as configuration files or written policies used by employees).

### 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 risk factors and/or a use case. See Annex C for more information.

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 risk factors and/or a use case.

**See Annex C for more information.**

### 5.2.X **TR-NKEV**: No known exploitable vulnerabilities at first use

The product shall implement appropriate mitigations for memory errors.

> FIXME: Currently copied from the operating systems standard, need a plan to synchronize.

#### 5.2.X.x Default Preparation, Verdict, and Evidence

Most memory safety mitigations have the same Verdict and Evidence:

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

| all              | VULH                 |

### 5.2.X Additional requirements

> TODO: Look at the [notes.md](notes.md) document for ideas for requirements to write.

## 5.3 Risk Mitigation Sets

### 5.3.1 Introduction

# 6 Conformity Assessment

> TODO: Split out assessment from clause 5 requirements and put them here when required. For now, they are adjacent to the requirement they are assessing, which is far easier to read, write, and understand.

> TODO: Split out assessment from clause 5 requirements and put them here if ETSI requires this. For now, they are adjacent to the requirement they are assessing, which is far easier to read, write, and understand.

# Annex A (informative): Mapping between the present document and CRA requirements

# Annex B (informative): Relationship between the present document and any related ETSI standards (if any)

> List any related ETSI standards and how they interact with the present document.

ETSI TS 103 732 "Consumer Mobile Device Protection Profile" provided some terms and definitions.

# Annex C (informative): Risk identification and assessment methodology