Apply accepted comments from public enquiry

# Executive summary

# Introduction

The present document is a European harmonised standard that defines cybersecurity requirements for products whose core function is as an virtual or physical network interface. Demonstrating compliance with the present document is not necessary, but doing so provides a presumption of conformity with Regulation (EU) 2024/2847, the Cyber Resilience Act <a href="#_ref_i.1">[i.1]</a>.

The present document does not apply to products that contain network interfaces or are part of a network interface if the core functionality of the product is not that of a network interface. However, it may be useful as one part of the process of demonstrating compliance for a product containing or interacting with network interfaces.

# How to understand a vertical standard

**PLEASE READ THIS SECTION BEFORE COMMENTING**

The present document is a vertical standard for the Cyber Resilience Act. This is a new kind of standard with some unusual properties. Read the rest of this section to understand how it works.

## TL;DR

The manufacturer defines an intended purpose or use case for their product. This use case determines how the essential cybersecurity requirements of the CRA can be satisified.

The vertical standard is only one way of assessing CRA conformance. Others methods are available if the product uses incompatible methods of CRA conformance.

Clauses 1 - 4 are not binding, just helpful context. Clauses 5 sets out the requirements necesssary to conform with the CRA. Clause 6 sets out how to assess the conformance of the product with the CRA.

Each technical requirement can be satisfied by one or more mitigations describing the default behavior of the product. The user may configure the product differently unless explicitly forbidden in the text of the requirement. Which mitigations are required depend on risk factors specific to each use case, and capabilities of the product. The tables at the end of each requirement show which mitigations are required.

Security profiles are groups of use cases that can be satisfied with the same mitigations. A product must fit into a security profile to use the vertical standard for CRA conformance. If a security profile includes mitigations that are sufficient to treat all of a product's cybersecurity risks, then the product may be assessed using the vertical standard.

## Standard basics

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

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.

### Requirements describe default configuration only

The requirements describe the default configuration of the product. It is implied that the product can be configured to behave in a different way, unless the requirement explicitly states that the product may not permit such an option. For example, if a requirement says a debug interface must be disabled, then the product may have an option to enable the debug interface. Only if the requirement says a debug interface must be _permanently_ disabled would it be not allowed to have an option to enable it.

## CRA vertical standard specifics

### Vertical standards are optional

Using a CRA vertical standard to assess conformance with the CRA is optional. A product may be assessed for conformance using a variety of other options as outlined in the CRA. If the vertical standard does not fit a specific product, then the assessor has many other options for assessment.

However, there are two advantages to using a vertical standard: (1) it allows self-assessment of Important Class II products, (2) it provides presumption of conformity. Note that all products consistently entirely of free and open source software as defined by the CRA can always self-assess, with or without a vertical standard.

### Manufacturer declares intended purpose/use case

For the purposes of the CRA, the manufacture declares an intended purpose and reasonablity foreseeable use and misuse for a product. This allows the manufacturer to do a risk assessment that is specific to a particular use case.

### Intended purpose/use case and capabilities determines how to satisfy requirements

A vertical standard includes a set of cybersecurity requirements and ways to satisfy them. The ways to satisfy them are **dependent on the use case and capabilities** of a product.

### Each requirement can be satisified by one or more mitigations

Each requirement is associated with a set of mitigations that reduce the cybersecurity risk of the product. Which mitigations are required to be implemented depend on the intended purpose/use case.

### Risk factors determine which mitigations are necessary

Each vertical standard defines a set of risk factors. The values of these risk factors are determined by the use case and/or the capabilities of the product. Which mitigations are necessary are determined by a combination of risk factors and capabilities. Each requirement ends with a table showing which mitigations are required, based on risk factors and capabilities.

### Use cases are grouped into security profiles

Security profiles are use cases grouped together by compatible mitigations. Each security profile describes a set of mitigations which can be used to satisfy the CRA essential requirements for any use case that is part of the security profile.

### Vertical standards may only be used for security profiles in the standard

Use cases whose risks are not addressed by the vertical standard may not use the vertical standard for conformance assessment.

### New use cases and security profiles may be contributed

New use cases and security profiles may be developed using existing or new risk assessments, risk factors, and mitigations. It is in the manufacturer's interest to contribute the risk assessment and mitigations for their use case to the vertical standard, as they may then get the benefits of conformance via a CRA vertical standard for their product.

### Manufacturer may use any CRA-conformant risk assessment methodology

The risk assessment section of a vertical standard is informative only. It exists to demonstrate that the standards writers have undertaken a risk assessment of the product. The manufacturer is explicitly permitted to use any risk assessment methodology consistent with the requirements in the CRA.

**Before commenting, please read Annex E for an informative explanation of the use and function of the present document.**

# 1 Scope

## 1.1 General

The present document describes how to demonstrate the compliance of virtual and physical network interfaces with the requirements in the EU Regulation 2024/2847, within the context described in clause 4, Product Context.

The present document specifies security requirements and related assessment criteria for physical and virtual network interfaces.

## 1.2 Products in scope

Physical network interfaces are connected to a host system by a communications bus, such as PCIe or USB. Virtual network interfaces are software running on the host system, and communicate via the device driver interface.

This category includes but is not limited to wired and wireless network interface cards, controllers and adapters, such as for Wi-Fi, Ethernet, IrDA, USB, Bluetooth, NearLink, Zigbee, Fieldbus, or Infiniband.

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:

Products not in scope include:

* Products whose primary purpose is not that of a network interface

* **Products whose primary purpose is not that of a network interface**

* Switches, routers, and standalone modems

* Cables connected to network interfaces

* Software or hardware add-ons, changes, or upgrades not shipped by the manufacturer that substantially modify the product

