Some editorials

# HARMONISED EUROPEAN STANDARD

**Draft ETSI EN 304 625 V0.0.11**

**Draft ETSI EN 304 626 V0.0.11**

<br />

<br />

</div>

# Contents

=======

---

Title: CRA;<br>Essential cybersecurity requirements for physical and virtual network interfaces

Spec Number: 304 626

Version: v0.0.11

Date: 2025-12

Work Item: TC/WI-Number

keywords: CRA

Copyright Year: 2025

---

# Intellectual Property Rights

## Essential patents

Essential patents

IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations pertaining to these essential IPRs, if any, are publicly available for **ETSI members and non-members** , and can be found in ETSI SR 000 314: _"Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards"_ , which is available from the ETSI Secretariat. Latest updates are available on the [ETSI IPR online database].

IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations pertaining to these essential IPRs, if any, are publicly available for **ETSI members and non-members** , and can be found in ETSI SR 000 314: _\"Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards\"_ , which is available from the ETSI Secretariat. Latest updates are available on the [ETSI IPR online database].

Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.

[ETSI IPR online database]: https://ipr.etsi.org/

## Trademarks

Trademarks

The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners. ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.

# Modal verbs terminology

In the present document "**shall** ", "**shall not** ", "**should** ", "**should not** ", "**may** ", "**need not** ", "**will** ", "**will not** ", "**can** " and "**cannot** are to be interpreted as described in clause 3.2 of the [ETSI Drafting Rules] (Verbal forms for the expression of provisions).

In the present document \"**shall**\", \"**shall not**\", \"**should** \", \"**should not**\", \"**may**\", \"**need not**\", "**will**\", \"**will not**\", \"**can**\" and \"**cannot**\" are to be interpreted as described in clause 3.2 of the [ETSI Drafting Rules] (Verbal forms for the expression of provisions).

"**must** " and "**must not** " are **NOT** allowed in ETSI deliverables except when used in direct citation.

\"**must**\" and \"**must not**\" are **NOT** allowed in ETSI deliverables except when used in direct citation.

[ETSI Drafting Rules]: https://portal.etsi.org/Services/editHelp/How-to-start/ETSI-Drafting-Rules

This category is composed of wired and wireless network interface cards, controllers and adapters, and network interface hardware modules, such as for Wi-Fi, Ethernet, cellular modems, IrDA, USB, Bluetooth, NearLink, Zigbee, Fieldbus, or Infiniband.

The term "modem" is used for two different kinds of products:

The term \"modem\" is used for two different kinds of products:

1. "Modem interface": a single network interface that connects a physical transmission adapter to a system bus, as for example a 5G modem interface or Power Line Communication device

1. \"Modem interface\": a single network interface that connects a physical transmission adapter to a system bus, as for example a 5G modem interface or Power Line Communication device

1. "Standalone modem": A device with two or more network interfaces that routes network data between two different networks, relaying data from one type of physical transmission media to another, such as a cable modem

1. \"Standalone modem\": A device with two or more network interfaces that routes network data between two different networks, relaying data from one type of physical transmission media to another, such as a cable modem

"Modem interfaces" are included in the present document. "Standalone modems" are excluded from the present document.

\"Modem interfaces\" are included in the present document. \"Standalone modems\" are excluded from the present document.

This category includes purely virtual standalone products, such as virtual network interfaces, container network interfaces, VPN interfaces, and loopback interfaces.

The following referenced documents are necessary for the application of the present document.

- <a name="_ref_1">[1]</a> prEN 40000-1-1: “Cybersecurity requirements for products with digital elements – Vocabulary”</a>

<span id="_ref_1"></span><a name="_ref_1">[1]</a> prEN 40000-1-1: “Cybersecurity requirements for products with digital elements – Vocabulary”</a>

- <a name="_ref_2">[2] prEN 40000-1-2: “Cybersecurity requirements for products with digital elements - Part 1-2: Principles for cyber resilience”</a>

<span id="_ref_2"></span><a name="_ref_2">[2] prEN 40000-1-2: “Cybersecurity requirements for products with digital elements - Part 1-2: Principles for cyber resilience”</a>

- <a name="_ref_3">[3] prEN 40000-1-3: “Cybersecurity requirements for products with digital elements – Vulnerability Handling”</a>

<span id="_ref_3"></span><a name="_ref_3">[3] prEN 40000-1-3: “Cybersecurity requirements for products with digital elements – Vulnerability Handling”</a>

## 2.2 Informative references

References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

* <a name="_ref_i.1">[i.1]</a>    Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)

<span id="_ref_i.1"></span><a name="_ref_i.1">[i.1]</a> Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)

* <a name="_ref_i.2">[i.2]</a>    EN 18031-1 (2024): "Common security requirements for radio equipment - Part 1: Internet connected radio equipment".

