Structural changes

<div align="center">

![~~ETSI Standard header image~~](media/etsi_coverpage-logo.png)

# HARMONISED EUROPEAN STANDARD

**ETSI EN 304-621 V0.0.1 (2025-08)**

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

<br />

<br />

<br />

<br />

Title;<br />

</div>

<br />

<br />

<br />

<br />

> Should you need a step-by-step guide for drafting an ETSI deliverable, please consult the "_ [Principles for Drafting ETSI Deliverables](https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/Principles_for_drafting_ETSI_deliverables.pdf)_" document. Otherwise you may contact us at\_ [edithelp@etsi.org ](mailto:edithelp@etsi.org).

> Should you need a step-by-step guide for drafting an ETSI deliverable, please consult the " [Principles for Drafting ETSI Deliverables](https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/Principles_for_drafting_ETSI_deliverables.pdf)" document. Otherwise you may contact us at [edithelp@etsi.org](mailto:edithelp@etsi.org).

<br />

<br />

<br />

<div align="center">

Reference<br />

&lt;Workitem><br />

Keywords<br />

&lt;keywords><br />

ETSI<br />

650 Route des Lucioles<br />

F-06921 Sophia Antipolis Cedex - FRANCE<br />

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16<br />

Siret N° 348 623 562 00017 - APE 7112B<br />

Association à but non lucratif enregistrée à la<br />

Sous-préfecture de Grasse (06) N° w061004871<br />

</div>

<br />

# Contents

<br />

# Intellectual Property Rights

# Foreword

> DRAFT FOREWORD - DO NOT CONSIDER THE CONTENT Should be written as a last item.

> DRAFT FOREWORD - DO NOT CONSIDER THE CONTENT

This draft Harmonised European Standard (EN) has been produced by ETSI Technical Committee Cyber Working Group for EUSR (CYBER-EUSR), and is now submitted for the combined Public Enquiry and Vote phase of the ETSI Standardisation Request deliverable Approval Procedure (SRdAP).

# Modal verbs terminology

In the present document "**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](https://portal.etsi.org/Services/editHelp/How-to-start/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](https://portal.etsi.org/Services/editHelp/How-to-start/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.

# Introduction

The present document is a European harmonised standard that defines cybersecurity requirements for products whose primary purpose is 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.

> A brief summary of the document to help the manufacturer figure out if they need to keep reading or if they should move on to a different document.

<br />

The present document is a European harmonised standard that defines cybersecurity requirements for products whose primary purpose is 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.

# 1 Scope

# 1.2 Products in scope

> Detailed list of things that are in scope, to help manufacturers identify in-scope products. Make the scope as narrow as possible while still covering all products in the vertical. Use the latest draft of the technical descriptions to help. Technical experts are considered to be the authority for interpreting the meaning and definition of technical terms, so use your best technical judgement.

This standard applies to Network Management Systems that manage 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.

<mark>FIXME: Link to technical definitions doc</mark>

> Detailed list of things whose scope might be confusing, including parts of a system which are often included when the terms in the "in scope" section are used in general conversation. Reference the "Product Context" section again to remind the reader what operational environments are in scope.

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

# 2 References

## 2.1 Normative references

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

>