## 4.7 Use cases

_The following use cases are provided to assist manufacturers in selecting risk factors and security levels. This is not intended to be an exhaustive or complete list of all possible use cases._

The following use cases are provided to assist manufacturers in selecting risk factors and security levels. This is not intended to be an exhaustive or complete list of all possible use cases.

The examples given in each use case are for a finished product that includes the network interface rather than the network interface itself. They are not examples of a product whose core purpose is as a network interface.

### 4.7.1 Wired network interface use cases

Type: Affects likelihood of all attacks.

  * **[COM-L-0]** Product implements minimal features necessary to send/recv packets

  * **[COM-L-1]** Product implements some simple performance features

  * **[COM-L-2]** Product implements encryption functions, RTOS managing radio, PXE boot, remote management, etc.

  * **[COM-L-0]** Product implements minimal features necessary to send/recv packets but not the features in COM-L-1 or COM-L-2

  * **[COM-L-1]** Product implements features such as simple performance improvements which are more complex than COM-L-0 but less complex than those in COM-L-2

  * **[COM-L-2]** Product implements complex features such as encryption functions, RTOS managing radio, PXE boot, remote management, etc.

**[LIS]** Ease of reading from transmission media of directly attached network by unauthorized agents

> Describe how to treat any residual risks, for example by documenting them or informing the user.

# Annex E (informative): Change history

# Annex E: Explanation of the present document (informative only)

## E.1 Introduction

This is a short introduction to how standareds work, how CRA vertical standards work in general, and how this standard specifically works.

## E.2 How to understand a vertical standard

### E.2.1 General

The present document is a vertical standard for the Cyber Resilience Act. This is a new kind of standard with some unusual properties. Read the rest of this section to understand how it works.

### E.2.2 TL;DR

The manufacturer defines an intended purpose or use case for their product. This use case determines how the essential cybersecurity requirements of the CRA can be satisified.

The vertical standard is only one way of assessing CRA conformance. Others methods are available if the product uses incompatible methods of CRA conformance.

Clauses 1 - 4 are not binding, just helpful context. Clauses 5 sets out the requirements necesssary to conform with the CRA. Clause 6 sets out how to assess the conformance of the product with the CRA.

Each technical requirement can be satisfied by one or more mitigations describing the default behavior of the product. The user may configure the product differently unless explicitly forbidden in the text of the requirement. Which mitigations are required depend on risk factors specific to each use case, and capabilities of the product. The tables at the end of each requirement show which mitigations are required.

Security profiles are groups of use cases that can be satisfied with the same mitigations. A product must fit into a security profile to use the vertical standard for CRA conformance. If a security profile includes mitigations that are sufficient to treat all of a product's cybersecurity risks, then the product may be assessed using the vertical standard.

## E.3 Standard basics

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

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.

### E.3.2 Requirements describe default configuration only

The requirements describe the default configuration of the product. It is implied that the product can be configured to behave in a different way, unless the requirement explicitly states that the product may not permit such an option. For example, if a requirement says a debug interface must be disabled, then the product may have an option to enable the debug interface. Only if the requirement says a debug interface must be _permanently_ disabled would it be not allowed to have an option to enable it.

## E.4 CRA vertical standard specifics

### E.4.1 Vertical standards are optional

Using a CRA vertical standard to assess conformance with the CRA is optional. A product may be assessed for conformance using a variety of other options as outlined in the CRA. If the vertical standard does not fit a specific product, then the assessor has many other options for assessment.

However, there are two advantages to using a vertical standard: (1) it allows self-assessment of Important Class II products, (2) it provides presumption of conformity. Note that all products consistently entirely of free and open source software as defined by the CRA can always self-assess, with or without a vertical standard.

### E.4.2 Manufacturer declares intended purpose/use case

For the purposes of the CRA, the manufacture declares an intended purpose and reasonablity foreseeable use and misuse for a product. This allows the manufacturer to do a risk assessment that is specific to a particular use case.

### E.4.3 Intended purpose/use case and capabilities determines how to satisfy requirements

A vertical standard includes a set of cybersecurity requirements and ways to satisfy them. The ways to satisfy them are **dependent on the use case and capabilities** of a product.

### E.4.4 Each requirement can be satisified by one or more mitigations

Each requirement is associated with a set of mitigations that reduce the cybersecurity risk of the product. Which mitigations are required to be implemented depend on the intended purpose/use case.

### E.4.5 Risk factors determine which mitigations are necessary

Each vertical standard defines a set of risk factors. The values of these risk factors are determined by the use case and/or the capabilities of the product. Which mitigations are necessary are determined by a combination of risk factors and capabilities. Each requirement ends with a table showing which mitigations are required, based on risk factors and capabilities.

### E.4.6 Use cases are grouped into security profiles

Security profiles are use cases grouped together by compatible mitigations. Each security profile describes a set of mitigations which can be used to satisfy the CRA essential requirements for any use case that is part of the security profile.

### E.4.7 Vertical standards may only be used for security profiles in the standard

Use cases whose risks are not addressed by the vertical standard may not use the vertical standard for conformance assessment.

### E.4.8 New use cases and security profiles may be contributed

New use cases and security profiles may be developed using existing or new risk assessments, risk factors, and mitigations. It is in the manufacturer's interest to contribute the risk assessment and mitigations for their use case to the vertical standard, as they may then get the benefits of conformance via a CRA vertical standard for their product.

### E.4.9 Manufacturer may use any CRA-conformant risk assessment methodology

The risk assessment section of a vertical standard is informative only. It exists to demonstrate that the standards writers have undertaken a risk assessment of the product. The manufacturer is explicitly permitted to use any risk assessment methodology consistent with the requirements in the CRA.

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