<span id="_ref_i.2"></span><a name="_ref_i.2">[i.2]</a> EN 18031-1 (2024): \"Common security requirements for radio equipment - Part 1: Internet connected radio equipment\".

* <a name="_ref_i.3">[i.3]</a>    EN 18031-2 (2024): "Common security requirements for radio equipment - Part 2: radio equipment processing data, namely Internet connected radio equipment, childcare radio equipment, toys radio equipment and wearable radio equipment".

<span id="_ref_i.3"></span><a name="_ref_i.3">[i.3]</a> EN 18031-2 (2024): \"Common security requirements for radio equipment - Part 2: radio equipment processing data, namely Internet connected radio equipment, childcare radio equipment, toys radio equipment and wearable radio equipment\".

* <a name="_ref_i.4">[i.4]</a>    EN 18031-3 (2024): "Common security requirements for radio equipment - Part 3: Internet connected radio equipment processing virtual money or monetary value".

<span id="_ref_i.4"></span><a name="_ref_i.4">[i.4]</a> EN 18031-3 (2024): \"Common security requirements for radio equipment - Part 3: Internet connected radio equipment processing virtual money or monetary value\".

* <a name="_ref_i.5">[i.5]</a>    C(2025)618 – Standardisation request M/606: Commission Implementing decision of 3.2.2025 on a standardisation request to the European Committee for Standardisation (CEN), the European Committee for Electrotechnical Standardisation (Cenelec) and the European Telecommunications Standards Institute (ETSI) as regards products with digital elements in support of Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act).

<span id="_ref_i.5"></span><a name="_ref_i.5">[i.5]</a> C(2025)618 – Standardisation request M/606: Commission Implementing decision of 3.2.2025 on a standardisation request to the European Committee for Standardisation (CEN), the European Committee for Electrotechnical Standardisation (Cenelec) and the European Telecommunications Standards Institute (ETSI) as regards products with digital elements in support of Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act).

* <a name="_ref_i.6">[i.6]</a>    CEN/CLC JTC13: "Cybersecurity and Data Protection".

<span id="_ref_i.6"></span><a name="_ref_i.6">[i.6]</a> CEN/CLC JTC13: \"Cybersecurity and Data Protection\".

* <a name="_ref_i.7">[i.7]</a>    ETSI TS 103 732 "Consumer Mobile Device Protection Profile".

<span id="_ref_i.7"></span><a name="_ref_i.7">[i.7]</a> ETSI TS 103 732 \"Consumer Mobile Device Protection Profile\".

# 3 Definition of terms, symbols and abbreviations

## 3.1 Terms

This clause provides terms and definitions based on CEN/CLC JTC13 WG09's <a href="#_ref_i.6">[i.6]</a> work on terms and definitions, terms and definitions provided by ETSI EN 303 645/TS 103 701 <a href="#_ref_i.7">[i.7]</a> and by CEN/CLC EN 18031 <a href="#_ref_i.2">[i.2]</a> series.

This clause provides terms and definitions based on CEN/CLC JTC13 WG09's [\[i.6\]](#_ref_i.6) work on terms and definitions, terms and definitions provided by ETSI EN 303 645/TS 103 701 [\[i.7\]](#_ref_i.7) and by CEN/CLC EN 18031 [\[i.2\]](#_ref_i.2) series.

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

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

| Abbreviation | Description                              |

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

| API          | Application Programming Interface        |

| ISP          | Internet Service Provider                |

| IT           | Information Technology                   |

| NI           | Network Interface                        |

| NDDI         | Network Device Driver Interface          |

| OS           | Operating System                         |

| VNI          | Virtual Network Interface                |

`API    Application Programming Interface`  

`ISP   Internet Service Provider`  

`IT    Information Technology`  

`NI    Network Interface`  

`NDDI  Network Device Driver Interface`  

`OS    Operating System`  

`VNI   Virtual Network Interface`  

# 4 Product context

A physical network interface connects via a communications bus to the host. The host transmits to and receives data from the network by means of a device driver interface provided by the device driver for the network interface. A physical network interface might read and write the host memory directly and raise interrupts. It sometimes has more advanced features that allow it to power cycle the entire system, download files using simple protocols, and act as a simple boot loader.

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

![Figure 4.3.2-1: Physical network device architecture](media/physical_network_interface.drawio.png)

**Figure 4.3.2-1: Physical network device architecture**

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.

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.

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

![**Figure 4.3.2-2: Virtual network device architecture**](media/virtual_network_interface.drawio.png)

**Figure 4.3.2-2: Virtual network device architecture**

### 4.3.3 Device drivers for network interfaces

The CRA requires the manufacturer to keep all the documentation necessary to show that the tests were conducted. In addition, the CRA explicitly grants the MSA the following rights in Article 13 Rec. 22:

> "Manufacturers shall, upon a reasoned request from a market surveillance authority, provide that authority, in a language which can be easily understood by that authority, with 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. Manufacturers shall cooperate with that authority, at its request, on any measures taken to eliminate the cybersecurity risks posed by the product with digital elements which they have placed on the market."

> \"Manufacturers shall, upon a reasoned request from a market surveillance authority, provide that authority, in a language which can be easily understood by that authority, with 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. Manufacturers shall cooperate with that authority, at its request, on any measures taken to eliminate the cybersecurity risks posed by the product with digital elements which they have placed on the market.\"

The goal is that when the MSA does a “sweep” or otherwise decides to verify a product’s conformance with the CRA, it has enough information that it can do its own independent testing without unnecessary barriers that could be solved by vendor documentation (e.g., does not have to reverse-engineer how to attach a serial console and read logs). Note that it is easer for an MSA to evaluate conformance via transparency - reviewing the test output and documentation to evaluate whether a mitigation is implemented - over actually testing the product themselves.

#### 5.2.1.4 MI-KEVM: Documentation of mitigation of known exploitable vulnerabilities

The product's development and release process shall include a process to document known exploitable vulnerabilities in the product and their fixes or mitigations. The documentation for this process shall be compliant with the process described in <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling". The product shall be compliant with this requirement if it:

The product's development and release process shall include a process to document known exploitable vulnerabilities in the product and their fixes or mitigations. The documentation for this process shall be compliant with the process described in [\[3\]](#_ref_3) prEN 40000-1-3: \"Cybersecurity requirements for products with digital elements – Vulnerability Handling\". The product shall be compliant with this requirement if it:

1. has no known exploitable vulnerabilities

1. has known exploitable vulnerabilities whose age is consistent with the specification of how long vulnerabilities may go unfixed after public disclosure, as described in the vulnerability handling procedure for the product

#### 5.2.18.1 Requirement

The product shall have vulnerability handling processes compliant with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling".

The product shall have vulnerability handling processes compliant with [\[3\]](#_ref_3) prEN 40000-1-3: \"Cybersecurity requirements for products with digital elements – Vulnerability Handling\".

#### 5.2.18.2 MI-VULH: Vulnerability handling

The product shall have vulnerability handling processes compliant with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling".

The product shall have vulnerability handling processes compliant with [\[3\]](#_ref_3) prEN 40000-1-3: \"Cybersecurity requirements for products with digital elements – Vulnerability Handling\".

  * Applicability: (for requirements that depend on a feature)

  * Reference: TR-VULH

  * Objective: Vulnerability handling

  * Activities: Review documentation associated with vulnerability handling.

  * Verdict: Vulnerability handling documentation is compliant with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling" => PASS, otherwise FAIL

  * Evidence: Vulnerability handling documentation, comparison with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling"

  * Verdict: Vulnerability handling documentation is compliant with [\[3\]](#_ref_3) prEN 40000-1-3: \"Cybersecurity requirements for products with digital elements – Vulnerability Handling\" => PASS, otherwise FAIL

  * Evidence: Vulnerability handling documentation, comparison with [\[3\]](#_ref_3) prEN 40000-1-3: \"Cybersecurity requirements for products with digital elements – Vulnerability Handling\"

## 5.3 Risk Mitigation Sets

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

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

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

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

Attacker may use unauthorized access to the product through the network to harm the host system.

_Note: If the attacker has physical or host system software access, they don't need to use the network device to harm the system._

> NOTE: If the attacker has physical or host system software access, they don't need to use the network device to harm the system.

| Risk factors                  | Likelihood | Security profiles |

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

### E.3.1 Normative and informative text

Standards consist of two kinds of text: informative and normative. Informative text is just "for your information": it is helpful for understanding the standard but it has no legally binding meaning. Normative text describes things that matter for conforming for the standard.

Standards consist of two kinds of text: informative and normative. Informative text is just \"for your information\": it is helpful for understanding the standard but it has no legally binding meaning. Normative text describes things that matter for conforming for the standard.

This vertical standard has only two normative clauses: Clause 5 Requirements and Clause 6 Assessment criteria. Everything else is just to help the reader understand the normative parts of the document. That means if something in clauses 1 - 4 or the Annexes isn't exactly correct, that doesn't affect the way you can use the standard.

# Annex F (informative): Change history

The "Change history/Change request (history)" annex shall be included in every revised or amended harmonised standard and shall contain information concerning significant changes that have been introduced by it. It shall be presented as a table.

The \"Change history/Change request (history)\" annex shall be included in every revised or amended harmonised standard and shall contain information concerning significant changes that have been introduced by it. It shall be presented as a table.

| Date            | Version | Information about changes                 |

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