Formatting changes

---

Title: Cybersecurity (CYBER); CRA; Cybersecurity requirements for network management systems

Spec Number: 304 621

Version: vX.Y.Z

Date: 2026-00-00

Version: v0.2.1

Date: 2026-07-08

Release: 5

Work Item: DEN/CYBER-EUS-009

keywords: CRA, Cybersecurity, Network

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

It is one of a series of standards prepared under the Commission's 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).

The present document has been prepared under the Commission's standardisation request C(2025)618 [\[i.3\]](#_ref_i.3) to provide one voluntary means of conforming to the requirements of Regulation (EU) 2024/2847 [\[i.1\]](#_ref_i.1) 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, known as the Cyber Resilience Act (CRA).

Once the present document is cited in the Official Journal of the European Union under that Regulation, compliance with the normative clauses of the present document given in table A.1 confers, within the limits of the scope of the present document, a presumption of conformity with the corresponding requirements of that Regulation and associated EFTA regulations.

9. **trace**: record of a system status with all relevant data that can be gathered

10. **squid proxy server**: an open-source-proxy server, often with intelligent web-caching and improvements of accelerating data transmissions combined with access controls

11. **manage element**: a physical or virtual device managed by the product

12. **cryptographic property**: property provided or supported by a cryptographic mechanism

13. **cryptographic mechanism**: security-related procedure using cryptography

This section provides terms and definitions based on CEN/CLC JTC13 WG09's work on terms and definitions provided by ETSI EN 303 645/TS 103 701 and terms and definitions provided by CEN/CLC EN 18031 series.

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

<mark>Add in the symbols used in the architecture drawings?</mark>

## 3.3 Abbreviations

For the purposes of the present document, the abbreviations given in <mark>... do we refer PT1?</mark> and the following apply:

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

`2FA   Two Factor Authentication`

`ABAC  Attribute-Based Access Control`

`ACM   Agreed Cryptographic Mechanisms`

`API   Application Programming Interface`

`CPU   Central Processing Unit`

`CRA   Cyber Resilience Act`

`CSP   Communication System Provider`

`CVE   Common Vulnerabilities and Exposures`

`DB    Database`

`DNS   Domain Name Server`

`DHCP  Dynamic Host Configuration Protocol`

`ER    Essential Requirement`

`GDPR  General Data Protection Regulation`

`GUI   Graphical User Interface`

`IAM   Identity and Access Management`

`IdP   Identity Provider`

`ICT   Information and Communication Technology`

`IoT   Internet of Things`

`IP    Internet Protocol`

`ISO   International Organization for Standardization`

`MDM   Mobile Device Management`

`NE    Network Element`

`NIST  National Institute of Standards and Technology`

`NMS   Network Management System`

`OCI   Open Container Initiative`

`OS    Operating System`

`OT    Operational Technology`

`PAN   Personal Area Network`

`PC    Personal Computer`

`PIA   Privacy Impact Assessments`

`PII   Personally Identifiable Information`

`PKI   Public Key Infrastructure`

`RDPS  Remote Data Processing Solution`

`RTO   Recovery Time Objective`

`SCC   Security Category Classes`

`SDK   Software Development Kit`

`SDN   Software Defined Networks`

`SIEM  Security Information and Event Management`

`SIF   Social Interactive Function`

`SOAR  Security Orchestration Automation and Response`

`SRU   Service Requesting Users`

`TLS   Transport Layer Security`

`UC    Use Case`

`VPN   Virtual Private Network`

and

`API    Application Programming Interface`

`ABAC   Attribute-Based Access Control`

`2FA    Two Factor Authentication`

`CSP    Communication System Provider`

`ER     Essential Requirement`

`IdP    Identity Provider`

`IP     Internet Protocol`

`NE     Network Element`

`NMS    Network Management System`

`MDM    Mobile Device Management`

`OCI    Open Container Initiative`

`PAN    Personal Area Network`

`TR    Technical Requirement`

`UC    Use Case`

`VPN   Virtual Private Network`

`SDN    Software Defined Networks`

`SRU    Service Requesting Users`

`PII    Personally Identifiable Information`

# 4 Product context

Where applications are able to preserve their statuses despite their changing virtual environment, and where these applications can share their statuses with atomic execution containers, these instances can change the application statuses.

These exchanges do not need the DHCP, and, the hosting OS container even does not need to request an IP address, as the OS container operates a preconfigured veth-interface ensuring the connectivity.

##### Application in a SDN

#### 4.2.1.2 Application in a SDN

These application network design parameters are in the form of a configuration, and are presented as a request towards the runtime environment.