> Referenced documents which are not found to be publicly available in the expected location might be found in the [ETSI docbox](https://docbox.etsi.org/Reference/).

>

> NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long-term validity.

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

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**:

<mark>FIXME actually define these</mark>

## 3.2 Abbreviations

For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:

| OS           | Operating System  |

| IDP          | Identity Provider |

<mark>FIXME add more abbreviations</mark>

# 4 Product context

## 4.1 General

## 4.2 Out of scope use/environments

> List uses/environments covered by other legislation or standards (critical, industrial, medical, etc.). Hoping to have a reusable generic list of these soon.

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

1. Services, except for the remote data processing solutions for a covered product as defined in CRA recitals 11-12; article 3, 2 <a name="_ref_i.1">[i.1]</a>;

10. Testing and unfinished versions as defined in recital 37; Article 4, 2-3 <a name="_ref_i.1">[i.1]</a>;

11. Products Placed on the Market Prior to December 11, 2027 as defined in CRA article 69 <a name="_ref_i.1">[i.1]</a>.

## 4.2 Product overview and architecture

## 4.3 Product overview and architecture

> Explain the overall architecture and relationship among the parts of the products. Use diagrams if that is helpful.

The main functionality of a NMS is to interface and manage Routers and Modems.

## 4.3 Use cases

## 4.4 Use cases

> Create a list of representative use cases, each one representing a different threat profile. If the threat profile is the same for two use cases, then it is basically the same use case for the purposes of the present document. Use cases should include both intended and reasonably foreseeable use/misuse. Use cases don't include industrial operations, automotive, transport, marine, airplane, medical, military, national security, etc.

> Create a list of representative use cases, each one representing a different threat profile. If the threat profile is the same, it's basically the same use case for the purposes of this document.

> When you have many use cases, group them into 3 - 5 levels of risk. These will probably be your security levels.

Manufacturer shall delcare what risk profile it's product is meant to be evaluated at.

Manufacturer shall be responsible of implementing all security measurments regardless of what subcomponents are in use.

### 4.3.1 Low risk deployment

### 4.4.1 Low risk deployment

- Distributed element design

- Lesser importance with the device functionality and role in the deployment context

There can be multple devices in the same network, and the NMS provides supporting services like DHCP and DNS caching.

### 4.3.2 Medium risk deployment

### 4.4.2 Medium risk deployment

- Converged network design

- Often more than one installation site

![Office network](./media/2025-08-10_office.drawio.png)

### 4.3.3 High risk deployment

### 4.4.3 High risk deployment

- High number of elements

- Significant size of affected user base

| Medium          | NIS2 important       |

| High            | NIS2 critical        |

## 4.5 Essential functions

## 4.6 Essential functions

> List the essential functions of the product, including:

>

<mark>FIXME need update/monitoring/etc.</mark>

## 4.6 Operational Environment

## 4.7 Operational Environment

The technical requirements of the present document apply under the environmental profile for operation of the product with digital elements, which shall be in accordance with its intended use. The product with digital elements shall comply with all the technical requirements of the present document at all times when operating within the boundary limits of the operational environmental profile defined by its intended use.

> Describe the expected operating environment given the exclusions in Section 4.2. This includes:

>

> - Physical environment (if applicable)

> - Networks it is connected to

> - Supporting/associated devices

> - Supporting/associated software or services

> - Other relevant context

## 4.7 Users

> You may be able to use the following instructions taken from the Common Internet of Things draft:

>

> Harmonised Standards not specifying a normative environmental profile should use the following text:

> Describe the classes of users for this product, as differentiated by sophistication in understanding and taking responsibility for security risks. More sophisticated users can be expected to follow more instructions and cope with higher levels of unmitigated risks.

The technical requirements of the present document apply under the environmental profile for operation of the product with digital elements, which shall be in accordance with its intended use. The product with digital elements shall comply with all the technical requirements of the present document at all times when operating within the boundary limits of the operational environmental profile defined by its intended use.

<mark>FIXME Who uses this?</mark>

## 4.8 Users

## 4.8 Risk distribution among components

> Describe the classes of users for this product, as differentiated by sophistication in understanding and taking responsibility for security risks. More sophisticated users can be expected to follow more instructions and cope with higher levels of unmitigated risks. Suggestions:

>

> - General public

> - Children

> - Assistants to primary user

> - IT professionals

> - Systems integrators

> Risk can be transferred between components, for example a network interface can document that secure update of its firmware must be handled by an external program, such as an operating system. In turn, the operating system can offer the security functionality of secure updates to other components in a system.

## 4.9 Risk distribution among components

> Describe what risks are delegated to sub-components, as well as what risk management features this product offers to things integrating it.

> Risk can be transferred between components, for example a network interface can document that secure update of its firmware must be handled by an external program, such as an operating system. In turn, the operating system can offer the security functionality of secure updates to other components in a system.

<mark>FIXME describe what subcomponents chip-in and how</mark>

> Describe what risks are delegated to other components, as well as what security functionalities this product offers to things integrated with it.

## 4.9 Support period

## 4.10 Support period

> Describe the expected support period and its impact on security risks. Generally the support period should be at least 5 years, shorter or longer according to the expected period of use. See Article 13.8 and Recitals 59 - 62 of the CRA for more information.

<mark>FIXME What is the expected use of an NMS product? Does it vary by class and security level?</mark>

# 5 Requirements specifications

## 5.1 General

## 5.2 Technical security requirements specifications

> List technical security requirements for the product. Each requirement should be objectively verifiable on an instance of a product. Each should include an implementable method of verifying the requirement is met. Each should include a way to determine if the requirement is applicable to the product. Ideally each will include at least one concrete example of an implementation that satisfies the requirement and a test that verifies it. If the requirement allows the manufacturer to specify their own solution to the technical requirement, the requirement should include a specific way to measure the effectiveness of the risk mitigation and set a minimum level.\_

> Example technical security requirements can be found in related standards, such as:\_

> List technical security requirements for the product. Each requirement should be objectively verifiable on an instance of a product. Each should include an implementable method of verifying the requirement is met. Each should include a way to determine if the requirement is applicable to the product. Ideally each will include at least one concrete example of an implementation that satisfies the requirement and a test that verifies it. If the requirement allows the manufacturer to specify their own solution to the technical requirement, the requirement should include a specific way to measure the effectiveness of the risk mitigation and set a minimum level.

> Example technical security requirements can be found in related standards, such as:

>

> - Protection profiles for similar categories of product

> - [EN-18031-2 (Radio Equipment Directive)](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09/CEN-CLC-JTC%2013-WG%209_N433_EN%2018031%20series.zip)

> - Other vertical standards drafts in [ETSI GitLab](https://forge.etsi.org/rep/cyber/stan4cr2)

> - Other vertical standards drafts as [contributions to verticals meetings on the ETSI Portal](https://portal.etsi.org/Meetings.aspx#/)

> - PT2 drafts, available in the [ETSI DocBox](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09)

> - ENISA's [CRA Requirements Standards Mapping](https://www.enisa.europa.eu/sites/default/files/2024-11/Cyber%20Resilience%20Act%20Requirements%20Standards%20Mapping%20-%20final_with_identifiers_0.pdf)

> Why do we need security levels? Isn't the base operation the same, but the applicaton usage context different? Stricter security expectes more imlemented features.

## 6.1 Product's technical requirements specifications

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

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

<mark>FIXME make the listing</mark>

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

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

> Table mapping technical security requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical security requirements.

| Logging and monitoring mechanisms               |                                    |

| Secure deletion and data transfer               |                                    |

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

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

## C.1 Assets

> - Use for intended purpose or reasonably foreseeable use

> - When integrated into another product

<mark>FIXME list threats</mark>

> Example threats can be found in the same documents suggested in the section on security requirements.

## C.3 Assumptions

## D.1 Mapping of risks to requirements

<mark>FIXME Create table mapping the identified risks to requirements</mark>

> Table mapping the identified risks to requirements

## D.2 Risks not treated by the requirements

<mark>FIXME fill in</mark>

## D.4. Residual risks

## D.4 Residual risks

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

**It should be evaluated - on the basis of the legal requirements supported and other information given in a harmonised standard - how detailed correspondence can be indicated between the normative elements of the harmonised standard and the legal requirements aimed to be covered. However, where this correspondence is expressed in too general terms, it could lead to a situation where the Commission cannot assess whether the Harmonised Standard satisfies the requirements, which it aims to cover, and subsequently publication of its references in the OJEU according to Article 10(6) of the Regulation is significantly delayed or is not possible at all.**

> **EXAMPLE for a table:**

**Table A.1: Relationship between the present document and<br />the requirements of EU Regulation 2024/2847**<a name="table_A.1"></a>

Other Union legislation may be applicable to the product(s) falling within the scope of the present document.

<br />

# Annex: Bibliography

# Annex <L+3> (informative): Bibliography

<br />

<Publication>: "<Title>".<Edition>. <Year>, <Issue designation>, <Page location>.

# Annex <L+4> (informative): Change history

|                 |         |                                           |

|                 |         |                                           |

<br />

# History

> The following table will automatically be filled in by the ETSI Secretariat.

+-------------------------------------------------+

|Document History |

+:==============+:==============+:================+

| Document Hisotry |      |                |

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

| Version          | Date | Milestone      |

+---------------+---------------+-----------------+

| <Month year>     | <#>  | <Changes made> |

+---------------+---------------+-----------------+

| | | |

+---------------+---------------+-----------------+

| | | |

+---------------+---------------+-----------------+