EditHelp change suggestions copied over from OS

![~~CAPTION~~](media/etsi-coverpage-logo.png)

**Draft ETSI EN 304-621a V0.0.5 (2025-10)**

**Draft ETSI EN 304-621a V0.0.7 (2025-10)**

<br />

<br />

# Introduction

This document is a European harmonised standard that defines cybersecurity requirements for products whose primary purpose is as a network management system. Demonstrating compliance with this standard is not necessary, but doing so provides a presumption of conformity with Regulation (EU) 2024/2847, the Cyber Resilience Act  [\[i.1\]](#_ref_i.1).

This document is a European harmonised standard that defines cybersecurity requirements for products whose primary purpose is as a network management system. 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  [\[i.1\]](#_ref_i.1).

# 1 Scope

> NOTE: This section is a technical definition outside of the standards context. The definition will be later replaced with references to the official documentation when the work is done and approved.

Products in scope include products whose core purpose is to serve as a network management systems intended to manage the network devices.

This standard applies to Network management systems Products with digital elements that manage IP-connected network elements, such as servers, routers, switches, workstations, printers or mobile devices, by tracking them and controlling their network configuration.

The present document applies to Network management systems Products with digital elements that manage IP-connected network elements, such as servers, routers, switches, workstations, printers or mobile devices, by tracking them and controlling their network configuration.

This category includes but is not limited to end-to-end management systems and dedicated configuration management systems, such as controllers for software-defined networking.

-   Routers, modems and switches as covered by EN 304 627

-   OS used to manage the NMS

This standard does not cover products in use in contexts other than those identified in Annex <L>.

The present document does not cover products in use in contexts other than those identified in Annex <L>.

# 2 References

- <span id="_ref_i.7"></span><a name="_ref_i.7">[i.7]</a> ETSI EN 304 622 \"Essential cybersecurity requirements for Security information and event management (SIEM) systems\"

- <span id="_ref_i.8"></span><a name="_ref_i.8">[i.8]</a> ETSI EN 304 627 \"Router, modems and switches\"

- <span id="_ref_i.9"></span><a name="_ref_i.9">[i.9]</a> ETSI EN 304 642 \"Cybersecurity Requirements for Telecommunication Systems\"

- <span id="_ref_i.10"></span><a name="_ref_i.10">[i.10]</a> [Mitre ATT&CK framework]

- <span id="_ref_i.10"></span><a name="_ref_i.10">[i.10]</a> [Mitre ATT&CK] framework

[Mitre ATT&CK framework]: (https://attack.mitre.org)

[Mitre ATT&CK]: (https://attack.mitre.org)

# 3 Definition of terms, symbols and abbreviations

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

1. **Operating System (OS):** 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.

1. **Identity Provider (IDP):** System that creates, maintains and manages identity information for principals like natural humans. Providers authentication services.

1. **Service Requesting Users (<span name="_term_.SRU">SRU</span>):** These users rely on the correct functioning of the NEs that are controlled and maintained from the NMS. SRUs do not care about the connected NEs and have no interface to login to the NMS. SRUs can be both, humans or devices and all are dependent to the connected NEs. The number of NE-connected SRUs can vary from a single person up to thousands per NE device, and is in principle not limited. For clarification of the risk factors, and as regulators define the criticality of a facility operation by the number of affected SRUs for the case a NE ceased its service, its relevant for the present document.

1. **User:** This is the person having the credentials to login to the NMS to operate administrative actions to control and maintain the NE.

1. **Machine User:** A virtual user used to access the system programming interfaces. Often attached with a role based access that is tailored for the need.

1. **Component:** software or hardware intended for integration into an electronic information system

1. **Application Programming Interface (API):** A specification of routines, data structures, object classes, and variables that allows an application to make use of services provided by another software component, such as a library. APIs are often provided for a set of libraries included with the platform.

1. **Operating System (OS):** software product that provides an abstract interface to the underlying hardware and control the execution of software

1. **Identity Provider (IDP):** system maintaining identity information

1. **Service Requesting Users (<span name="_term_.SRU">SRU</span>):** users relying on the correct functioning of the network element

1. **user:** person having the credentials to login to the NMS to operate administrative actions to control and maintain the NE

1. **machine user:** virtual user used to access the system programming interfaces

1. **component:** software or hardware intended for integration into an electronic information system

1. **Application Programming Interface (API):** interface used to communicate with the running program

## 3.2 Abbreviations

`OS     Operating System`  

`IDP    Identity Provider`  

`VPN    Virtual Private Network`  

`SIEM   Security Information and Event Management systems`  

`SIEM   Security Information and Event Management Systems`  

`NMS    Network Management System`  

`2FA    Two Factor Authentication`  

`CSP    Communication System Provider`  

`SDN    Software Defined Networks`  

`GUI    Graphical User Interface`  

`NE     One or more connected Network Elements`  

`MDM    Mobile Device Management system`  

`NE     Network Element`  

`MDM    Mobile Device Management`  

# 4 Product context

## 4.2 Out of scope use/environments

The types of products with digital elements listed in this subsection do not fall within the scope of Regulation (EU) 2024/2847 (Cyber Resilience Act), and are not covered by this standard:

The types of products with digital elements listed in this subsection do not fall within the scope of Regulation (EU) 2024/2847 (Cyber Resilience Act), 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  [\[i.1\]](#_ref_i.1);

2. Products specifically designed or procured for national security and defence purposes as defined in CRA recitals 14 and 26; article 2, 7-8  [\[i.1\]](#_ref_i.1);

7. Spare and used parts as defined in CRA recital 29; article 2, 6  [\[i.1\]](#_ref_i.1);

8. Refurbished, repaired, and upgraded products that have not been substantially modified as defined in recitals 39 - 42  [\[i.1\]](#_ref_i.1);

The following types of products have reduced or varied requirements under Regulation (EU) 2024/2847 (Cyber Resilience Act)  [\[i.1\]](#_ref_i.1) and can only be partially covered by this standard:

The following types of products have reduced or varied requirements under Regulation (EU) 2024/2847 (Cyber Resilience Act)  [\[i.1\]](#_ref_i.1) and can only be partially covered by the present document:

9. High Risk AI as defined in CRA recital 51; article 12  [\[i.1\]](#_ref_i.1);

10. Testing and unfinished versions as defined in recital 37; Article 4, 2-3  [\[i.1\]](#_ref_i.1);

Being in scope as written in the technical definition [1.2 Products in scope](#12-products-in-scope) assumes that the NMS controls the device configuration at least partially. The same definition outlines, that NMS is a system with connected elements like routers, hense NMS is an aggregate product.

Aggregate product can have components, like an OS and networking interfaces, which are evaluated outside of the scope of this standard.

Aggregate product can have components, like an OS and networking interfaces, which are evaluated outside of the scope of the present document.

More boundaries are listed in the [C3 Assumptions](#c3-assumptions).

Manufacturers shall be responsible for implementing all security measures, regardless of the subcomponents in use.

## 5.1 General

The following are non-technical requirements, that shall be implemented by all products with digital elements evaluated with this standard.

The following are non-technical requirements, that shall be implemented by all products with digital elements evaluated with the present document.

-   **[REQ-GEN-0]:** Manufacturer shall declare in the technical documentation with what [Risk factors](#45-risk-factors) the product with digital elements shall be evaluated.

-   **[REQ-GEN-1]:** Manufacturer shall provide in the technical documentation a detailed enough systems architecture design description, that enables national bodies like MSA to evaluate and test the product design.

Network segmentation is encouraged to be used where applicapble. The best practise is to use dedicated network segment for network management traffic.

Management traffic can be configuration updates, encryption keys, software updates, and others alike.

Regardless of what connectivity structure manufacturer implements in the NMS design from [ACC-L-0] to [ACC-L-3], manufacturer shall implement mitigations described in the following section [Risk Mitigations](#53-risk-mitigations).

Regardless of what connectivity structure manufacturer implements in the design, manufacturer shall implement mitigations described in the following section [Risk Mitigations](#53-risk-mitigations).

ZeroTrust routing is also encouraged where applicable.

> This section shall have:

>

> -   How the NMS shall verify the authensity and integrity of the incoming data

> -   How the system shall verify the authensity and integrity of the incoming data

> -   What is expected to happen, if discrepencies are found

-   **[REQ-INGEST-0]** The manufacturer shall protect the system against data poisoning or other adversial attacks.