The application describes its needs as how much distribution it requires, what parts of the different processes can be in the same or different computational context, and even how much capacity it expects from the backend.

This highly abstract and fluid control scheme can host emergency services critical information, nations polling results or a non-profit organisations read-only website.

Only the implementing entity's risk appetite sets the upper limit on what this structure can be used for.

#### 4.2.1.2 Pocket deployment

#### 4.2.1.3 Pocket deployment

A pocket deployment is a special combination of design criteria, where the product serves a single product user and the interconnectivity of the network is minimal.

A connected network always requires at least one upstream gateway where to send packets to.

When a single device is compromised, the exposure is limited to the devices in that same network.

#### 4.2.1.3 Devices using provided connectivity

#### 4.2.1.4 Devices using provided connectivity

Relying on provided connectivity is common for devices that are part of some [ecosystem](#413-ecosystem-management) where the main function of the device is not necessarily to serve Service Requesting Users with connectivity, but to provide the user higher level application features.

The cluster the product is hosted at is often composed out of multiple nodes and scaled to fit into the operator’s operational environment.

The number of nodes and the composition of the hardware is designed to handle the expected load from the management function the product is performing.

**Table 4.3.2-1: Logical separation of duties adjacent to RFC1122**

| Layer                     | Responsibility       | Observability                                           |

| :------------------------ | :------------------- | :------------------------------------------------------ |

| Application               | Development          | Quality provided for the customer                       |

| Capacity                  | HW engineers         | Application requests towards HW                         |

| Networking and facilities | Site manager         | Is it on? Can I walk into the premises?                 |

**Table 4.3.2-1: Logical separation of duties adjacent to RFC1122**

The product requirement can be defined with the abstraction layers as given in the table above, but the product is required to support the architectural design and conditions of the concrete operational environment.

There are a variety of structures and responsibility separations supporting the actual use case possible.

Also the product’s shipment and delivery procedures usually follow the system users' needs and may also need to be conformant with critical infrastructure rules and requirements.

> Example: SIEM system operation requires access grants from the product Application-layer to be able to collect information from devices in the Networking and facilities-layer.

**Table 4.3.2-2: Responsibility separation example in a larger scale deployments**

| Layer                     | In-house             | Hyperscaler      | On-site as a service |

| :------------------------ | :------------------- | :--------------- | :------------------- |

| Application               | Product customer     | Product customer | Service provider     |

| Capacity                  | HW engineers         | Hyperscaler      | Product customer     |

| Networking and facilities | Site manager         | Hyperscaler      | Product customer     |

**Table 4.3.2-2: Responsibility separation example in a larger scale deployments**

While it is possible to stay in a higher abstraction level of above layering while defining the product requirements, the provided product needs to acknowledge what designs are supported.

There are different benefits in different responsibility separation structures.

Often the selection of delivery style is guided by customer needs, where critical infrastructure requirements have to to be matched in the product.

This ABAC is also known as policy-based access control that compliments Identity and Access Management (IAM).

The attributes that formulate the identity portion of the grant are often matched with a target action.

> **ABAC Example:**

> An identified workflow execution A in a trusted environment B can amend the OCI registry C, under a project D, with a new container if the workflow is launched under trusted environment B organisation E, repository F.

> EXAMPLE: An identified workflow execution A in a trusted environment B can amend the OCI registry C, under a project D, with a new container if the workflow is launched under trusted environment B organisation E, repository F.

In the above example, the trust relationship between policy holder and the source environment can be established in various ways with different implementations.

* Delivery of configuration and software to hosts in a push model (initiated by the NMS) or a pull model (requested by the host), in both cases with host-side verification of the integrity and authenticity of the delivered content, as described in [4.2.4.3 Device management](#4243-device-management).

Managed hosts typically run an agent that registers with the NMS during enrolment.

Trust between the NMS and each host is established at enrolment, as described in [4.3.x Trust initialisation](#43x-trust-initialisation), and is thereafter used to authenticate the host and to deliver configuration, content, and commands.

The connectivity between the NMS and the managed hosts is, in this use case, usually provided by the surrounding network and is not controlled by the product, as described for [devices using provided connectivity](#421x-devices-using-provided-connectivity).

Trust between the NMS and each host is established at enrolment, as described in [4.3.4.4 Trust initialisation](#4344-trust-initialisation), and is thereafter used to authenticate the host and to deliver configuration, content, and commands.

The connectivity between the NMS and the managed hosts is, in this use case, usually provided by the surrounding network and is not controlled by the product, as described for [devices using provided connectivity](#4214-devices-using-provided-connectivity).

The NMS can be deployed as a single instance for a small estate, or scaled with intermediate proxies or hubs that cache content and relay commands to hosts in remote sites or segmented networks, following the [distributed deployment](#421-network-architecture) pattern.

The upstream software content source — and, depending on the product, subscription, licensing, or usage reporting — is commonly external to the product and is then a [remote data processing solution](#44-distribution-of-security-functions), to which the provisions of [Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps) apply.

## B.1 Assets

<mark>What is the impact of the asset compromise?</mark>

**Network connectivity**

* Social interaction

Configuration and monitoring data confidentiality requirements depends on the data set classification and national policies.

> Example: In Finland, base station location is considered to be secret, as it is seen to be part of critical infrastructure, and the location combined with monitoring data could reveal other protected assets or personal information.

> EXAMPLE: In Finland, base station location is considered to be secret, as it is seen to be part of critical infrastructure, and the location combined with monitoring data could reveal other protected assets or personal information.

> Not all nations see this the same way.

Confidentiality of business-critical processes is more important for the service requesting user, rather than for the who provides the network connectivity.

The risks are a combination of likelihood and impact.

Each risk factor is evaluated using defined criteria for likelihood and impact.

**Table B.2-1: Determining risk level**

### B.2.1 Managed elements (RF_ELEMENT)

The service requesting user quantity and type impacts the risk evaluation.

Enterprise risks scale with the complexity of the network, the number of users, the variety of devices, interconnectivity of the sites and with the criticality of the operating entity.

> Example 1:

> EXAMPLE 1:

> A water production facility might have a low staff count, but the operation is defined to be critical in the local legislation, the entity needs a system, where all mitigations are implemented to the highest standard.

> Example 2:

> EXAMPLE 2:

> A business that is just starting, where the operations are small, and relevancy is not significant to the society, at least yet, does not necessarily benefit from support for external auditing systems, like the one that is required from a CSP.

> Example 3:

> EXAMPLE 3:

> A growing enterprise, where there are under thousand devices in the network, a few office sites, moderate interconnectivity does not require the same level of details from metrics than a CSP would.

Each of the following is true independently:

## K.0 General

### K.0.1 Introduction

<mark>Editor’s note: Clause K.0 provides general context, terms and application guidance for vertical standards. Guidance and editorial instructions in this clause shall be removed or adapted when Annex K is integrated into a vertical standard. Terms and definitions in clause K.0.2 shall be moved to the terms and definitions clause of the vertical standard or retained in Annex K, as appropriate.</mark>

The requirements and assessment provisions provided by this annex are intended to be used as a common framework for vertical CRA standards concerning the use of cryptography, including state-of-the-art cryptographic mechanisms and controlled interoperability-based exceptions, with the aim to:

- provide a path towards presumption of conformity;

- enable cross-vertical alignment; and

- reflect interoperability needs.

Vertical standards may adapt the framework, and in particular specify additional or more specific requirements, assessment activities, assessment evidence or assessment criteria where needed for the relevant product category, product function, use case or risk profile.

Clause K.1.1 defines the product-facing requirement for the cryptographic mechanisms used in the product’s default configuration. It distinguishes ACM-listed cryptographic mechanisms defined in [\[1\]](#_ref_1), ACM-extended cryptographic mechanisms, and interoperability-based cryptographic mechanisms listed in clause K.4.2. ACM-extended cryptographic mechanisms are either listed in clause K.3.2 or fulfil the criteria specified in clause K.1.1 item 2.b.

Vertical standards can instantiate clause K.3.2 where ACM-extended cryptographic mechanisms are specified by the vertical standard. Mechanisms listed or referenced in clause K.3.2 shall be identified with sufficient precision to support assessment under clause K.1.2. For interoperability-based cryptographic mechanisms, vertical standards shall instantiate clause K.4.2 and identify the mechanisms with sufficient precision to support assessment under clause K.1.2.

### K.0.2 Terms and definitions

**Cryptographic mechanism**: security-related procedure using cryptography.

> NOTE 1: The term “cryptographic mechanism” is used in this annex as an umbrella term covering the categories used in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [\[1\]](#_ref_1), including cryptographic algorithms, primitives, schemes, protocols, protocol profiles, cipher suites, modes of operation, constructions and parameter sets.

> NOTE 2: The terms “cryptographic primitive”, “cryptographic construction”, “cryptographic scheme” and “cryptographic protocol” are used consistently with the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [\[1\]](#_ref_1).

> NOTE 3: A cryptographic mechanism can be specified at different levels of abstraction. For example, AES is a cryptographic primitive, AES-GCM is a mode of operation / authenticated encryption construction, TLS 1.3 is a protocol, a TLS 1.3 restricted cipher-suite profile is a protocol profile, and TLS_AES_128_GCM_SHA256 is a cipher suite.

**Cryptographic property**: property provided or supported by a cryptographic mechanism.

> NOTE 4: Cryptographic properties include, for example, confidentiality, integrity, authenticity, entity authentication, message authentication, key establishment, key confirmation, replay protection, collision resistance, second-preimage resistance, pre-image resistance, signature unforgeability, non-repudiation, forward secrecy and password-verifier protection. Where relevant, a cryptographic property can be expressed using a formal cryptographic notion, for example IND-CPA, IND-CCA, IND-CCA2, EUF-CMA, SUF-CMA or authenticated key exchange security.

> NOTE 5: A cryptographic property is distinct from a product-level technical requirement, although it can support such a requirement. For example, a secure communication requirement can rely on cryptographic properties such as confidentiality, integrity and authentication.

### K.0.3 Application Guidance for vertical standards

Vertical standards should use the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [\[1\]](#_ref_1) as the primary reference for cryptographic mechanisms, as defined in clause K.1.1 item 1).

Where the ACM catalogue is not sufficient, or where a cryptographic mechanism is not explicitly listed in the ACM catalogue, including a specific profile, restriction or configuration of an ACM-listed mechanism, the ACM-extended route in clause K.1.1 item 2 can be used. Vertical standards can specify or reference ACM-extended cryptographic mechanisms in clause K.3.2. For mechanisms not listed in clause K.3.2, the criteria in clause K.1.1 item 2.b apply.

Where a cryptographic mechanism is not classified as state-of-the-art cryptography but is needed for interoperability, vertical standards can specify or reference the mechanism in clause K.4.2, subject to the selection criteria defined therein. This covers cases where an external specification, operational constraint or interoperability requirement requires the use of such a cryptographic mechanism, provided that its use is identified, limited to the intended interoperability purpose and, where applicable, mitigated at system level. Inclusion of a cryptographic mechanism in clause K.4.2 does not classify it as state-of-the-art cryptography.

Clause K.1.2 defines the assessment of the product’s cryptographic default configuration. It is intended to verify that the cryptographic mechanisms used in the product’s default configuration are ACM-listed, ACM-extended under clause K.1.1 item 2, or interoperability-based under clause K.1.1 item 3, and that they are used in accordance with the relevant characteristics, product functions, use cases where applicable, external specifications or external requirements, and conditions specified in the present document.

Clause K.2 defines the crypto-agility requirement, and clause K.2.2 defines the corresponding assessment of crypto-agility mechanisms. This assessment verifies whether the product provides means to address situations where the ACM catalogue, or the vertical standard, specifies a deprecation date, expiry date, migration condition or usage limitation for a cryptographic mechanism used in the product’s default configuration, and where this lifecycle information falls within the intended lifetime of the product.

Vertical standards should specify cryptographic mechanisms at the level appropriate for the product functions and, where relevant, use cases, by identifying any relevant characteristics, parameters, protocol profiles, cipher suites, configuration constraints, conditions or limitations.

Where different product functions or use cases require different cryptographic mechanisms, profiles, conditions or limitations, clauses K.3.2 and K.4.2 should identify the related product function, use case where relevant, conditions or limitations for each listed cryptographic mechanism, and, for clause K.4.2, the relevant external specification or external requirement.

For interoperability-based cryptographic mechanisms, clause K.4.2 should also clearly identify the interoperability justification and any conditions or limitations needed to ensure secure and constrained use. Where the organisation accountable for the relevant specification is not explicitly listed in clause K.1.1 item 2.b ii) or clause K.4.0 item b), rapporteurs are to document additional supporting evidence before including the cryptographic mechanism in clause K.3.2 or K.4.2, respectively. Such evidence may include public technical review, SDO review, expert review, security proof, formal analysis, rigorous technical argument or dedicated security analysis.

If the vertical standard does not specify ACM-extended cryptographic mechanisms, clause K.3 should state that no ACM-extended cryptographic mechanisms are specified. If the vertical standard does not specify interoperability-based cryptographic mechanisms, clause K.4 should state that no interoperability-based cryptographic mechanisms are specified.

For the purpose of completing clauses K.3.2 and K.4.2, the vertical standard does not need to reproduce the full content of a referenced cryptographic catalogue, external specification or external requirement. It may reference the relevant catalogue entry, clause, table, profile, requirement or other uniquely identifiable part of the referenced source, provided that the cryptographic mechanism, its applicable characteristics, parameters, conditions or limitations, and the related product function or interoperability need are sufficiently identifiable for assessment.

## K.1 Cryptography

### K.1.1 Requirement