Synched with the latest from skeleton structure

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](https://ipr.etsi.org/).

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](https://ipr.etsi.org/).

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.

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.

**DECT™**, **PLUGTESTS™**, **UMTS™** and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. **3GPP™** , **LTE™** and **5G ™** logo are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. **oneM2M™** logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. **GSM®** and the GSM logo are trademarks registered and owned by the GSM Association.

**DECT™**, **PLUGTESTS™**, **UMTS™** and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. **3GPP™** and **LTE™** are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. **oneM2M™** logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. **GSM®** and the GSM logo are trademarks registered and owned by the GSM Association.

# Foreword

The present document provides the technical cybersecurity requirements for the products in scope, following a risk-based approach in support of the Cyber Resilience Act (CRA) [\[i.1\]](#_ref_i.1). The technical cybersecurity requirements are thereby proportionate to the intended purpose, reasonably foreseeable use, deployment context, and threat exposure of the products.

[Clause 4](#4-product-context) does not contain technical requirements; it describes the product architecture and intended purpose in their context.

[Clause 4](#4-product-context) does not contain technical requirements; it describes the product context that is considered for the application of the present document.

Clause 4 also defines Use Cases (UCs) that represent the main deployment scenarios reflecting the intended purpose and reasonably foreseeable use of the product, which serve as the basis for identifying relevant cybersecurity risks.

[Annex A](#annex-a-informative-relationship-between-the-present-document-and-the-requirements-of-eu-regulation-eu-20242847---the-cyber-resilience-act) maps the technical requirements of the present document with the essential requirements of the CRA [\[i.1\]](#_ref_i.1) regulation.

[Annex B](#annex-b-informative-security-analysis) informs about the methodology used to assess the security risks of the products in their context. Where a product does not clearly correspond to one of the defined Use Cases of Clause 4, the risk assessment methodology of Annex B may be used to determine the applicable cybersecurity requirements.

[Annex B](#annex-b-informative-security-analysis) informs about the methodology used to assess the security risks of the products in their context.

[Annex K](#annex-k-normative-generic-cryptographic-requirements-and-assessment) supports the definition of the cryptographic requirements and assessment criteria used by the present document.

[Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps) provides supplementary requirements and assessment provisions where a product relies on remote data processing solutions (RDPS) for the provision or support of one or more product functions.

> NOTE: Annex R may be used by vertical standards where RDPS-specific security considerations are relevant and are not already addressed by the core requirements of the concerned standard.

Further information on guidance for the application of the present document is provided in Annex G.

# 1 Scope

The present document specifies technical requirements and corresponding assessment criteria for [vertical product category name] related to cybersecurity.

The products with digital elements in scope, thereafter "NMS":

are specified within the "technical description" of the "category of product" number "NN" by the Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 on the technical description of the categories of important and critical products with digital elements pursuant to Regulation (EU) 2024/2847 of the European Parliament and of the Council. [\[i.2\]](#_ref_i.2) as:

- are specified within the "technical description" of the "category of product" number "NN" by the Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 on the technical description of the categories of important and critical products with digital elements pursuant to Regulation (EU) 2024/2847 of the European Parliament and of the Council. [\[i.2\]](#_ref_i.2) as:

> Products with digital elements that manage connected network elements, such as servers, routers, switches, workstations, printers or mobile devices, by monitoring them and controlling their network operations and 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.

The present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847 [\[i.1\]](#_ref_i.1) Annex I Part I under the conditions identified in annex A.

> NOTE: This reduces the scope of the vertical. Full presumption of conformity of the product will be given by complying with both the CRA Vertical standard and PT3, once they are cited in the EUOJ.

NMS as defined above is not restricted only to systems that are "internet protocol" (IP) connected. The scope covers all connected elements in the network that are managed. This includes, but is not limited to, Mobile Device Management (MDM) systems and Software Defined Networking.

Personal Area Network (PAN) consumer devices are usually not managed by an NMS, however, if they are capable, a NMS management could control them too, as PAN devices are communication media and can be used for management traffic. In such situations the NMS used often has functions beyond network configuration such as in most Mobile Decive Management systems.

NMS necessary for extremely high secuirity deployments, such as those designed and developed to be hardened against nation-state and other highly sophisticated attackers are excluded from the scope of the present document.

The present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847 [\[i.1\]](#_ref_i.1) Annex I Part I under the conditions identified in annex A.

> NOTE: This reduces the scope of the vertical. Full presumption of conformity of the product will be given by complying with both the CRA Vertical standard and PT3, once they are cited in the EUOJ.

<mark>Editor’s Note: Explain which products are covered by other vertical standards that have an overlap with the product category targeted by this standard.</mark>

Where applicable, the scope could include the following exclusion:

[the product_short_name] intended for use in the industrial OT (Operational Technology) domain are excluded from the scope of the present document, see prEN 50770 series [\[i.x\]](#_ref_i.x).

The scope covers all connected elements in the network that are managed. This includes, but is not limited to, Mobile Device Management systems and Software Defined Networking.

NMS intended for use in the industrial OT (Operational Technology) domain are excluded from the scope of the present document, see prEN 50770 series [\[i.x\]](#_ref_i.x).

# 2 References

## 2.1 Normative references

<mark>Editor's Note: _**In Harmonised Standards these references shall be specific** (identified by date of publication and/or edition number or version number) **publicly available and in English, **except in exceptional circumstances making sure that impacts have been evaluated and explanations have been given on how any negative implications should be avoided**. See clauses 2.10.1 and 8.4 of the [EDRs](https://portal.etsi.org/Services/editHelp/How-to-start/ETSI-Drafting-Rules)._</mark>

<mark>Editor’s Note: Chains of normative references should be as short as possible or avoided altogether. Where references themselves include further references, authors should, as appropriate, attempt to resolve intermediate references and directly include the final target of referencing in this document.</mark>

<mark>Editor’s Note: Normative references must be limited to European standards (EN), except where those references are without alternative, essential to the standard. In that case, it is strongly advised to seek feedback from the European Commission (e.g., ENISA ACM document has been flagged as adequate by the European Commission). Publicly available ISO/IEC standards can be considered appropriate; contact the European Commission for feedback of any reference that is not an EN or an ISO/IEC standard.</mark>

<mark>Editor's Note: _**Legal acts can never be used as normative references.**_</mark>

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/).

<span id="_ref_1"></span><a name="_ref_1">[1]</a> [ENISA Report 1747792503](https://certification.enisa.europa.eu/document/download/a845662b-aee0-484e-9191-890c4cfa7aaa_en?filename=ECCG%20Agreed%20Cryptographic%20Mechanisms%20version%202.pdf) (version 2 - April 2025) "European Cybersecurity Certification Group Sub-group on Cryptography Agreed Cryptographic Mechanisms" [ACM]

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

<span id="_ref_1"></span><a name="_ref_3">[3]</a> ENISA April 2025 (Version 2.0) "Agreed Cryptographic Mechanisms"

## 2.2 Informative references

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

<span id="_ref_i.x"></span><a name="_ref_i_x">[i.x]</a> ENISA April 2025 (Version 2.0) "Agreed Cryptographic Mechanisms"

# 3 Definition of terms, symbols and abbreviations

## 3.1 Terms

`CC    Common Criteria`

`CPU   Central Processing Unit`

`CRA   Cyber Resilience Act`

`CRL   Certificate Revocation List`

`CVE   Common Vulnerabilities and Exposures`

`DB    Database`

`DNS   Domain Name Server`

`MP    Main Product`

`MTTD  Mean Time to Detect`

`MTTR  Mean Time to Respond`

`NAT   Network Address Traversal`

`NIST  National Institute of Standards and Technology`

`OCSP  Online Certificate Status Protocol`

`OS    Operating System`

`OT    Operational Technology`

`PC    Personal Computer`

`PIA   Privacy Impact Assessments`

`PKI   Public Key Infrastructure`

`PSK   Pre-shared key`

`PoLP  Principle of Least Privilege`

`RDPS  Remote Data Processing Solution`

`RTO   Recovery Time Objective`

## 4.1 Product Functions

<mark>Editor’s Note: Product functions should be clearly defined and granular enough to inform decision-making regarding capability-based applicability of related security controls. The recommended structure for doing this is a hierarchical functional decomposition, wherein each larger functional capability is broken down into its constituent parts. This enables manufacturers to easily derive whether their product supports parts of or all of a specific function.</mark>

<mark>Editor’s Note: If the product category consists of multiple distinct product types, the functions of each product type should be listed separately, possibly following an overall function list up with a mapping to product types.</mark>

<mark>Editor’s Note: Where a product contributes to the delivery of services as part of a system, these services do not constitute functionalities of the product. Identify the product’s role in the delivery of services.</mark>

<mark>Editor’s Note: Configuration functionality is equally in scope.</mark>

The following list of essential functions keep the NMS self-secure and correct functioning during its operation in its intended environment.

## 4.2 Product Architecture

<mark>Editor’s Note: This clause shall depict reference architectural patterns of products in this category, focusing on the architecture of the product itself and not the product as part of its operational environment or a larger ecosystem. The goal is to clearly indicate components, RDPS and their inter-relationships.</mark>

<mark>Editor’s Note: If the product category consists of multiple distinct product types, the reference architecture for each product type shall be drawn up separately for maximum clarity.</mark>

<mark>Editor’s Note: The diagram(s) shall be clearly labeled and accompanied by a short description of the main flows and components.</mark>

Network management systems are commonly deployed using centralized management services that provide command, control, monitoring, and administration functions.

## 4.3 Operational Environment

<mark>Editor’s Note: This clause should describe the conditions under which products of a particular type in the category are used as well as detailing possible systems in which they are integrated, including network context, integration environment, and physical surroundings, including the external conditions affecting RDPS.</mark>

<mark>Editor’s Note: Human factors of the operational environment are to be discussed in other clauses.</mark>

The technical requirements of the present document apply to the operational and environmental profiles of a Network Management System in accordance with its intended use.

### 4.3.1 General description

## 4.4 Distribution of Security Functions

<mark>Editor's Note: The clause should explain how the security functions are distributed among the product and its environment, referencing as appropriate elements of the operational environment defined in prior clauses. This analysis is not limited to which security functions products expect to get but should also explain which functions they themselves provide.</mark>

An NMS can be formed by a compilation or collaboration of different subsystems in a local distance but within the same management network and within the equal operational environment.

The security functions may be implemented inside one or more of the subsystems that form the NMS.

The NMS can thereby be operated by an OS package manager or other systems which also belong to the NMS and are in scope of the present standard.

    - Description via subclauses or bullet points which elements from each apply (i.e., product type: ..., function: ..., users: ..., architecture: ..., operational environment: ...)

</mark>

<mark>The use cases should be generic enough to cover most products available on the market in the scope of the standard, and granular enough to serve as a basis for the security analysis. Use cases need to be exhaustive enough to capture differences in terms of security impact (to cover the whole scope of the standard).</mark>

<mark>Full exhaustivity is not realistic; what matters is security impact.</mark>

<mark>Editor’s Note: Use cases may include the case of critical infrastructure but shall refrain from an explicit link to the NIS 2 Directive.</mark>

This list of use cases is a resource for manufacturers to simplify the selection of a set of cybersecurity requirements.

Manufacturer's technical documentation may benefit from including or referring to these use cases and associated security profiles.

<mark>_Proposed ESR code: SU_</mark>

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (c). This technical requirement may be accompanied by the following note:

> NOTE: The CRA essential requirement laid out in Annex 1 Part 1 (2) (b) foresees an applicability exception to the secure configuration by default in case there is an agreement between manufacturer and business user in relation to a tailor-made product with digital elements.

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (c).

## 5.6 Authentication and access control

## 6.1 Introduction to the assessment and compliance criteria

This clause provides objective and reproducible assessment criteria to determine whether a product complies with the technical security requirements of clause 5.

For each cybersecurity requirement defined in clause 5, the following clauses specify assessment criteria to determine if the technical requirement is met.

For each cybersecurity requirements defined in clause 5, the following clauses specify assessment criteria to determine if the technical requirement is met.

<mark>Editor’s note: Please ensure that there is an easy, clear and unambiguous mapping of the requirements in clause 5 to the relevant assessment criteria in clause 6.</mark>

The assessment criteria for each security requirements are described in a structured manner, as follows:

> NOTE 2: If the standard is developed according to the structure in the present skeleton document, then the number of the clauses in the table below don't need to be changed.

> NOTE 3: The last two columns shall be either filled with details and the reference of the table(s) mapping the applicability of the technical cybersecurity requirements, or deleted all together.

**Key to columns:**

**Requirements of Regulation** Identification of article(s) defining the requirement in the Regulation.

This Annex applies state of the art methodology to identify assets, threats, identify and evaluate risk factors, and define security profiles applicable to the different use cases identified in the product context.

<mark>

The standard may implement an existing methodology, referencing the standards where it is defined. Alternatively, the following structure has been proposed as part of the HAS comments received, that may be adapted as relevant for each vertical:

<mark> Editor's Note: The standard may implement an existing methodology, referencing the standards where it is defined. However, this methodology shall not compete with the legal obligation to draft an overall risk assessemnt. Alternatively, the following structure has been proposed as part of the EC comments received, that may be adapted as relevant for each vertical:

<br>

B.1 Assets

<br>

There are no clear instructions or interfaces available.

The SBOM format and generation is not a concern that is unique for the products in this category.

# Annex L (informative): Change history

_The following table will automatically be filled in by the ETSI Secretariat._

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

|Document history                                                                                  |

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

|V0.0.1    |16 Feb 2026   |Preliminary draft distributed to all ETSI-EUSR Rapporteurs for comments |

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

|V0.0.2    |24 Feb 2026   |Contributed and presented to CYBEREUSR#30, including comments received  |

|          |              |from consumer IoT and Hypervisor rapporteurs                            |

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

|V0.0.3    |5 March 2026  |Contributed to CYBEREUSR#31, including comments from previous meeting   |

|          |              |and additional guidance received from EC **and new introduction clause**|

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

|V0.0.4    |10 April 2026 |Resolution of inconsistencies, links errors and editorials              |

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

|          |              |                                                                        |

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

<br />

_Last update on 2026-04-03_